SOFTWARE TESTING without requirements without
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
Documentation
No documentation
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
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
SO, WHAT’S
THE
PLAN?
The Plan.
Exploratory testing 1
Learn the product 2
Create documentation 3
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-down
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.
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.
HINTS AND
HACKS
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.
KEEP CALM
AND
TEST, TEST AGAIN, THEN TEST SOME MORE
Found it useful? Tweet about it!
Oleksandr Lutsaievskyi, Agile Coach
Top Related