- Exploratory testing isn't scripted,
but we still need to focus it appropriately
and there are some techniques that help us do that.
Decide where you're gonna focus
your exploratory testing sessions.
Think about the risks in your product and in your domain
and these new features that you're testing.
How will different persons navigate through them?
What resources can we use as we explore?
Different types of data and information from analytics.
You can use API endpoints to do exploring.
What will help us learn?
And what do we want to learn that's valuable
to our business, to the delivery team,
to our customers and end users?
This helps us plan our exploratory testing
and make the best use of our time
'cause we know we never have enough time to test everything.
We have to prioritize.
Though you're planning your exploratory testing,
be sure to be open to surprises along the way.
And set a time limit for each session.
If you see something unexpected, if you see a surprise,
you could spend some time investigating that,
but be sure to set a time limit on that
or maybe write another exploratory testing charter
to investigate that later.
We like to use Elisabeth Hendrickson's template
for writing exploratory testing charters.
And in this template, we explore some target.
That's the goal of our exploratory testing session.
What resources are we going to use
that helps flush out the charter?
We might use a particular persona.
We might decide to go look at competitive products.
What are the other pet salons in town
doing with their websites?
I like to go through old bug reports
and see what areas of the code that are like this
had problems before?
What kind of problems occurred?
Maybe I wanna try some of those similar things.
There are different heuristics that you can use.
For example, if you're testing for security,
you might wanna use a tool that can generate
format exploit strings for you.
SQL injection, cross-site scripting.
And then we want to discover something.
What's the purpose of our testing?
What are we hoping to find?
What do we want to learn?
What will help our team?
What will help our stakeholders?
Here's an example.
We're exploring editing user profiles
with exploits such as SQL injection or cross-site scripting
to learn about vulnerabilities in our application.
It could be tricky to get the right level of detail
for exploratory testing.
Your exploratory testing charter isn't just a list of tasks.
There is a place for that in quadrant two testing.
You might do very specific test cases
to help guide your development.
We wanna allow ourselves to think broadly
but not too broadly.
We never get finished with this charter.
We could just keep exploring it
with every kind of format exploit we can think of.
But, the second charter is way too specific.
It's really just one specific test case.
There's really nothing left to explore.
So, practice to learn the right scope for your charters.
There are many more tools
that help you do exploratory testing.
For example, there are numerous testing heuristics
and mnemonics available.
We really like Elisabeth Hendrickson's
Testing Heuristics Cheat Sheet.
I actually made copies of this and laminated them
and I had them scattered around our work area
so that the developers could pick them up
when they need inspiration for exploration ideas,
so there are lots of different ideas in here,
super long text strings, multi-byte characters,
different character sets, different format exploits.
And we'll provide a link to that
in our downloadable reference documentation.
Mind maps, they're great for communication
and brainstorming.
We can also use them for exploratory testing.
So, here we start with a main node,
explore security vulnerabilities in editing profiles.
Again, we think about the resources that we want to use,
like the tools that generate format exploit strings.
You can do your mind maps on a whiteboard
or if you have a distributed team,
you might wanna use a collaborative online tool.
One of the nice things about mind maps,
especially using the online ones,
is you can use them for reporting.
You can check them off as you go.
You can attach screenshots of maybe something you want
the team to think about more or give to the product owner.
And it also can make progress
on your exploratory testing more visible.
There are other ways to visualize, so just experiment.
We'll look at a couple more options.
A very simple approach is just writing bullet points.
You can write these on your story cards or on a Wiki page,
and they can work but don't let them constrain you
from lateral thinking.
You really need to be open minded
and be ready to see those gorillas
dancing through your basketball players.
Here is a charter that's channeling a busy pet chauffeur
who needs to make multiple appointments at the same time
because she's bringing in several pets at once.
Try different formats for your exploratory test
and see what works best for your team.
There are unlimited areas that you can explore.
And as Janet said, it's not necessarily your product.
You might be exploring test frameworks or cutting frameworks
or new technologies.
And when do we explore?
We can explore early
when new features are being designed and planned.
We can explore business rules and examples for example.
We can explore our architecture.
We can explore at the feature level,
the story level, and the task level.
And as soon as some piece of code is delivered,
we can start exploring it.
For example, if we're working on a new feature,
we might be able to explore the business logic
with the 3D API before the user interface is even written.
That gives us a lot quicker feedback.
We can code up a thin end-to-end slice
of some new functionality in a test environment
that mirrors production
and see what it's really going to be like
for our users to use it and learn about that.
We want to look at value.
We want to think about unknown unknowns
and be able to find those,
all those thing we didn't think about
when we were planning and designing.
This is the time that we can discover them.
I've seen people really get stuck, even on my own team.
We've had workshops to teach everyone on the team
how to do exploratory testing,
but they still have a hard time getting started
to write that first charter or execute that first test.
So, don't overthink it.
Just think of a test, do it.
See where it leads you.
Use your observational skills.
Use your critical thinking and your gut intuition,
what questions occur to you.
As you observe something unusual,
maybe there's a smell there,
you wanna dig deeper but again,
set a time limit on your side trips
and perhaps write another charter
if you think there's a whole nother area
you want to dig into.
Be sure to take notes as you test
so that you can report what you learned back
to the team, to the product owner,
to the business stakeholders.
I really like to pair for exploratory testing
either with another tester or a developer
or a product owner.
And pairing is really great because it's like driving a car.
If you're busy driving the car and watching the road,
you can't really observe very well,
so the person who's not driving the keyboard
can observe and actually take notes a lot more easily,
and then you can switch off with driving and observing.
And debriefing is key.
We need to pass on this information that we learned.
Exploratory testing is usually a manual process,
but we often use scripts to help us with that
and do the tedious and boring parts
and free ourselves up for the parts where we need our
critical thinking and observational skills.
For example, generating test data,
setting up a particular scenario
where we wanna start testing.
Janet has shared some experiences
with her remote data management team
of how they built a simulator to send inputs.
They also use that for exploratory testing,
so a lot of the things you do for automation
of your regression test can help with exploratory testing,
set up data to explore new scenarios.
You can use emulators if you're testing mobile applications
or embedded software,
although you always need to explore with the real devices
at some point too,
and use other resources like log files.
A lot of times, your system can fail silently.
Nothing comes in through the API response
or the user interface,
but something happened behind the scenes
that could have caused even data loss,
so you wanna make sure to check those too.
For exploratory testing, there are some tools out there
that will record the keystrokes that you did
so that you can repeat something if you want to
and help you keep notes, so you can look out for those.