Introduction Outline

Transcription

1 Outline These slides are distributed under the Creative Commons License. In brief summary, you may make and distribute copies of these slides so long as you give the original author credit and, if you alter, transform or build upon this work, you distribute the resulting work only under a license identical to this one. For the rest of the details of the license, see Introduction 2002 Amland Consulting 1-1

2 Outline Introduction ET Planning, Exec. and Introduction to testing. What is Exploratory Testing? Where to use it? When to use it? Introduction to Risk Introduction 2002 Amland Consulting 1-2

3 Introduction 1.1 Introduction to testing thinking like a tester 1.2 Introduction to Exploratory Testing 1.3 Introduction to Risk and Risk-Based Testing Introduction 2002 Amland Consulting 1-3

4 Different testing approaches 1. Skeptical approaches 2. Analytical approaches 3. Information-driven approaches 4. Time-honored but less effective approaches 5. Experiential and intuitive approaches 6. And? Ross Collard (2002) Introduction 2002 Amland Consulting 1-4

5 Different testing approaches (1) Skeptical approaches In God We Trust, Everything Else We Test! The barbarians (software engineers) are at the gate Let s use a scatter gun to test with, and see what bugs we hit Ross Collard (2002) Introduction 2002 Amland Consulting 1-5

6 Different testing approaches (2) Analytical approaches Let s analyze the functional specs. to understand the system s expected behavior Let s develop a model of the system, and then use this conceptual model as a basis for testing Let s derive the test cases by analyzing the description logic, process flows, equivalence classes, changes of state, or input combinations, etc. Ross Collard (2002) Introduction 2002 Amland Consulting 1-6

7 Different testing approaches (3) Information-driven approaches Let s focus the depth and intensity of the testing in the high risk areas, based on the perceived threats and vulnerabilities of the system Let s follow this bug list or check list in our testing Let s go ask the software engineers what to test, because they know how the system works Let s look under the hood and read the code Let s follow the clients direction, because they have the final sign-off authority Ross Collard (2002) Introduction 2002 Amland Consulting 1-7

8 Different testing approaches (4) Time-honored but less effective approaches Let s follow the book We always do it this way You shouldn t change that features because it will screw up our testing. The tail wags the dog. Testing is easy, or at least a lot easier than software design, programming and maintenance. Anyone can do testing Errors just happen. They are caused by bad luck. Ross Collard (2002) Introduction 2002 Amland Consulting 1-8

9 Different testing approaches (5) ManagementExperiential and intuitive approaches ET Let s think blue-sky, speculate and follow our intuition. We have good hunches about where the bugs are lurking. Let s jump in an explore the system s behavior hands-on, so we can decide how to test it. Let s find the important bugs fast, and worry about the test paperwork later. Ross Collard (2002) Introduction 2002 Amland Consulting 1-9

10 Different testing approaches Exploratory Testing Let s explore, design the tests and test the system concurrently (James Bach) Let s learn about the system, test it and reports bugs as we go (Cem Kaner) Let s structure and document our creative testing so we know where we have been Let s apply everything we have learned about testing as we learn about the system, let s do thinking-while-testing! Introduction 2002 Amland Consulting 1-10

11 What s Special about a Tester s Brain? Introduction 2002 Amland Consulting 1-11

12 Epistemology the Study of Knowledge Epistemology is the study of how we know what we know. The philosophy of science belongs to Epistemology. All good testers practice Epistemology. From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-12

13 Basic Skills of Epistemology Ability to pose useful questions. Ability to observe what s going on. Ability to describe what you perceive. Ability to think critically about what you know. Ability to recognize and manage bias. Ability to form and test conjectures. Ability to keep thinking despite already knowing. Ability to analyze someone else s thinking. From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-13

14 Tunnel-Vision is Our Great Occupational Hazard invisible problems Problems you can find with your biases invisible problems From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-14

