- More agile teams are finding value in exploratory testing,
but for many teams,
it's still a new or even an unknown idea.
We're gonna start by explaining the purpose of
exploratory testing and what's involved.
We like Elizabeth Hendrickson's definition
of exploratory testing.
Simultaneously designing and executing tests
to learn about the system,
using your insights from the last experiment
to inform the next.
Exploratory testing helps us find surprises.
Implications of interactions that nobody considered
when we were planning our feature,
and misunderstandings about what the software
is supposed to do.
Our goal is to learn information of interest and value
to the delivery team, to the business
and to the customers.
We wanted to mitigate risk and gain confidence
in our new features and our product.
With exploratory testing, there's no script.
There are no lists of expected outputs,
but instead, we think about our goal.
What do we want to learn?
What resources can we use?
When you do exploratory testing,
be open to observing, to learning.
Use your critical thinking skills.
Challenge your expectations.
New thoughts will take you to new places.
If you have ever joined a project that had no documentation
about their product and you just had to learn
what the system does by using it,
you've actually done exploratory testing,
but in this lesson,
we're focusing on exploratory testing
in the agile world and we're assuming
that you know your system under test.
People often confuse exploratory testing
with ad hoc testing or monkey testing.
Ad hoc testing is testing without
any planning or any documentation,
and there's a place for that.
Just trying things.
Following your nose.
Not the same as exploratory testing though.
Monkey testing is just entering random inputs
and random actions and see what breaks,
and both of these types of testing have their place.
But exploratory testing
is much more focused and disciplined.
It's the difference between
wandering at random because you're lost
and exploring thoughtfully to gain insights.
We can explore other things besides the software itself.
We can explore ideas.
In lesson three, we talked about
exploring business roles by using examples.
There are lots of techniques for exploratory testing,
and we'll cover some of these later in this lesson.
Lets look at a few of the many different approaches
of exploratory testing.
Personas.
Think about who uses your system.
How do they use it?
What's their job?
What's their role?
We want to look at risks,
both technical and business risks.
The most common exploratory testing approach
is using workflows or journeys,
and we can also use tours.
Identifying landmarks, if you will, to explore the system.
This comes in very handy during the in game.
It can be combined with workflows and journeys
to look at your system and navigate through
in different ways.
We'll be looking at each of these techniques in more detail.