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

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