1. IS4500 – SOFTWARE QUALITY ASSURANCE TESTING STRATEGIES Copyright © 2012 by Martin Schedlbauer, Ph.D. All Rights Reserved. Do Not Duplicate or Distribute Without Written Consent of the Author. www.neu.edu · m.schedlbauer@neu.edu

2. Objectives Upon completion of this chapter you will be able to: ◦ Differentiate between different testing approaches ◦ Appreciate the role of testing in different project lifecycles ◦ Use incremental approaches to testing v1.01 2 Solution Validation & Testing

3. Reality of Testing Most testers believe that it is their job to prove that a solution does not contain any defects. This is impossible; a program cannot be tested completely. ◦ There will always be some remaining defects. Testing is therefore a risk reducing activity. Reducing the risk to zero may be cost prohibitive. ◦ balance the cost with the amount of residual risk of defects one is willing to accept v1.01 3 Solution Validation & Testing

4. Workshop Activity v1.01 4 Solution Validation & Testing Goal: Understand the reality of testing. Time: 5 minutesFormat: Individually or in groups Materials: Whiteboard, flipchart, or paper Instructions: List at least three reasons why software solutions cannot be fully tested. Give examples.

5. Defect Clusters Software defects tend to be clustered. Finding one defect in some area of a solution will likely reveal additional defects in the same module. Why is this the case? v1.01 5 Solution Validation & Testing

6. Managing Defects Once defects are found, they need to be documented and then removed. But, removing the defects may not be feasible: ◦ Not enough time before release ◦ May cause other parts of solution to break ◦ Work-arounds are available Defects that remain in the solution are referred to as latent defects. v1.01 6 Solution Validation & Testing

7. Testing Approaches Two overall categories: ◦ Dynamic testing  Black box vs. white box ◦ Static testing Testing can check ◦ Functionality of services/behavior ◦ Quality of service Testing presumes that there is a specification of expected behavior. v1.01 7 Solution Validation & Testing

8. Exploratory vs. Predictive Testing Testing presumes that there is a specification based on stakeholder requirements. The specification is used to create appropriate test cases and scenarios. In the absence of specifications or requirements documentation, testers may choose to conduct exploratory testing. Exploratory testing is an ad hoc testing approach that uses the intuition of the tester and principally looks for possible failures of the solution. v1.01 8 Solution Validation & Testing

9. Incremental Testing Testing should be done incrementally from smallest to largest. v1.01 9 Solution Validation & Testing

10. Taxonomy of Testing Approaches v1.01 10 Solution Validation & Testing

11. Workshop Activity v1.01 11 Solution Validation & Testing Goal: Define testing approaches and testing terms. Time: 10 minutesFormat: Individually or in groups Materials: Whiteboard, flipchart, or paper Instructions: Define the following testing terms. For each term, specify if the approach is in use in your organization and if you have used it.

12. Lifecycle Methodologies A lifecycle methodology guides the team during the development of the system and prescribes activities and deliverables. Most organizations have their own internally developed methods that leverage industry best practices. Project lifecycle methodologies can be broadly classified into two extremes: ◦ sequential and iterative methods. v1.01 12 Solution Validation & Testing

13. Sequential Lifecycle Model v1.01 13 Solution Validation & Testing

14. Iterative/Agile Lifecycle Model v1.01 14 Solution Validation & Testing

15. Summary In this module we learned that: ◦ Testing is a risk-based activity and limited which implies that not all defects can be found ◦ Testing is an iterative and incremental endeavor ◦ Project lifecycles determine when, how, and to what extent testing is done ◦ Testing is done on the static code and the running solution ◦ User acceptance testing requires well-define acceptance criteria that must be defined when the requirements are documented 15 Solution Validation & Testing v1.01