1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 17 Software Testing Techniques

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Motivation A PUZZLE A PUZZLE

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Problem  There is a closed room with a lamp off inside the room  There are three switches (A,B,C) outside the room and next to the door, but only one control the lamp (turn it on and off)  Your task is to find out which switch is the one which controls the lamp  Restrictions:  You cannot see inside the room to see if the lamp is on or off.  You can turn on/off the switches as many times as you want to.  You are allowed to open the door once to help you decide which switch is the right one. OF COURSE, after you open the door you cannot touch the switches any more.  You can use as much time as you want, however the less time you use the better you solution is.

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 A B C

6. 6 The Problem  There is a closed room with a lamp off inside the room  There are three switches (A,B,C) outside the room and next to the door, but only one control the lamp (turn it on and off)  Your task is to find out which switch is the one which controls the lamp  Conditions:  You cannot see inside the room to see if the lamp is on/off.  You can turn on/off the switches as many times as you want to.  You are allowed to open the door once to help you decide which switch is the right one. OF COURSE, after you open the door you cannot touch the switches any more.  You can use as much time as you want, however the less time you use the better you solution is

7. 7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Brute Force Solution  Get heaps of hamburgers  Pay attention to any sound  Turn on/off every switch in order  Until one of them blow the lamp, you will hear a noise  That switch control the lamp.  How long will take you?  Depend on the lamp quality. Any way, most lamps last more 1000 hours.

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Smart solution  Turn on any switch ( A)  Wait a couple minutes, eat your hamburger  Turn on other switch (B) and  Immediately open the door  Look at the lamp  Is the lamp off?  The switch is C  Is the lamp on  TOUCH IT  It is COLD ( and ON) The switch is BThe switch is B  It is WARN (and ON) The switch is AThe switch is A  How much time did it take?

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 What did we learn?  Applying brute force restlessly will solve the problem eventually.  However using your brain, will produce a better, cheaper and faster solution most of the time.  Testing is not the exception  You may apply restlessly test cases and eventually you will catch an error  However, if you are smart enough you can get the same results in less time and effort.

10. 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Testing Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.

11. 11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Testability  Operability—it operates cleanly  Observability—the results of each test case are readily observed  Controlability—the degree to which testing can be automated and optimized  Decomposability—testing can be targeted  Simplicity—reduce complex architecture and logic to simplify tests  Stability—few changes are requested during testing  Understandability—of the design

12. 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 What Testing Shows errors requirements conformance performance an indication of quality

13. 13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Who Tests the Software? developer independent tester Understands the system but, will test "gently" and, is driven by "delivery" Must learn about the system, but, will attempt to break it and, is driven by quality

14. 14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Exhaustive Testing loop < 20 X There are 10 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! 14

15. 15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Selective Testing loop < 20 X Selected path

16. 16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Testing Methods Strategies white-box methods black-box methods

17. 17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Test Case Design "Bugs lurk in corners and congregate at boundaries..." Boris Beizer OBJECTIVE CRITERIA CONSTRAINT to uncover errors in a complete manner with a minimum of effort and time

18. 18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 White-Box Testing... our goal is to ensure that all statements and conditions have been executed at least once...

19. 19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why Cover? logic errors and incorrect assumptions are inversely proportional to a path's execution probability we often believe that a path is not that a path is not likely to be executed; in fact, reality is often counter intuitive typographical errors are random; it's likely that untested paths will contain some

20. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Basis Path Testing First, we compute the cyclomatic complexity: number of simple decisions + 1 or number of enclosed areas + 1 In this case, V(G) = 4

21. 21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. V(G) modules modules in this range are more error prone

22. 22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Basis Path Testing Next, we derive the independent paths: Since V(G) = 4, there are four paths Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8 Finally, we derive test cases to exercise these paths. 1 2 3 4 56 7 8

23. 23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Basis Path Testing Notes you don't need a flow chart, but the picture will help when you trace program paths count each simple logical test, compound tests count as 2 or more basis path testing should be applied to critical modules

24. 24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Loop Testing NestedLoops Concatenated Loops Unstructured Loops Simpleloop

25. 25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Loop Testing: Simple Loops Minimum conditions—Simple Loops 1. skip the loop entirely 2. only one pass through the loop 3. two passes through the loop 4. m passes through the loop m < n 5. (n-1), n, and (n+1) passes through the loop where n is the maximum number of allowable passes

26. 26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Loop Testing: Nested Loops Start at the innermost loop. Set all outer loops to their minimum iteration parameter values. Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their minimum values. Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until the outermost loop has been tested. If the loops are independent of one another then treat each as a simple loop then treat each as a simple loop else* treat as nested loops else* treat as nested loops endif* for example, the final loop counter value of loop 1 is used to initialize loop 2. Nested Loops Concatenated Loops

