Software Testing Strategies 2 Software Testing

  • View
    3.990

  • Download
    2

Embed Size (px)

Text of Software Testing Strategies 2 Software Testing

  • 1.Software Testing Strategies

2. Software Testing

  • Strategy
    • Integration of software test case design methods into a well-planned series of steps
      • Successful software construction
    • Provides a road map that describes
      • The steps to be conducted as part of testing
      • How much effort, time and resources will be required
    • Must incorporate test planning, test case design, test execution, and resultant data collection and evaluation

3. Software Testing

  • Strategy
    • Should be flexible enough to promote a customized testing approach
    • Must be rigid enough to promote reasonable planning and management tracking as the project progresses
    • Different test methods are beginning to cluster themselves into distinct approaches and philosophies

4. Software Testing

  • What is it?
    • To uncover errors
      • How do we conduct the test?
        • Do we develop a formal plan?
        • Should we test the entire program as a whole or run tests on a small part of it?
        • Should we rerun tests we have already conducted as we add new components to a large system?
        • When should we involve customer?
        • These questions must be answered when we develop a software testing strategy.

5. Software Testing

  • Who does it?
    • The strategy is developed by the project manager, software engineers, and testing specialists.
  • Why is it important
    • Testing often accounts for more project effort than any other software engineering activity
      • If conducted haphazardly
        • time is wasted
        • Unnecessary effort is expended
        • Errors sneak through undected

6. Software Testing

  • What are the steps?
    • Begins in the small and progresses to the large
      • Focus on a single component or a small group of related components
      • After components are tested they may be integrated until the complete system is constructed
      • As errors are uncovered, they must be diagnosed and corrected using a process that is called debugging

7. Software Testing

  • What is the work product?
    • A test specification document
      • Defining a plan that describes overall strategy
      • A procedure that defines specific testing steps and the tests that will be conducted
  • How do I ensure that Ive done it right?
    • By reviewing the Test specification prior to testing
    • Assess the completeness of test cases and testing tasks

8. Software Testing

  • A Strategic Approach
    • Testing is a set of activities that can be planned in advance and conducted systematically
      • Conduct effective formal technical reviews
      • Begin at the component level and work outward toward the integration of the entire computer-based system
      • Different testing techniques at different points in time
      • Usually conducted by the software developer and for large projects by an independent test group
      • Testing and debugging are different activities, but debugging must be accommodated in any testing strategy

9. Software Testing

  • Verification and Validation
    • Software testing is often referred to as V&V
      • Verification refers to the set of activities that ensures that software correctly implements a specific function
        • Are we building the product right?
      • Validation is a different set of activities that ensure that the software that has been built is traceable to customer requirements
        • Are we building the right product?

10. Software Testing

  • Verification and Validation
    • Encompass a wide array of Software Quality Assurance (SQA) activities including
        • Formal technical reviews
        • Quality and configuration audits
        • Performance monitoring
        • Simulation
        • Feasibility study
        • Documentation review
        • Database review
        • Algorithm analysis
        • Development, usability, installation testing

11. Software Testing

  • Organizing for Software Testing
    • Psychological point of view
      • The software engineer analyzes, models, and then creates a computer program and its documentation
        • From the software engineers perspective testing is destructive as it tries to break the thing that SE has built
      • There are often a number of misconceptions
        • The developer of the software should no do test
        • Software should be tossed over the wall to strangers who will test it mercilessly
        • Testers get involved with the project only when the testing steps are about to begin

12. Software Testing

  • Organizing for Software Testing
    • The role of the independent test group
      • Remove the inherent problems associated with letting the builder test the thing that has been built
      • Removes the conflict of interest
      • The software engineer, however, does turn the program over to the ITG and walk away; both have to work closely throughout the project
      • The developer must be available to correct uncovered errors

13. Software Testing

  • Strategy for conventional software architecture
    • Unit Testing
      • Concentrates on each unit (i.e. component) of the software as implemented in the source code
    • Integration Testing
      • Focus is on design and the construction of the software architecture
    • Validation Testing
      • Requirements are analysis are validated against the software that has been constructed
    • System Testing
      • Software and other elements are tested as a whole

14. Software Testing

  • Strategy for Object Oriented Architecture
    • Focus on testing in the small and work outward toward testing in the large
      • Testing in the small changes from an individual module to a class encompassing attributes and operations; implies communication and collaboration
      • A series of regression tests are run to uncover errors due to communication and collaboration between classes

15. Software Testing

  • Strategic Issues
    • Specify product requirements in a