SOFTWARE TESTING
without requirementswithout
NO
TIME TO
EXPLAIN!
TEST!
The situation:
NO
TIME TO
EXPLAIN!
TEST!
The situation:
No
documentation
No testing
process
No time to test
everything
HAVE
YOU
BEEN IN THIS
SITUATION?
No resources to create docs.
Legacy product support.
No knowledge to create docs.
You are limited to testing only obvious things.
Obvious things you
can test.
Things you can only
guess.
Techniques.
High risk / No time Low risk / more time
Exploratory testing
Experience-based testing
Error guessing
Own experience
Docume...
High risk / No time Low risk / more time
Exploratory testing
Experience-based testing
Error guessing
Structure-based testi...
High risk / No time Low risk / more time
Documentation
No documentation
Exploratory testing
Experience-based testing
Error...
SO,
WHAT’S
THE
PLAN?
The Plan.
Exploratory testing1
Learn the product2
Create documentation3
Exploratory testing
Learn the product
Create documentation
Find the person responsible for
the results of testing.
It can be:
Who is interested in testing?
The Project
Manager?
The Customer?
This person
will help you
to understand
what is
TRUE
about
Test Scenarios
Pass/Fail
Expected
Results
Start with risk-
based testing.
Most critical and high-use features
Features you will release soon
Log test
scenarios.
For regression testing.
To learn system behavior.
To confirm the tests.
Confirm the
test results.
Until it is confirmed, this is
only your assumption.
Running the same
tests over and
over again
would not show
any new defects.
Watch out the
Pesticide
Paradox!
Notice
defect
clusters.
80% of bugs are
caused by
20%of modules.
Exploratory testing
Learn the product
Create documentation
Learn:
Users.
Objects.
Workflows.
Product properties.
Emails
Notes
Recorded issues
Marketing materials
What can be used?
The product itself
Competitors’ products
Interviews with Stakeholders
The Interview: Focus on Results
1: What should you get?
Outputs
2: What will you use?
Inputs Process
3: How is it done?
Exploratory testing
Learn the product
Create documentation
Visualize
system
requirements
To build a “map” of the workflows
To fit new tests in a whole picture
Use-case
diagrams
Flowcharts
“Screenflow”
charts
Tools:
Screenflow chart example
Document on
a high level first.
Just enough for testing
Details will be added “as you go”
Use-cases
Checklists
Tools:
Add more details
while you test.
Connect high-level requirements
and detailed test scenarios
Use both bottom-up and top-do...
Exploratory
testing
Learn the
product
Create
documentation
Risk-based testing.
Log the scenarios.
Confirm the results.
Use...
Exploratory
testing
Learn the
product
Create
documentation
Exploratory
testing
Learn the
product
Create
documentation
Expl...
HINTS
AND
HACKS
Always inform people
about the risks.
You cannot test everything –
test by priority.
Aware of some developers,
saying “it’...
KEEP
CALM
AND
TEST, TEST AGAIN,
THEN TEST SOME MORE
Found it useful?
Tweet about it!
Oleksandr Lutsaievskyi,
Agile Coach
Upcoming SlideShare
Loading in...5
×

Software Testing without Requirements: Survival Guide

44,764

Published on

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

Published in: Technology, Education
31 Comments
128 Likes
Statistics
Notes
No Downloads
Views
Total Views
44,764
On Slideshare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
816
Comments
31
Likes
128
Embeds 0
No embeds

No notes for slide

Software Testing without Requirements: Survival Guide

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

    Clipping is a handy way to collect important slides you want to go back to later.

×