27. 27 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Black-Box Testing requirements events input output

28. 28 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Equivalence Partitioning Every element in the class shares the same procedure

29. 29 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Boundary Value Analysis input domain

30. 30 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Other Black Box Techniques  error guessing methods  decision table techniques  cause effect graphing

31. 31 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 18 Software Testing Strategies

32. 32 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Testing Strategy unit test integrationtest validationtest systemtest

33. 33 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Unit Testing module to be tested test cases results softwareengineer

34. 34 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Unit Testing interface local data structures boundary conditions independent paths error handling paths module to be tested test cases

35. 35 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Unit Test Environment Module stub stub driver RESULTS interface local data structures boundary conditions independent paths error handling paths test cases

36. 36 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Integration Testing Strategies Options: the “big bang” approachthe “big bang” approach an incremental construction strategyan incremental construction strategy

37. 37 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Top Down Integration top module is tested with stubs stubs are replaced one at a time, "depth first" as new modules are integrated, some subset of tests is re-run A B C DE FG

38. 38 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Bottom-Up Integration drivers are replaced one at a time, "depth first" worker modules are grouped into builds and integrated A B C DE FG cluster

39. 39 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Sandwich Testing Top modules are tested with stubs Worker modules are grouped into builds and integrated A B C DE FG cluster

40. 40 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 High Order Testing validation test system test alpha and beta test other specialized testing

41. 41 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Usability Testing  What it is?  It is a technique for ensuring that the intended users of a system can carry out the intended tasks efficiently, effectively and satisfactorily  How should be done?  A well planned session where a group of users (1-5) will be introduced to the software and asked to perform some activities.  There is a host tester  The users will be observed(recorded)  Most than one session may be required  The functionality is there. Can the user reach it easily?

42. 42 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Debugging: A Diagnostic Process

43. 43 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Debugging Process test cases results Debugging suspectedcauses identifiedcauses corrections regressiontests new test cases

44. 44 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Debugging Effort time required to diagnose the symptom and determine the cause time required to correct the error and conduct regression tests

45. 45 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Symptoms & Causes symptom cause symptom and cause may be geographically separated symptom may disappear when another problem is fixed cause may be due to a combination of non-errors cause may be due to a system or compiler error cause may be due to assumptions that everyone believes symptom may be intermittent

46. 46 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Consequences of Bugs damage mild annoying disturbing serious extreme catastrophic infectious Bug Type Bug Categories: function-related bugs, function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc.

47. 47 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Debugging Techniques brute force / testing backtracking induction deduction

48. 48 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Debugging: Final Thoughts Don't run off half-cocked, think about the about the symptom you're seeing. Use tools (e.g., dynamic debugger) to gain (e.g., dynamic debugger) to gain more insight. If at an impasse, get help from someone else. from someone else. Be absolutely sure to conduct regression tests when you do "fix" the bug. 1. 2. 3. 4.

49. 49 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 23 Object-Oriented Testing

50. 50 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Strategy  class testing is the equivalent of unit testing  operations within the class are tested  the state behavior of the class is examined  integration applied three different strategies  thread-based testing—integrates the set of classes required to respond to one input or event  use-based testing—integrates the set of classes required to respond to one use case  cluster testing—integrates the set of classes required to demonstrate one collaboration

51. 51 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT—Test Case Design Berard [BER93] proposes the following approach: 1.Each test case should be uniquely identified and should be explicitly associated with the class to be tested, 2.The purpose of the test should be stated, 3.A list of testing steps should be developed for each test and should contain [BER94]: a.a list of specified states for the object that is to be tested b.a list of messages and operations that will be exercised as a consequence of the test c.a list of exceptions that may occur as the object is tested d.a list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test) e.supplementary information that will aid in understanding or implementing the test.

52. 52 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Methods: Random Testing  Random testing  identify operations applicable to a class  define constraints on their use  identify a miminum test sequence  an operation sequence that defines the minimum life history of the class (object)  generate a variety of random (but valid) test sequences  exercise other (more complex) class instance life histories

53. 53 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Methods: Partition Testing  Partition Testing  reduces the number of test cases required to test a class in much the same way as equivalence partitioning for conventional software  state-based partitioning  categorize and test operations based on their ability to change the state of a class  attribute-based partitioning  categorize and test operations based on the attributes that they use  category-based partitioning  categorize and test operations based on the generic function each performs

54. 54 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Methods: Inter-Class Testing  Inter-class testing  For each client class, use the list of class operators to generate a series of random test sequences. The operators will send messages to other server classes.  For each message that is generated, determine the collaborator class and the corresponding operator in the server object.  For each operator in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits.  For each of the messages, determine the next level of operators that are invoked and incorporate these into the test sequence