Verification & Validation


Published on

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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>