9. Exploratory Testing:
Better tests, better testers!
• An approach, not a technique
• Find unknown unknowns
• Disciplined
• Test is a performance, not artifact
– Artifacts support human
memory
– Many forms: e.g. checklists and
automation
• Exploratory performance testing,
Exploratory test automation,
Exploratory regression testing
Test-related
learning
Design of new
tests
Test execution
Result
interpretation
9
10. There’s a Difference!
• A comment I hear often on the ET
course I give:
– ”I’ve always been doing this just did not
give it a name”
• I must emphasize that:
– I require more out of exploratory testing
than just ”going where you feel like
while testing”
• Ask yourself:
– Can you defend your choices of
strategy and tactics?
– Can you explain what you’ve done in
words that don’t just explain numbers of
bugs found?
– How do you know if you’re done or not?
10
”My testing would
be unsystematic
ad hoc testing if I
could not tell the
story of my tests,
remember what
I’ve tested or
what my strategy
was, or relate
that back to my
mission” –James
Bach
12. Exploratory Testing:
Frame of Management
”A day’s work”
Vision (“Sandbox”) Current Charter
Other Charters Details
Bug
Reports
Perception of
quality and
coverage
Quality
ReportDebriefing
Tester
Test
Manager
Past
Results
Obstacles
Outlook
Feelings
?
#
xCharter backlog of the future
testing
Out of
budget
Next in
importance!
#, ?, x, +
20:20:60
Session sheets of the past testing
Idea of
exploration
Metrics
summary
Coachin
g
12
Playbooks
Coverage outlines
13. Test Ideas / Quick-and-Dirty
Download the full 2-page Cheat Sheet with ideas from Elisabeth Hendrickson,
James Lyndsay, and Dale Emery on Qualitytree.com 14
14. (Exploratory) Testing Dynamics
Source: Adapted from James Bach, Jon Bach, Michael Bolton. Exploratory Testing
Dynamics. v.2.2. 2009
Evolving
work
products
Skills
and
tactics
Testing
polarities
Test
strategy
”A set of
considerations designed
to help you test robustly
or evaluate someone
else’s testing.”
” To develop ideas or
search a complex space
quickly yet thoroughly,
not only must you look
at the
world from many points
of view and perform
many kinds of activities”
”Exploratory testing
spirals upward toward a
complete and
professional set of test
artifacts”
” …skills that comprise
professional and cost
effective exploration of
technology. Each is
distinctly observable and
learnable, and each is
necessary to exploratory
work.”
15
15. Exploration Skills
Source: Adapted from James Bach, Jon Bach, Michael Bolton. Exploratory Testing
Dynamics. v.2.2. 2009
Self-
managemen
t
Developing
ideas
Examining
product
Done
To Do
Issues
Coverage
All sources available
Best use of time – effective and efficient work
Making models
Tool support – creative solutions
Risk-based testing – scientific approach
Keeping one’s eyes open
16
16. Test Automation / Tools in ET
• Any form of acquiring quality-related
information fits into exploratory testing
• It’s not manual, it’s brain-engaged – and for
making that happen, you need to be smart
with automation and tools!
• Example: you might not at first know what
you’re looking for...
Search "<ns1:Koodi>" (443 hits in 169 files) in VE
Y:ELLULAPATestausKokonaiseläketurvan-oteAnsaintatiedot-VEHaeAnsaintatiedot-VE__
20110307 14-22-15.xml (4 hits)
Line 1313: <ns1:Koodi>YL130I</ns1:Koodi>
Line 1317: <ns1:Koodi>LAPA_172_011</ns1:Koodi>
Line 1321: <ns1:Koodi>67</ns1:Koodi>
Line 1324: <ns1:Koodi>67</ns1:Koodi>
A lot of text cut away from here… 17
20. Serendipity, Perseverance
…and Love of Testing
• Serendipity = Lucky
accident
• Just my luck?
– Luck favors the ones
who intentionally vary
their actions
• ”The more I practice,
the luckier I get”
• Perseverance = Keep
trying
• Testing takes time –
keep trying with more
ideas, stop giving up so
easily
• “It's not that I'm so
smart, it's just that I
stay with problems
longer.”
21. The World Has Already
Changed
COMMODITY
TESTERS
• Manual checkers
• Tests are an
artifact
SKILLED
TESTERS
• Explorers of
products and
businesses
• Testing is a
performance
22
This talk is about skilled testing - breaking illusions about your product, providing information founded on empirical evidence and learning while performing testing. There’s a lot of misconceptions on what it means to do exploratory testing, and this talk sets out to clarify what it is and how it’s done and why should you care if testing in your projects is done with the right mindset. We look into nature of testing with a couple of exercises and discuss common misconception of its role and purpose in agile.
Waterfall: Dismissing feedback 1) not a bug, feature 2) not relevant enough at this point of schedule 3) relevant, but it still goes to production.
Fighting a losing battle
Agile: People welcome and react to feedback
In both waterfall and agile, we don’t want to do wasteful testing. Thus exploratory testing, awareness of opportunity cost.
We want it to work in production. And with developer-tester perspectives, we’ve managed to make that true.
We had recruited a tester because we knew (the devs) that they couldn’t see things from all the necessary angles. So they had asked for the feedback.
The difference between people who do ad hoc testing (a starting form of exploratory testing) is significant. It is especially visible for a manager in a scrum meeting. When you, as a tester, answer the question: ”what did you do since yesterday and what do you plan on doing by tomorrow”, you’re not doing a very good job in ET if you tell that ”Found a problem in X, will find another one” – you’re not enabling your team to learn about testing, most likely since you did not learn yourself yet. Learning is a key element in exploratory testing!
Point of this slide: Testing helps with EFFECTIVENESS, as a productivity service. Your users might not really like reporting your bugs for you, as it wastes their time.
Point of this slide: BUGS not defects: anything this might bug a user, there’s many types of illusions we have
Finding really expensive bugs: missing value, wrong features
Illusion: releasing as scheduled (sprint) vs. releasing when done (kanban)
EMPIRICAL evidence trumps speculation. Every Single Time. – testobsessed
You need to know about the product, the business model around the product and the process used to create that product. Not just take things as they are given “by the book” or “scrum says”, but actively question and rely on empirical evidence.
Yesterday arriving at the hotel, they gave me a room number and a key – those just did not match
First day at new work I created a bookmark to remember the system. First use => program error
Started testing a new feature and needed a user account for that. Decided to take an old one and change its password => program error
It's not that I'm so smart, it's just that I stay with problems longer. – Albert Einstein
The more I practice, the luckier I get – Arnold Palmer
Point of this slide: COMMODITY testers and SKILLED testers are two completely different breeds
Your ideas of testers may be outdated. You get what you ask for, and if you ask for test cases, you get commodity approaches.