4. • Think out of the box and be creative
• Find nasty bugs
• Learn about the product
• This is where we can make the difference
Why?
5. How?
• Use charters to give structure
• Explore [target] with [resources] to discover
[information]
• Focus by using time boxed test sessions
• Document what you do!
11. Users do all kinds of stuff you haven’t thought of
12.
13. context from the team
• Ahold, e-commerce for Dutch supermarket
• Test automation basics in place
• Existing phone app from 2009, code was messy
• Making new tablet app for iOS & Android
17. And…
• aside from all the automated checks, we need to
explore the weird paths/states in the app
• trying to find the unknown unknowns before our
users do
• more people testing == more chance of finding
defects
18. Let’s start the journey
• Educate developers and others about testing
• Test together
• Have fun
• Try to find the black swans before the users do
19. step 1. Educate
• Start teaching people the basics of
Exploratory Testing
• Article on company Wiki
• Small presentation I could give to people
• Give people context
You want the materials that I made? No probs,
contact me after this presentation
20. Step 2. Plan
• get the Product Owner
involved
• plan the session (invite
cross-team as well)
• prepare for the ‘omg 2 hours
of testing??!!’ response
• promise free drinks
21. Step 3. prepare the session
• make the ET charters yourself, or with the team, or
the PO…it depends!
• print out the charters
• make sure the test system is available and
everybody will test the same version
• make sure your test session isn’t ruined by
deployments, outages, whatever (if you can..)
22. sidestep: the charters
• think about your context
• where’s the biggest risk?
• what is already automated?
23. Step 4. The session
• intro: presentation (10-15 minutes)
• stress the importance of documenting!
• split the session in blocks of 30 minutes to help to
keep the focus
• debrief after 30 minutes, repeat the cycle
• let people pair up
24. step 5. Debrief
• longer debrief at the end, not everyone needed to
attend
• most important!
• decide which bugs need fixing
• administration: boring but necessary
• this part can take a loooooooong time
28. Step 6. Celebrate!
• very positive feedback on the
session
• people had fun
• the value of the testing was crystal
clear
• retro: let’s do this every sprint
29. What I liked about it:
• developers are great testers, they see different
things (biases can be a good thing!)
• everybody at Ahold was open to try this out
• people really put effort into ‘thinking like a tester’
and ‘thinking like an end user’
30. Next sessions:
• people from other teams started to organise their
own sessions
• PO’s from other teams were impressed with the
results
• lots of defects found in each session
31. and we lived happily ever after and
everybody tests…?
32. BUT
• Attendance got flaky
• Developers started finding excuses why they
couldn’t participate
• Urgent vs important fallacy
34. My own idea:
• no longer a separate session, but part of the DoD
• pair up with a developer every day
• write charters with others
35. Keep up the spirit
• Keep inspiring other team members to do ET
sessions
• Make the sessions a fun thing
• Lead by example
36. Recap to set this up
• Educate your colleagues
• Plan the session
• Prepare the session
• Do the session
• Debrief
• Celebrate
• And…..Don’t give up!
37. Never forget the goal
The whole team is responsible for quality of the
product
As a tester, our job is to help achieve this goal
40. Helpful resources
• Blog Exploratory Testing 3.0 http://
www.satisfice.com/blog/archives/1509
• Book ‘Explore It!’ by Elizabeth Hendrickson
• Test Heuristics Cheat Sheet
• your brain (you know more than you think)
