Your SlideShare is downloading. ×
Software Testing without Requirements: Survival Guide
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Software Testing without Requirements: Survival Guide

43,828
views

Published on

How to test software products without specifications or any documented requirements?

How to test software products without specifications or any documented requirements?

Published in: Technology, Education

30 Comments
117 Likes
Statistics
Notes
No Downloads
Views
Total Views
43,828
On Slideshare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
764
Comments
30
Likes
117
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. SOFTWARE TESTING without requirementswithout
  • 2. NO TIME TO EXPLAIN! TEST! The situation:
  • 3. NO TIME TO EXPLAIN! TEST! The situation: No documentation No testing process No time to test everything
  • 4. HAVE YOU BEEN IN THIS SITUATION?
  • 5. No resources to create docs. Legacy product support. No knowledge to create docs.
  • 6. You are limited to testing only obvious things.
  • 7. Obvious things you can test. Things you can only guess.
  • 8. Techniques.
  • 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. SO, WHAT’S THE PLAN?
  • 13. The Plan. Exploratory testing1 Learn the product2 Create documentation3
  • 14. Exploratory testing Learn the product Create documentation
  • 15. Find the person responsible for the results of testing.
  • 16. It can be: Who is interested in testing? The Project Manager? The Customer?
  • 17. This person will help you to understand what is TRUE about Test Scenarios Pass/Fail Expected Results
  • 18. Start with risk- based testing. Most critical and high-use features Features you will release soon
  • 19. Log test scenarios. For regression testing. To learn system behavior. To confirm the tests.
  • 20. Confirm the test results. Until it is confirmed, this is only your assumption.
  • 21. Running the same tests over and over again would not show any new defects. Watch out the Pesticide Paradox!
  • 22. Notice defect clusters. 80% of bugs are caused by 20%of modules.
  • 23. Exploratory testing Learn the product Create documentation
  • 24. Learn: Users. Objects. Workflows. Product properties.
  • 25. Emails Notes Recorded issues Marketing materials What can be used?
  • 26. The product itself Competitors’ products
  • 27. Interviews with Stakeholders
  • 28. The Interview: Focus on Results 1: What should you get? Outputs 2: What will you use? Inputs Process 3: How is it done?
  • 29. Exploratory testing Learn the product Create documentation
  • 30. Visualize system requirements To build a “map” of the workflows To fit new tests in a whole picture
  • 31. Use-case diagrams Flowcharts “Screenflow” charts Tools:
  • 32. Screenflow chart example
  • 33. Document on a high level first. Just enough for testing Details will be added “as you go”
  • 34. Use-cases Checklists Tools:
  • 35. Add more details while you 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. Log the 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 Learn the product Create documentation Repeat the pattern to obtain more and more knowledge on each step.
  • 38. HINTS AND HACKS
  • 39. Always inform people about the 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, THEN TEST SOME MORE
  • 41. Found it useful? Tweet about it! Oleksandr Lutsaievskyi, Agile Coach