Verification & Validation
- 1. Verification and Validation V & V
- 2. Verification and Validation Verification and Validation are used interchangeably but have different definitions.
- 3. Verification(Reviews) Verification is the process confirming that -software process meets its specification
- 4. Validation Validation is the process confirming that it meets the user’s requirements.
- 5. Definitions Verification is the process of determining whether one phase of a software process conforms to its previous phase Validation is the process of determining whether a fully developed system conforms to its requirements specification.
- 6. Software V&V Requirements Design Code System Test Integration Test Unit Test
- 7. Purpose of Review Detect defects earlier Emphasize quality throughout development May involve customer / end user Permit midcourse corrections
- 8. Objectives Verify that specifications are satisfied Verify conformance to standards Identify deviation from standards and specifications Collect data for improvement
- 9. Need for Reviews Requirements Product Development
- 10. Need for Reviews Development Requirements Product Rework
- 11. Verification Use: To identify defects in the product early in the life cycle. Classification: Verifications are classified based on the Time&purpose.
- 12. Types of Reviews Inprocess Review Phase end/Decision Point/Milestone Review Post Implementation/Post Mortem
- 13. During a specific period of the development cycle – like design period Used to find defects in the work product and the work process Catches defects early – where they are less costly to correct. Types of Reviews In Process
- 14. Decision-point & Phase-end Review of products and processes near the completion of each phase of development. Decisions for proceeding with development are based on cost, schedule, risk, progress, readiness for next phase. Also referred to as Milestone Review
- 15. Also known as “Postmortems” Review/evaluation of the product that includes planned vs. actual development results and compliance with requirements Used for process improvement of software development Can be held up to three to six months after implementation Post Implementation Reviews
- 16. Informal Review (or) Peer review Semiformal Review (or) Walk Through Formal Review (or) Inspection Classes of Reviews
- 17. Informal Also called peer-reviews Generally one-to-one meeting Scheduled Results are reported Occur as needed through out each phase Classes of Reviews
- 18. Semiformal Facilitated by the author Presentation is made with comment throughout and at the end reports are distributed to the participants Possible solutions for defects may discussed Occur one or more times during a phase Classes of Reviews
- 19. Formal Classes of Reviews Facilitated by moderator Assisted by recorder Meetings are planned in advance Directly dependent on the preparation of participants Held at any time
- 20. Formal Review Team Members Classes of Reviews
- 21. The product is reviewed, not the producer Defects and issues are identified, not corrected All members of the reviewing team are responsible for the results of the review Review Rules
- 22. Test Level Criteria's Entrance Criteria Exit Criteria
- 23. Special Test types Performance: the time taken to complete a task How Performance is measured? Processing speed Response time Efficiency
- 24. Performance test It is designed to test the run time performance of software. It occurs throughout all steps in the testing process.(test levels)
- 25. Load The maximum number of users a system can support is called load. We feed it with all that it can handle. Operate the software with the largest possible data files.
- 26. Stress Running the software under less conditions Low memory, Low disk space and so on. Limiting them to their bare minimum. Pull down resources
- 27. Usability Determines how well the user will be able to understand and interact with the system. This is done prior to the testing levels.
- 28. Vendor Validation this can be conducted jointly by software vendor and the testing team. Ensuring that all the requested functionality has been delivered. Prior to accepting it & installing it into a production.
- 29. Benefits Realization Test It is a test or analysis conducted after an application is moved into production. To determine whether the application is likely to deliver the original benefits. This is conducted by the user or client group who requested the project.
- 30. Configuration Testing This testing is performed find out the various supporting combinations of hardware and software.
- 31. Recovery Testing It is nothing but a features built into the application for handling interruptions. Returning to the actual points/Page in the application.
- 32. Test Standards – Area 2 External Standards Familiarity with and adoption of industry test standards from organizations Internal Standards Development and enforcement of the test standards that testers must meet
- 33. External Standards IEEE Institute of Electrical and Electronics Engineers Founded in 1884 Have an entire set of standards devoted to Software Testers should be familiar with all the standards on the attached IEEE document (included an abstract for each one)
- 34. IEEE STANDARDS That a Tester should be aware of 610.12-1990 IEEE Standard Glossary of Software engineering Terminology 730-1998 IEEE Standard for Software Quality assurance Plans 828-1998 IEEE Standard for Software Configuration Management Plan 829-1998 IEEE Standard for Software Test Documentation. 830-1998 IEEE Recommended Practice for Software Requirement Specification 1008-1987 (R1993) IEEE Standard for Software Unit Testing(ANSI) 1012-1998 IEEE Standard for Software Verification and Validation 8. 1012a-1998 IEEE Standard for Software Verification and Validation- Supplement to 1012-1998 – Content Map to IEEE 122207.1 1016-1998 IEEE Recommended Practice for Software Design Descriptions 1028-1997 IEEE Standard for Software Reviews 1044-1993 IEEE Standard Classification for Software Anomalies 1045-1992 IEEE Standard for Software Productivity Metrics ( ANSI) 1058-1998 IEEE Standard for Software Project Management Plans 1058.1-1987 (R1993) IEEE Standard for Software Management Plans (ANSI) 1061-1998 IEEE Standard for Software Quality Metrics Methodology
- 35. Internal Standards The use of Standards… Simplifies communication Promotes consistency and uniformity Eliminates the need to invent yet another solution to the same problem Provides continuity Presents a way of preserving proven practices Supplies benchmarks and framework