15 A Tester s Attitude Cautious Jump to conjectures, not conclusions. Practice admitting I don t know. Have someone check your work. Curious What would happen if? How does that work? Why did that happen? Critical Proceed by conjecture and refutation. Actively seek counter-evidence. Good testers are hard to fool. From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-15

16 To improve our judgement and skills : Heuristics: A heuristic is a fallible method for finding the solution to a problem. It's essentially a plausible guess, or a mechanism that helps generate plausible guesses. James Bach, james@satisfice.com Introduction 2002 Amland Consulting 1-16

17 Heuristics continued: 5. "Avoid driving while intoxicated, because there is an elevated danger of an accident" is a heuristic. "Never drive when intoxicated" is, by contrast, a rule. James Bach, james@satisfice.com Introduction 2002 Amland Consulting 1-17

18 Testing is done in Context 1. The value of any practice depends on its context. 2. There are good practices in context, but there are no best practices. 3. People, working together, are the most important part of any project's context. 4. Projects unfold over time in ways that are often not predictable. 5. The product is a solution. If the problem isn't solved, the product doesn't work. 6. Good software testing is a challenging intellectual process. 7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products. Introduction 2002 Amland Consulting 1-18

19 Exercise: The Triangle Program Specification: This program takes three numbers as input. The numbers represent the dimensions of a triangle. When you click on the check button, the program tells you what kind of triangle the sides represent: scalene (no side equal to any other) isosceles (two sides are equal) equilateral (all sides are equal) Please test this program. From Black Box Software Testing, copyright Cem Kaner Introduction 2002 Amland Consulting 1-19

20 Example tests: The Triangle Program Example of tests or groups of tests: Test case for a valid equilateral triangle At least three test cases that represent valid isosceles triangles (all permutations, e.g. 3,3,4; 3,4,3; 4,3,3) Test case in which one side has a zero value See Meyer s Answer in his book Myers 1979, page 3. Introduction 2002 Amland Consulting 1-20

21 Introduction 1.1 Introduction to testing thinking like a tester 1.2 Introduction to Exploratory Testing 1.3 Introduction to Risk and Risk-Based Testing Introduction 2002 Amland Consulting 1-21

22 What is Exploratory Testing? "Exploratory testing involves simultaneously learning, planning, running tests, and reporting / troubleshooting results." Dr. Cem Kaner (2001) "Exploratory testing is an interactive process of concurrent product exploration, test design and test execution. To the extent that the next test we do is influenced by the result of the last test we did, we are doing exploratory testing. James Bach, Satisfice (2001) Introduction 2002 Amland Consulting 1-22

23 Said about extreme Programming Agile software development is not conventional software development done more quickly or done on tippie-toe. Agile software development is software done differently. Ron Jeffries, ( on agile-testing list, April 24, 2002) proven (no single technique is new) application oriented planned and disciplined controllable and reliable risk minimizing Two sides of extreme programming: for the developer: freedom, flexibility, fun for the manager: controllability, reliability, high quality Martin Lippert (University of Hamburg), ICSTEST 2002 Introduction 2002 Amland Consulting 1-23

24 The extreme Programming and Exploratory Testing Analogy: Agile software testing is not conventional (scripted) software testing done more quickly or done on tippie-toe. Exploratory Testing: proven (no single technique is new) application oriented planned and disciplined controllable and reliable risk minimizing Two sides of Exploratory Testing: for the tester: freedom, flexibility, fun for the manager: controllability, reliability, high quality Introduction 2002 Amland Consulting 1-24

25 ET vs. Scripted Testing Fully Scripted Testing Exploratory Testing Ad-hoc Testing Automated Tests Bug Hunting Jarle Våga (2002) Introduction 2002 Amland Consulting 1-25

26 What is Scripted Testing? Small (but realistic) example: How to script and test this login? (Functional tests only not security!) Introduction 2002 Amland Consulting 1-26

