Your SlideShare is downloading. ×
Software Testing - Verification
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software Testing - Verification

599

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
599
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Testing: Verification and Validation
    • Verification “Are we building the product right?”
    • Validation “Are we building the right product?”
    • Barry Boehm, 1979
  • 2. Verification and Validation Techniques
    • Static Techniques
      • Software Inspections (against source code)
    • Dynamic Techniques
      • Software Testing (requires executable program)
  • 3. Verification and Validation Static techniques
    • Software Inspections
      • of requirements documents
      • of design documents ( design reviews )
      • of source code ( code reviews )
      • automated static analysis
  • 4. Verification and Validation Dynamic techniques
    • Software Testing
      • specification vs. implementation
        • Defect testing [Ch.20]
      • verifying non-functional requirements ( e.g. performance; reliability)
        • Statistical testing [Ch.21]
      • automated dynamic analysis (if applicable)
  • 5. Verification and Validation Goals
    • Establish that software is fit for purpose, not “bug-free”
    • “Good enough” depends on:
      • Software function (critical nature?)
      • User expectations
      • Market
        • competition, price
  • 6. Testing vs. Debugging
    • Verification and Validation
      • looking and categorizing existence of system defects [ example ] [ bug list ]
      • “ What?”
    • Debugging
      • locating and correcting these defects
      • “ Why?”
  • 7.
    • Canned test runs to verify that new defects were not introduced during “debugging” session.
    • Not exhaustive
    • Targeted to a particular interface
      • components, sub-systems, integrated system
    • Different levels (lengths) of regression tests
      • Targeted regressions
    Regression Testing
  • 8.
    • Planning should begin right after requirements specification
      • Acceptance tests can be written then
    • System, sub-system tests can be written against designs
    The Test Plan
  • 9. The Test Plan
  • 10. 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]
      • (We’ll talk about Cleanroom later)
  • 11. 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
        • inspectors are skilled programmers
    • Common practice: code reviews and then acceptance testing
      • reviews can also help with development of tests
  • 12. 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
      • During meeting, directives recorded by Scribe
      • Testers/documenters attend too
  • 13. 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)
  • 14. 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 , BoundsChecker

×