Exploratory Testing Workshop in Risk-Based Agile Testing

1,082 views
1,027 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,082
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
58
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Fasinerende klokke: den har tall fra 3, 6, 9 osv. Til 30??!? Likner på den som Normannen solgte på postordre til Sverige; watch sold on mail order to Sweden with hands painted on the front.
  • Introduction to testing in GENERAL Exploratory Testing Risk and Risk-Based Testing
  • Is this how we LIKE to test?
  • My FAVOURITE?
  • This includes EXPLORATORY TESTING!?
  • (from Cambridge International Dictionary of English) conjecture ANTAKELSE / HYPOTESE verb, noun   (to form) a guess or judgment, based on the appearance of a situation rather than on proof   We'll never know exactly how she died. We can only conjecture.   [I] He conjectured that the company would soon be in financial difficulties.   [+ that clause] There's been a lot of conjecture in the papers recently about the royal marriage.   [U] It's pure conjecture. Nobody knows the facts.   [U] conjectural adjective   refute “BEVIS” verb   [T]   FORMAL OR LAW   to say or prove that (a person, statement, opinion, etc.) is wrong or false   to refute a person/theory/argument The barrister used new evidence to refute the charges and clear the defendant. refutation noun   [C/U]   FORMAL OR LAW  
  • Major problem with ET?
  • (from Cambridge International Dictionary of English ) conjecture verb, noun   (to form) a guess or judgment, based on the appearance of a situation rather than on proof   We'll never know exactly how she died. We can only conjecture.   [I] He conjectured that the company would soon be in financial difficulties.   [+ that clause] There's been a lot of conjecture in the papers recently about the royal marriage.   [U] It's pure conjecture. Nobody knows the facts.   [U] conjectural adjective   refute verb   [T]   FORMAL OR LAW   to say or prove that (a person, statement, opinion, etc.) is wrong or false   to refute a person/theory/argument The barrister used new evidence to refute the charges and clear the defendant. refutation noun   [C/U]   FORMAL OR LAW   Når man skal utforske Funksjonalitet kan man Ikke være for bastant! Antakelse  motbevise
  • Fra: "James Bach" <james@satisfice.com> Til: <stale@amland.no> Dato: Sat, 17 Aug 2002 15:27:26 -0400 Emne: RE: Context-sensitive skills and Heuristics Hi Stale, I'm speaking of heuristic the way the term is used in AI, Psychology, and Philosophy. 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. "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. The difference between them is that we relate to heuristics as a tool to apply; something that might help us do the right thing in a given situation, whereas we relate to a rule as something to comply with; something that defines right behavior. Using heuristics properly requires that you exercise discretion and judgment, on some level; whereas judgment may get in the way of rules. It's helpful to have contradictory heuristics, because that's like having a variety of advice available before making a decision; whereas contradictory rules make compliance impossible. -- James
  • See previous Note-page for reference to James Bach: ” The difference between them is that we relate to heuristics as a tool to apply; something that might help us do the right thing in a given situation, whereas we relate to a rule as something to comply with; something that defines right behavior. ”
  • Cem Kaner Black Box Testing: Testing is done in context Rather than looking for The One True Way to run a test group, we should recognize that the testing group is a service organization and that its work is done in a context. Life cycles, testing group missions, testing techniques must fit within the overall organization. We should look at / for relevant factors (perform a requirements analysis ) to guide our decisions.
  • Scalene = skjev, isosceles = likebent, equilateral = likesidet Several classes of issues were missed by most students. For example: Few students checked whether they were producing valid triangles. (1,2,3) and (1,2,4) cannot be the lengths of any triangle. Knowledge of the subject matter of the program under test will enable you t ocreate test cases that are not directlu suggested by the specification. If you lack that knowledge , you will miss key tests. (This knowledge is sometimes called “domain knowledge”, not to be confused with “domain testing”) Few students checked non-numeric values, bad delimiters, or non-integers The only boundaries tested were at MaxInt or 0 Myer’s Answer: Test case for a valid scalene triangle Test case for a valid equilateral triangle Three test cases for valid isosceles triangles (a=b, b=c, a=c) One, two or three sides has zero values (5 cases) One side has a negative Sum of two numbers equals the third (e.g. 1,2,3) is invalid b/c not a triangle (tried with 3 permutations a+b=c, a+c=b, b+c=a) Sum of two numbers is less than the third (e.g. 1,2,3) (3 permutations) Non-integer Wrong number of values (too many, too few)
  • En ANALOGI for å forklare ET!! Kjenner deltakerne til XP?? en “revolusjon” innen systemutvikling sammenliknet med tradisjonell “krav og spesifikasjons”-drevet (vannfalls)utvikling med fokus på små grupper, intern kommunikasjon, mindre dokumentasjon Analogi – likhet: XP vs. WaterFall ET vs. Scripted Testing
  • En ANALOGI for å forklare ET!! ET er IKKE tilfeldig Planned and Disciplined
  • Version 1 – positive tests: Input: Enter a valid User-id Enter av valid Password Press Enter or click login Expected Output: The system will log you in and display main menu Version 2 – posistive tests: Enter User-id = AMLAND Enter Password = OK123 Press Enter Expected Output: The system will log you in and display main menu Negative tests – even worse: General version: Enter combinations of negative user-id/ password with the other input as valid input. Or extremely detailed input……(for automation).
  • Ask participants about how detailed their test scripts are? How good are they? What kind of errors do they NOT find?
  • Just like ordinary Explorers; after a trip they prepare maps and detailed descriptions of the country they traveled through.
  • Posted to software-testing@ yahoogroups .com by James Bach, July 14, 2001. Stale Amland saw me do the ”minefield” exercise in a testing class and asked me to write a concise description of the reasoning behind it. (I’m also looking for comments, because I want to get this right.) Heuristic: It’s better to vary tests than to repeat the same tests. Minefield analogy: Finding problems in a product is like looking for mines in a minefield. If you’re trying to clear a minefield, you can’t do it by traveling the same line through it over and over again. That’s how you avoid finding mines. Take different paths through the field and you’ll cover it better. Varying tests is better than repeating tests, because testing is a sampling process, and you get a larger sample of the product when you vary the tests. Since a test is a question that you’re asking the product, why ask the same questions over and over again? Although varying tests is a powerful idea. Depending on the situation, there may be reasons to avoid variation. I know of six distinct reasons. A thoughtful tester is aware of these issues, and makes a reasoned judgment about when to vary tests and when to keep them the same. Seven Caveats to Always-Vary-Tests You might rationally repeat tests... 1. if there is a substantially greater probability of a problem happening in an area that is exercised by the tests, compared to other areas. The distribution of problems across a product space is not necessarily uniform. 2. if any problem that could be discovered by those tests is likely to have substantially more importance than problems in other areas. The distribution of the importance of product behavior is not necessarily uniform. 3. if they have some value and are sufficiently inexpensive compared to the cost of new and different tests. New tests may still be vitally important for the test effort, however. 4. if the tests you repeat represent the only tests that seem worth doing. This is the virus scanner argument: maybe a repeated virus scan is okay, instead of constantly changing virus tests. However, sometimes we introduce variation because we aren’t sure what tests truly are worth doing. 5. if variation of tests is specifically prohibited by contract or regulation. In other words, the point of your testing may not be to find problems. 6. if the repeated tests comprise a performance standard that gets its value by comparison with previous executions of the same exact tests. When historical test data is used as an oracle, then you must take care that the tests you perform are comparable to the historical data. Holding tests constant may not the only way to make results comparable, but it can be the best choice available. 7. when the discovery of bugs is probablistic, perhaps due to important variables involved that you can’t control in your tests. Performing a test that is, to you, exactly the same as a test you’ve performed before, may result in discovery of a bug that was always there but not revealed until the uncontrolled variables line up in a certain way. This is the same reason that a gambler at a slot machine has for playing again after losing the first time. Non-uniform distribution Non-uniform importance Cheap Virus scan Contract Standard Gambling
  • Put ET into the BIG Picture! The Product Testing will NOT be discussed in this workshop.
  • Introduction to testing Different testing approaches Basic skills as a tester – a testers attitude Context-driven testing Objectives What is Exploratory Testing? Concurrent Product Exploration Test Design Test Execution Where to use it? As part of product testing When to use it? When there is high uncertainty When creating new tests is important When high reliability and MTBF is not main focus 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 Introduction to Risk A risk is an unwanted event that has negative consequences. 2 types of risk: Project / process risk Business / Product risk
  • Exploratory Testing Workshop in Risk-Based Agile Testing

    1. 1. Introduction Outline <ul><li>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 http://creativecommons.org/licenses/by-sa/2.0/legalcode . </li></ul>
    2. 2. Introduction Outline Introduction Test Management and Techniques ET Planning , Exec . and Documentation ET Styles ET Management <ul><li>Introduction to testing. </li></ul><ul><li>What is Exploratory Testing? </li></ul><ul><li>Where to use it? </li></ul><ul><li>When to use it? </li></ul><ul><li>Introduction to Risk </li></ul>5. 4. 3. 2. 1.
    3. 3. 1. 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 1. 2. 3. 4. 5.
    4. 4. Different testing approaches <ul><li>Skeptical approaches </li></ul><ul><li>Analytical approaches </li></ul><ul><li>Information-driven approaches </li></ul><ul><li>Time-honored but less effective approaches </li></ul><ul><li>Experiential and intuitive approaches </li></ul><ul><li>And…? </li></ul>Ross Collard (2002) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    5. 5. Skeptical approaches <ul><li>“ In God We Trust, Everything Else We Test!” </li></ul><ul><li>“ The barbarians (software engineers) are at the gate” </li></ul><ul><li>“ Let’s use a scatter gun to test with, and see what bugs we hit” </li></ul>Ross Collard (2002) Different testing approaches (1) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    6. 6. Analytical approaches <ul><li>Let’s analyze the functional specs. to understand the system’s expected behavior </li></ul><ul><li>“ Let’s develop a model of the system, and then use this conceptual model as a basis for testing” </li></ul><ul><li>Let’s derive the test cases by analyzing the description logic, process flows, equivalence classes, changes of state, or input combinations, etc.” </li></ul>Ross Collard (2002) Different testing approaches (2) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    7. 7. Information-driven approaches <ul><li>“ 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” </li></ul><ul><li>“ Let’s follow this bug list or check list in our testing” </li></ul><ul><li>“ Let’s go ask the software engineers what to test, because they know how the system works” </li></ul><ul><li>“ Let’s look under the hood and read the code” </li></ul><ul><li>“ Let’s follow the clients’ direction, because they have the final sign-off authority” </li></ul>Ross Collard (2002) Different testing approaches (3) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    8. 8. Time-honored but less effective approaches <ul><li>“ Let’s follow the book” </li></ul><ul><li>“ We always do it this way” </li></ul><ul><li>“ You shouldn’t change that features because it will screw up our testing.” The tail wags the dog. </li></ul><ul><li>“ Testing is easy, or at least a lot easier than software design, programming and maintenance.” </li></ul><ul><li>“ Anyone can do testing” </li></ul><ul><li>“ Errors just happen. They are caused by bad luck.” </li></ul>Ross Collard (2002) Different testing approaches (4) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    9. 9. Experiential and intuitive approaches <ul><li>“ Let’s think blue-sky, speculate and follow our intuition.” </li></ul><ul><li>“ We have good hunches about where the bugs are lurking.” </li></ul><ul><li>“ Let’s jump in an explore the system’s behavior hands-on, so we can decide how to test it.” </li></ul><ul><li>“ Let’s find the important bugs fast, and worry about the test paperwork later.” </li></ul>Ross Collard (2002) Different testing approaches (5) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    10. 10. Exploratory Testing <ul><li>Let’s explore, design the tests and test the system concurrently (James Bach) </li></ul><ul><li>Let’s learn about the system, test it and reports bugs as we go (Cem Kaner) </li></ul><ul><li>Let’s structure and document our creative testing so we know where we have been </li></ul><ul><li>Let’s apply everything we have learned about testing as we learn about the system, let’s do ”thinking-while-testing”! </li></ul>Different testing approaches… Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    11. 11. What’s Special about a Tester’s Brain? Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    12. 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 © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    13. 13. Basic Skills of Epistemology <ul><li>Ability to pose useful questions. </li></ul><ul><li>Ability to observe what’s going on. </li></ul><ul><li>Ability to describe what you perceive. </li></ul><ul><li>Ability to think critically about what you know. </li></ul><ul><li>Ability to recognize and manage bias. </li></ul><ul><li>Ability to form and test conjectures. </li></ul><ul><li>Ability to keep thinking despite already knowing. </li></ul><ul><li>Ability to analyze someone else’s thinking. </li></ul>From Rapid Software Testing, copyright © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    14. 14. Tunnel-Vision is Our Great Occupational Hazard From Rapid Software Testing, copyright © 1996-2002 James Bach Problems you can find with your biases… invisible problems invisible problems Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    15. 15. A Tester’s Attitude <ul><li>Cautious </li></ul><ul><ul><li>Jump to conjectures, not conclusions. </li></ul></ul><ul><ul><li>Practice admitting “I don’t know.” </li></ul></ul><ul><ul><li>Have someone check your work. </li></ul></ul><ul><li>Curious </li></ul><ul><ul><li>What would happen if…? </li></ul></ul><ul><ul><li>How does that work? </li></ul></ul><ul><ul><li>Why did that happen? </li></ul></ul><ul><li>Critical </li></ul><ul><ul><li>Proceed by conjecture and refutation. </li></ul></ul><ul><ul><li>Actively seek counter-evidence. </li></ul></ul>Good testers are hard to fool. From Rapid Software Testing, copyright © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    16. 16. To improve our ”judgement and skills”: <ul><li>Heuristic s: </li></ul><ul><li>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. </li></ul>James Bach, james@satisfice.com 1. 2. 3. 4. 5.
    17. 17. Heuristics… continued: <ul><li>&quot;Avoid driving while intoxicated, because there is an elevated danger of an accident&quot; is a heuristic. </li></ul><ul><li>&quot;Never drive when intoxicated&quot; is, by contrast, a rule. </li></ul>James Bach, james@satisfice.com 1. 2. 3. 4. 5.
    18. 18. Testing is done in Context <ul><li>The value of any practice depends on its context. </li></ul><ul><li>There are good practices in context, but there are no best practices. </li></ul><ul><li>People, working together, are the most important part of any project's context. </li></ul><ul><li>Projects unfold over time in ways that are often not predictable. </li></ul><ul><li>The product is a solution. If the problem isn't solved, the product doesn't work. </li></ul><ul><li>Good software testing is a challenging intellectual process. </li></ul><ul><li>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. </li></ul>http://www.context-driven-testing.com/ Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    19. 19. Exercise: The Triangle Program <ul><li>Specification: </li></ul><ul><ul><li>This program takes three numbers as input. </li></ul></ul><ul><ul><li>The numbers represent the dimensions of a triangle. </li></ul></ul><ul><ul><li>When you click on the check button, the program tells you what kind of triangle the sides represent: </li></ul></ul><ul><ul><ul><ul><li>scalene (no side equal to any other) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>isosceles (two sides are equal) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>equilateral (all sides are equal) </li></ul></ul></ul></ul><ul><li>Please test this program. </li></ul>From Black Box Software Testing, copyright © 1996 – 2002 Cem Kaner Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    20. 20. Example tests: The Triangle Program <ul><li>Example of tests or groups of tests: </li></ul><ul><ul><li>Test case for a valid equilateral triangle </li></ul></ul><ul><ul><li>At least three test cases that represent valid isosceles triangles (all permutations, e.g. 3,3,4; 3,4,3; 4,3,3) </li></ul></ul><ul><ul><li>Test case in which one side has a zero value </li></ul></ul><ul><li>See Meyer’s Answer in his book </li></ul>Myers 1979, page 3. Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    21. 21. 1. 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 1. 2. 3. 4. 5.
    22. 22. What is Exploratory Testing? <ul><li>&quot;Exploratory testing involves simultaneously learning, planning, running tests, and reporting / troubleshooting results.&quot; </li></ul><ul><li>Dr. Cem Kane r (2001) </li></ul><ul><li>&quot;Exploratory testing is an interactive process of concurrent product exploration, test design and test execution.” </li></ul><ul><li>” 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. ” </li></ul><ul><li>James Bach, Satisfice (2001) </li></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    23. 23. <ul><li>Said about eXtreme Programming </li></ul><ul><li>Agile software development is not conventional software development done more quickly or done on tippie-toe. Agile software development is software done differently. </li></ul><ul><li>Ron Jeffries, (e-mail on agile-testing list, April 24, 2002) </li></ul><ul><li>proven (no single technique is new) </li></ul><ul><li>application oriented </li></ul><ul><li>planned and disciplined </li></ul><ul><li>controllable and reliable </li></ul><ul><li>risk minimizing </li></ul><ul><li>Two sides of extreme programming: </li></ul><ul><ul><li>for the developer: freedom, flexibility, fun </li></ul></ul><ul><ul><li>for the manager: controllability, reliability, high quality </li></ul></ul><ul><li>Martin Lippert (University of Hamburg), ICSTEST 2002 </li></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    24. 24. <ul><li>The eXtreme Programming and Exploratory Testing Analogy: </li></ul><ul><li>Agile software testing is not conventional (scripted) software testing done more quickly or done on tippie-toe. </li></ul><ul><li>Exploratory Testing: </li></ul><ul><li>proven (no single technique is new) </li></ul><ul><li>application oriented </li></ul><ul><li>planned and disciplined </li></ul><ul><li>controllable and reliable </li></ul><ul><li>risk minimizing </li></ul><ul><li>Two sides of Exploratory Testing: </li></ul><ul><ul><li>for the tester: freedom, flexibility, fun </li></ul></ul><ul><ul><li>for the manager: controllability, reliability, high quality </li></ul></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    25. 25. ET vs. Scripted Testing Jarle Våga (2002) Fully Scripted Testing Ad-hoc Testing Automated Tests Bug Hunting Exploratory Testing Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management Product Exploration Test Design Test Execution
    26. 26. What is Scripted Testing? <ul><li>Small (but realistic) example: </li></ul><ul><li>How to script and test this login? (Functional tests only – not security!) </li></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    27. 27. Sample test scripts (4 of “many”): <ul><li>Sample test script 1: </li></ul><ul><ul><li>Launch the Login screen </li></ul></ul><ul><ul><li>Enter User-id: “xyz” </li></ul></ul><ul><ul><li>Enter Password: “zyx” </li></ul></ul><ul><ul><li>Press <Enter> </li></ul></ul><ul><ul><li>Expected result: login ok </li></ul></ul><ul><li>Sample test script 2: </li></ul><ul><ul><li>Launch the Login screen </li></ul></ul><ul><ul><li>Enter User-id: “xyz” </li></ul></ul><ul><ul><li>Enter Password: “zyx” </li></ul></ul><ul><ul><li>Click the “Login” button </li></ul></ul><ul><ul><li>Expected result: login ok </li></ul></ul><ul><li>Sample test script 3: </li></ul><ul><ul><li>Launch the Login screen </li></ul></ul><ul><ul><li>Enter User-id: “” </li></ul></ul><ul><ul><li>Enter Password: “zyx” </li></ul></ul><ul><ul><li>Press <Enter> </li></ul></ul><ul><ul><li>Expected: login rejected </li></ul></ul><ul><li>Sample test script 4: </li></ul><ul><ul><li>Launch the Login screen </li></ul></ul><ul><ul><li>Enter User-id: “” </li></ul></ul><ul><ul><li>Enter Password: “zyx” </li></ul></ul><ul><ul><li>Click the “Login” button </li></ul></ul><ul><ul><li>Expected: login rejected </li></ul></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    28. 28. Sample Generic Scripts (2 of “many”) <ul><li>Sample generic test script 1: </li></ul><ul><ul><li>Launch the Login screen </li></ul></ul><ul><ul><li>Enter valid User-id </li></ul></ul><ul><ul><li>Enter valid Password </li></ul></ul><ul><ul><li>Press <Enter> or click button </li></ul></ul><ul><ul><li>Expected result: login ok </li></ul></ul><ul><li>Sample generic test script 2: </li></ul><ul><ul><li>Launch the Login screen </li></ul></ul><ul><ul><li>Enter invalid User-id </li></ul></ul><ul><ul><li>Enter valid Password </li></ul></ul><ul><ul><li>Press <Enter> or click button </li></ul></ul><ul><ul><li>Expected result: login rejected </li></ul></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    29. 29. Sample test “Pattern” script (checklist) <ul><li>Input fields: </li></ul><ul><ul><li>Valid data </li></ul></ul><ul><ul><li>Invalid data </li></ul></ul><ul><ul><li>Length > max </li></ul></ul><ul><ul><li>Length = max +1 </li></ul></ul><ul><ul><li>Length = max </li></ul></ul><ul><ul><li>Length = max –1 </li></ul></ul><ul><ul><li>Combinations of above </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Actions: </li></ul><ul><ul><li>Keyboard </li></ul></ul><ul><ul><li>Buttons </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Operations: </li></ul><ul><ul><li>Add, Modify, Inquiry, Delete </li></ul></ul><ul><ul><ul><li>What to test for each… </li></ul></ul></ul><ul><ul><li>… </li></ul></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    30. 30. When to use Exploratory Testing? (1) <ul><li>A common goal of exploration is to probe for weak areas of the program. </li></ul><ul><li>Test team’s resource consumption per week: </li></ul><ul><ul><li>25% of the group’s time developing new tests </li></ul></ul><ul><ul><li>50% executing old tests (including bug regression) </li></ul></ul><ul><ul><li>25% on exploratory testing </li></ul></ul>Cem Kaner (2001a) Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    31. 31. When to use Exploratory Testing? (2) <ul><li>When there is little or no specifications and / or requirements </li></ul><ul><li>When you have little or no domain knowledge </li></ul><ul><li>When you don’t have time to specify, script and test </li></ul><ul><li>Uncertainty and Time Pressure! </li></ul>Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    32. 32. When to use Exploratory Testing? (3) <ul><li>Exploratory Testing is extremely useful when faced with software that is </li></ul><ul><ul><li>Untested </li></ul></ul><ul><ul><li>Unknown or </li></ul></ul><ul><ul><li>Unstable </li></ul></ul><ul><li>The tester must create a map of the application as he goes on testing it. </li></ul>Harry Robinson, http://www.testingcraft.com/exploratory-robinson.html Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    33. 33. When to use Exploratory Testing? (4) <ul><li>Take a more scripted approach when: </li></ul><ul><ul><li>There are little uncertainty about how to test </li></ul></ul><ul><ul><li>New tests are relatively unimportant </li></ul></ul><ul><ul><li>The need for efficiency and reliability in executing tests is worth the effort of scripting </li></ul></ul><ul><ul><li>We are prepared to pay the cost of documenting and maintaining tests </li></ul></ul>From Black Box Software Testing, copyright © 1996 – 2002 Cem Kaner Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    34. 34. The Fallacy of Repeated Tests: Clearing Mines mines From Rapid Software Testing, copyright © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    35. 35. Totally Repeatable Tests Won’t Clear the Minefield mines fixes From Rapid Software Testing, copyright © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    36. 36. Variable Tests are Therefore More Effective mines fixes From Rapid Software Testing, copyright © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    37. 37. Sample Product Test Cycle <ul><li>1. Receive the product. </li></ul><ul><ul><li>Formal builds </li></ul></ul><ul><ul><li>Informal builds </li></ul></ul><ul><ul><li>Save old builds. </li></ul></ul><ul><li>2. Clean your system. </li></ul><ul><ul><li>Completely uninstall earlier builds. </li></ul></ul><ul><li>3. Verify testability. </li></ul><ul><ul><li>Smoke testing </li></ul></ul><ul><ul><li>Suspend test cycle if the product is untestable. </li></ul></ul><ul><li>4. Determine what is new or changed. </li></ul><ul><ul><li>Change log </li></ul></ul><ul><li>5. Determine what has been fixed. </li></ul><ul><ul><li>Bug tracking system </li></ul></ul><ul><li>6. Test fixes. </li></ul><ul><ul><li>Many fixes fail! </li></ul></ul><ul><ul><li>Also test nearby functionality. </li></ul></ul><ul><li>7. Test new or changed areas. </li></ul><ul><ul><li>Exploratory testing. </li></ul></ul><ul><li>8. Perform regression testing. </li></ul><ul><ul><li>Not performed for an incremental cycle. </li></ul></ul><ul><ul><li>Automated vs. manual </li></ul></ul><ul><ul><li>Important tests first! </li></ul></ul><ul><li>9. Report results. </li></ul><ul><ul><li>Coverage </li></ul></ul><ul><ul><li>Observations </li></ul></ul><ul><ul><li>Bug status (new, existing, reopened, closed) </li></ul></ul><ul><ul><li>Assessment of quality </li></ul></ul><ul><ul><li>Assessment of testability </li></ul></ul>From Rapid Software Testing, copyright © 1996-2002 James Bach Introduction Test Management and Techniques ET Planning and Documentation ET Styles ET Management
    38. 38. 1. 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 1. 2. 3. 4. 5.
    39. 39. No Risk? No Test!
    40. 40. Typical Questions for Testers <ul><li>How much testing is enough? </li></ul><ul><li>When should we stop testing? </li></ul><ul><li>When is the product good enough for release? </li></ul><ul><li>How good is our testing? </li></ul><ul><li> Managing RISK! </li></ul>1. 2. 3. 4. 5.
    41. 41. Product Quality and test coverage Quality Risk Coverage (potential faults) Customer use Coverage 100% 100% Rex Black 1999 1. 2. 3. 4. 5. Worst Poor Perfect! Good
    42. 42. Introduction Summary Introduction Test Management and Techniques ET Planning , Exec . and Documentation ET Styles ET Management <ul><li>Introduction to Testing. </li></ul><ul><li>What is Exploratory Testing? </li></ul><ul><li>Where to use it? </li></ul><ul><li>When to use it? </li></ul><ul><li>Introduction to Risk </li></ul>1. 2. 3. 4. 5.

    ×