160 likes | 692 Views
Software Testing: Verification and Validation. Verification “Are we building the product right?” Validation “Are we building the right product?” Barry Boehm, 1979. Verification and Validation Static techniques. Software Inspections of requirements documents
E N D
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
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
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
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
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
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
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
The Test Plan Ch.19 - Verification & Validation
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
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
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
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
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