software testing verification and validation n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Testing: Verification and Validation PowerPoint Presentation
Download Presentation
Software Testing: Verification and Validation

play fullscreen
1 / 13

Software Testing: Verification and Validation

251 Views Download Presentation
Download Presentation

Software Testing: Verification and Validation

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Testing: Verification and Validation • Verification“Are we building the product right?” • Validation “Are we building the right product?” Barry Boehm, 1979 Ch.19 - Verification & Validation

  2. Verification and ValidationStatic techniques • Software Inspections • of requirements documents • of design documents (design reviews) • of source code (code reviews) • automated static analysis Ch.19 - Verification & Validation

  3. Verification and ValidationDynamic techniques • Software Testing • executing implementation against test data • verifying non-functional requirements (e.g. performance; reliability) • Defect testing • implementation vs. specification [Ch.20] • Statistical testing • performance and reliability [Ch.21] Ch.19 - Verification & Validation

  4. Verification and ValidationGoals • Establish that software is fit for purpose,not “bug-free” • “Good enough” depends on: • Software function (critical nature) • User expectations • Market • competition, price Ch.19 - Verification & Validation

  5. Testing vs. Debugging • Verification and Validation • looking and categorizing existence of system defects [example] [bug list] • “What?” • Debugging • locating and correcting these defects • “Why?” Ch.19 - Verification & Validation

  6. Regression Testing • Canned test runs to verify that new defects were not introduced during “debugging” session. • Not exhaustive • Different levels (lengths) of regression tests • Targeted regressions Ch.19 - Verification & Validation

  7. The Test Plan • Planning should begin right after requirements specification • Acceptance tests can be written then • System, sub-system tests can be written against designs Ch.19 - Verification & Validation

  8. The Test Plan Ch.19 - Verification & Validation

  9. Software Inspections (code reviews) • >60% of program errors can be detected in code review [Fagan86] • >90% if more formal approach used (e.g. “Cleanroom” process) [Mills87] Ch.19 - Verification & Validation

  10. Software Inspections (code reviews) • Why are reviews more effective for finding defects in systems/subsystems (i.e., before acceptance testing)? • Bugs are often masked by other bugs • Leverage domain/programming knowledge • Common practice: code reviews and then acceptance testing • reviews can also help with development of tests Ch.19 - Verification & Validation

  11. Software Inspections (code reviews) • Sample procedure: • Announce review meeting in advance (a week?) • Provide design document, implementation overview, and pointer to code • Reviewers read code (and make notes) in advance of meeting • Testers/documenters attend too Ch.19 - Verification & Validation

  12. Automated Static Analysis • CASE tools that catch program curiosities that are usually indicative of bugs: • unreachable code • uninitialized variables • unreferenced variables • Programming language dependent • e.g., LINT (for C) Ch.19 - Verification & Validation

  13. Automated Dynamic Analysis • Tools which do bookkeeping while program is run/tested. • Can find some dynamic problems that compiler cannot catch (depends on language…) • C/C++ tools: Purify Ch.19 - Verification & Validation