- We talked about personas in the last section,
and now we're gonna introduce you to a few other
techniques for exploratory testing.
Teams often don't give enough attention to risks.
Product owners should know the business risks
and make 'em visible.
Another example besides business risks might be
from a technical perspective;
what happens if you lose your data
due to error message handling.
Other coding risks as well, such as the language you use.
Different languages have different risks.
You should know them.
What about outside influences?
What are the risk from them?
So start asking questions.
What-if scenarios.
One of my favorite questions is,
what is the worst thing that could possibly happen?
So if you ask that question to your product owner,
they might think about it and then go,
well, maybe the theft of customer data.
So then, you know that security has really big impact
and you're gonna wanna spend extra time exploring that
to bring out the biggest risks,
well to mitigate those risks.
A tried and true approach, the simplest approach
to exploratory testing, and it's the most common,
is user journeys.
For example, thinking about how people use your system.
I have a very personal one that I suffered through lately.
We had a mobile phone network, we bought a little network
that we were trying to do.
I wanted to add funds to that network so that I could have
wifi on the go.
Found out that I couldn't do that over the internet
like we'd tried to because it wanted a US postal code.
I'm from Canada.
That company didn't think of non-US citizens.
I had to go down to a store and get them to add the funds
so that I could continue to use the wifi.
Start with one journey.
Try exploring variations.
For example, if we use our dog-owner versus a cat-owner,
if we look we through a journey through the pet salon,
we have a cat-owner looking for a new groomer,
wants to see the options and the prices.
They want to book a simple brush-out to check out the store,
but the groomers as well.
What happens if you don't have the cat-owner,
but try the dog-owner?
Is that a different journey?
Would you be looking at different things?
A tour is a little bit different.
There's different things.
But it's structured; it allows us
to focus the types of questions.
It's based on a tourist metaphor.
So if you think about going to a city, right,
if I go to Paris, I want to see the Louvre,
I wanna see the Eiffel Tower,
I want to see the Cathedral, right?
That's a tour.
I can use it as a possibly tourist agent.
They would look at it much different than if I was a tourist
who came in and I had one day
and wanted to see all three things.
Different types of tours.
One that is used quite often
and is quite effective is a landmark tour.
It means looking at the order differently.
So the first time I might go to the Louvre, Eiffel Tower
and the Cathedral; the next time, what happens if I
go to the Cathedral first and then the Eiffel Tower?
All right.
You wanna look at your landmarks in your application.
What would that mean?
Can you take and go through different ways changing
the order up?
James Whittaker has a book out that describes a lot of
different tours, but, if you go and explore on the internet,
you will see all kinds of tours that people have made up.
Create their own very special for their application.
I like to use tours during the end game.
It gives you a different perspective for your application.
You want to be looking at it
from a completely different viewpoint.
So let's look at some examples in our pet salon site.
Websites appear differently on different devices
with different resolutions.
Maybe if you have different printouts
or from different papers or a different printer even,
the pet salon will look different on different devices.
You might wanna look for or think about colorblindness.
For example, if i was looking at a airline seat
and we were trying to say, this is a good seat by
the color green and this would be color red,
if somebody was colorblind, well, it might not look so good.
So we wanna think about accessibility.
If you have a pink dog with a green background,
how will that affect your site?
Think about those sorts of things.
So you wanna manage color and style across platforms.
It's a big challenge to optimize what is important to you.
If we think about the landmark tour from our pet salon,
what happens if you try things in a different order?
So first of all we try grooming options,
maybe we look at testimonials,
maybe we look at the pet pictures.
And then we book an appointment.
That might be a normal kind of thing to do.
What happens if we start by looking at the pet pictures,
booking an appointment, then looking at the testimonials?
You may get different behavior in your testing.
So try it.
It can be very powerful.
Programmers might explore during their own coding
to help shorten the feedback loop for their visual issues.
Testers might explore stories for browser incompatibility.
But we still need to explore at the feature level.
And one way is to explore in groups.
Lisa's teams adds group hugs, she calls 'em, I love that,
for extra confidence on major or risky features.
She gets a lot of people together in a room
or perhaps even a video meeting.
Testers might provide the charters,
or maybe the team members will provide their own,
collaborate to test concurrency issues.
If I update this, what happens to that?
Lisa and I do that a lot when we're collaborating on
a book or even this video course,
making sure that we keep things in sync.
When you're doing group testing, though,
make sure you keep notes in a shared document
to follow up if necessary.
We can also do mob testing.
It's a very interesting way of testing one driver with
multiple people helping by asking questions.
It's a lot like mob programming,
but from a testing perspective.
We're not gonna talk a lot about that,
but we've provided a link in the download section
so that you can research more.
Exploratory testing is about learning.
One of my favorite ways of going into a new team
is to explore, not only the software, but the
documentation if there is any.
I look at the tests.
I walk around to see what's on the walls, what's visible.
It really is all about learning.
Exploratory testing has many uses.
Programmers use it to explore new tools or language.
Maybe we have end-to-end slice of a new project
and we need to look for unexpected behavior.
Does a feature have unexpected impacts on other areas?
So I would probably start by drawing a context diagram
or something else to be able understand what impacts
it might be, and maybe I go explore in that specific area.