27 Sample test scripts (4 of many ): Sample test script 1: Launch the Login screen Enter User-id: xyz Enter Password: zyx Press <Enter> Expected result: login ok Sample test script 2: Launch the Login screen Enter User-id: xyz Enter Password: zyx Click the Login button Expected result: login ok Sample test script 3: Launch the Login screen Enter User-id: Enter Password: zyx Press <Enter> Expected: login rejected Sample test script 4: Launch the Login screen Enter User-id: Enter Password: zyx Click the Login button Expected: login rejected Introduction 2002 Amland Consulting 1-27

28 Sample Generic Scripts (2 of many ) Sample generic test script 1: Launch the Login screen Enter valid User-id Enter valid Password Press <Enter> or click button Expected result: login ok Sample generic test script 2: Launch the Login screen Enter invalid User-id Enter valid Password Press <Enter> or click button Expected result: login rejected Introduction 2002 Amland Consulting 1-28

29 Sample test Pattern script (checklist) Input fields: Valid data Invalid data Length > max Length = max +1 Length = max Length = max 1 Combinations of above Actions: Keyboard Buttons Operations: Add, Modify, Inquiry, Delete What to test for each Introduction 2002 Amland Consulting 1-29

30 When to use Exploratory Testing? (1) A common goal of exploration is to probe for weak areas of the program. Test team s resource consumption per week: 25% of the group s time developing new tests 50% executing old tests (including bug regression) 25% on exploratory testing Cem Kaner (2001a) Introduction 2002 Amland Consulting 1-30

31 When to use Exploratory Testing? (2) When there is little or no specifications and / or requirements When you have little or no domain knowledge When you don t have time to specify, script and test Uncertainty and Time Pressure! Introduction 2002 Amland Consulting 1-31

32 When to use Exploratory Testing? (3) Exploratory Testing is extremely useful when faced with software that is Untested Unknown or Unstable The tester must create a map of the application as he goes on testing it. Harry Robinson, Introduction 2002 Amland Consulting 1-32

33 When to use Exploratory Testing? (4) Take a more scripted approach when: There are little uncertainty about how to test New tests are relatively unimportant The need for efficiency and reliability in executing tests is worth the effort of scripting We are prepared to pay the cost of documenting and maintaining tests From Black Box Software Testing, copyright Cem Kaner Introduction 2002 Amland Consulting 1-33

34 The Fallacy of Repeated Tests: Clearing Mines mines From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-34

35 Totally Repeatable Tests Won t Clear the Minefield mines fixes From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-35

36 Variable Tests are Therefore More Effective mines fixes From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-36

37 Sample Product Test Cycle 1. Receive the product. Formal builds Informal builds Save old builds. 2. Clean your system. Completely uninstall earlier builds. 3. Verify testability. Smoke testing Suspend test cycle if the product is untestable. 4. Determine what is new or changed. Change log 5. Determine what has been fixed. Bug tracking system 6. Test fixes. Many fixes fail! Also test nearby functionality. 7. Test new or changed areas. Exploratory testing. 8. Perform regression testing. Not performed for an incremental cycle. Automated vs. manual Important tests first! 9. Report results. Coverage Observations Bug status (new, existing, reopened, closed) Assessment of quality Assessment of testability From Rapid Software Testing, copyright James Bach Introduction 2002 Amland Consulting 1-37

38 Introduction 1.1 Introduction to testing thinking like a tester 1.2 Introduction to Exploratory Testing 1.3 Introduction to Risk and Risk-Based Testing Introduction 2002 Amland Consulting 1-38

39 No Risk? No Test! Introduction 2002 Amland Consulting 1-39

40 Typical Questions for Testers How much testing is enough? When should we stop testing? When is the product good enough for release? How good is our testing? Managing RISK! Introduction 2002 Amland Consulting 1-40

41 Product Quality and test coverage 100% Poor Perfect! Quality Risk Coverage (potential faults) Worst Good Customer use Coverage 100% Rex Black 1999 Introduction 2002 Amland Consulting 1-41

42 Introduction Summary Introduction ET Planning, Exec. and Introduction to Testing. What is Exploratory Testing? Where to use it? When to use it? Introduction to Risk Introduction 2002 Amland Consulting 1-42