Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Verification  and  Validation V & V
Verification and Validation <ul><li>Verification and Validation are used interchangeably but have different definitions. <...
Verification(Reviews) <ul><li>Verification is the process confirming that -software process meets its specification </li><...
Validation <ul><li>Validation is the process confirming that it meets the user’s requirements. </li></ul>
Definitions <ul><li>Verification </li></ul><ul><ul><li>is the process of determining whether one phase of a software proce...
Software V&V Requirements Design Code System Test Integration Test Unit Test
Purpose of Review <ul><li>Detect defects earlier </li></ul><ul><li>Emphasize quality throughout development </li></ul><ul>...
Objectives <ul><li>Verify that specifications are satisfied </li></ul><ul><li>Verify conformance to standards </li></ul><u...
Need for Reviews Requirements Product Development
Need for Reviews Development Requirements Product Rework
Verification <ul><li>Use: </li></ul><ul><li>To identify defects in the product early in </li></ul><ul><li>the life cycle. ...
Types of Reviews <ul><li>Inprocess Review </li></ul><ul><li>Phase end/Decision Point/Milestone Review </li></ul><ul><li>Po...
<ul><ul><li>During a specific period of the   development cycle – like design period </li></ul></ul><ul><ul><li>Used to fi...
Decision-point & Phase-end <ul><ul><li>Review of products and processes near the completion of each phase of development. ...
<ul><ul><li>Also known as “Postmortems” </li></ul></ul><ul><ul><li>Review/evaluation of the product that   includes planne...
<ul><li>Informal Review (or) Peer review </li></ul><ul><li>Semiformal Review (or) Walk Through </li></ul><ul><li>Formal Re...
Informal <ul><ul><li>Also called peer-reviews  </li></ul></ul><ul><ul><li>Generally one-to-one meeting </li></ul></ul><ul>...
Semiformal <ul><ul><li>Facilitated by the author  </li></ul></ul><ul><ul><li>Presentation is made with comment    througho...
Formal Classes of Reviews <ul><ul><li>Facilitated by moderator  </li></ul></ul><ul><ul><li>Assisted by recorder </li></ul>...
Formal Review Team Members Classes of Reviews
<ul><li>The product is reviewed, not the producer </li></ul><ul><li>Defects and issues are identified, not corrected </li>...
Test Level Criteria's Entrance Criteria Exit Criteria
Special Test types <ul><li>Performance: </li></ul><ul><ul><li>the time taken to complete a task </li></ul></ul><ul><ul><li...
Performance test <ul><li>It is designed to test the run time performance of software. </li></ul><ul><li>It occurs througho...
Load <ul><li>The maximum number of users a system can support is called load.  </li></ul><ul><li>We feed it with all that ...
Stress <ul><li>Running the software under less conditions </li></ul><ul><li>Low memory, Low disk space and so on. </li></u...
Usability <ul><li>Determines how well the user will be able to understand and interact with the system. </li></ul><ul><li>...
<ul><li>Vendor Validation </li></ul><ul><li>this can be conducted jointly by software vendor and the testing team. </li></...
Benefits Realization Test <ul><li>It is a test or analysis conducted after an application is moved into production. </li><...
Configuration Testing <ul><li>This testing is performed find out the various supporting combinations of hardware and softw...
Recovery Testing <ul><li>It is nothing but a features built into the application for handling interruptions. </li></ul><ul...
Test Standards – Area 2 <ul><li>External Standards </li></ul><ul><ul><li>Familiarity with and adoption of industry test st...
External Standards <ul><li>IEEE </li></ul><ul><ul><li>Institute of Electrical and Electronics Engineers   </li></ul></ul><...
IEEE STANDARDS  That a Tester should be aware of <ul><li>610.12-1990 IEEE Standard Glossary of Software engineering </li><...
Internal Standards <ul><li>The use of Standards… </li></ul><ul><ul><li>Simplifies communication </li></ul></ul><ul><ul><li...
Upcoming SlideShare
Loading in …5
×

Verification & Validation

10,587 views

Published on

Published in: Technology, Business
  • Be the first to comment

Verification & Validation

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

×