Download as PDF, PPTX
Uploaded byOleksandr Lutsaievskyi
Software Testing without Requirements: Survival Guide
This document discusses software testing techniques that can be used in situations where there is little time or documentation available. It recommends an approach of exploratory testing, learning about the product through exploration and interviews, and creating documentation throughout the testing process in a top-down and bottom-up manner. Specific techniques mentioned include risk-based testing, logging test scenarios, confirming results, learning about users, objects, workflows and properties of the product, visualizing system requirements, starting with high-level documentation and adding details while testing. The approach is to repeat exploratory testing and documentation to continually learn more about the product.
Software Testing without Requirements: Survival Guide
- 1.
- 2.
- 3. NO TIME TO EXPLAIN! TEST! The situation: No documentation Notesting process No time to test everything
- 4.
- 5. No resources tocreate docs. Legacy product support. No knowledge to create docs.
- 6. You are limitedto testing only obvious things.
- 7. Obvious things you cantest. Things you can only guess.
- 8.
- 9. High risk /No time Low risk / more time Exploratory testing Experience-based testing Error guessing Own experience Documentation No documentation
- 10. High risk /No time Low risk / more time Exploratory testing Experience-based testing Error guessing Structure-based testing Use-case based testing Equivalence partitioning Boundary testing State-transition Decision tables Specification Use-cases Code Own experience Documentation No documentation
- 11. High risk /No time Low risk / more time Documentation No documentation Exploratory testing Experience-based testing Error guessing Use-case based testing Equivalence partitioning Boundary testing State-transition Decision tables Specification Use-cases Own experience Structure-based testing Code
- 12.
- 13. The Plan. Exploratory testing1 Learnthe product2 Create documentation3
- 14. Exploratory testing Learn theproduct Create documentation
- 15. Find the personresponsible for the results of testing.
- 16. It can be: Whois interested in testing? The Project Manager? The Customer?
- 17. This person will helpyou to understand what is TRUE about Test Scenarios Pass/Fail Expected Results
- 18. Start with risk- basedtesting. Most critical and high-use features Features you will release soon
- 19. Log test scenarios. For regressiontesting. To learn system behavior. To confirm the tests.
- 20. Confirm the test results. Untilit is confirmed, this is only your assumption.
- 21. Running the same testsover and over again would not show any new defects. Watch out the Pesticide Paradox!
- 22. Notice defect clusters. 80% of bugsare caused by 20%of modules.
- 23. Exploratory testing Learn theproduct Create documentation
- 24.
- 25.
- 26. The product itself Competitors’products
- 27.
- 28. The Interview: Focuson Results 1: What should you get? Outputs 2: What will you use? Inputs Process 3: How is it done?
- 29. Exploratory testing Learn theproduct Create documentation
- 30. Visualize system requirements To build a“map” of the workflows To fit new tests in a whole picture
- 31.
- 32.
- 33. Document on a highlevel first. Just enough for testing Details will be added “as you go”
- 34.
- 35. Add more details whileyou test. Connect high-level requirements and detailed test scenarios Use both bottom-up and top-down
- 36. Exploratory testing Learn the product Create documentation Risk-based testing. Logthe scenarios. Confirm the results. Users, Objects, Flows. Use legacy docs. Interview people. Visualize. Start with a high level. Top-down/bottom-up.
- 37. Exploratory testing Learn the product Create documentation Exploratory testing Learn the product Create documentation Exploratory testing Learnthe product Create documentation Repeat the pattern to obtain more and more knowledge on each step.
- 38.
- 39. Always inform people aboutthe risks. You cannot test everything – test by priority. Aware of some developers, saying “it’s not a bug – it’s a feature!” Still the bug can be not the bug – discuss doubtful issues. Always follow up discussion with a written notes.
- 40. KEEP CALM AND TEST, TEST AGAIN, THENTEST SOME MORE
- 41. Found it useful? Tweetabout it! Oleksandr Lutsaievskyi, Agile Coach