This post is a prettied-up version of the notes I made in advance of my
talk, How To Test Anything, at the
OnlineTestConf 2020
this week. Here's the abstract:
Sometimes you’re asked to start testing in a context that is not ideal:
you’ve only just joined the project, the test environment is broken, the
product is migrating to a new stack, the developer has left, no-one seems
quite sure what’s being done or why, and there is not much time.
Knowing where to begin and what to focus on can be difficult and so in
this talk I’ll describe how I try to meet that challenge.
I’ll share a definition of testing which helps me to navigate uncertainty
across contexts and decide on a starting point. I’ll catalogue tools that
I use regularly such as conversation, modelling, and drawing; the rule of
three, heuristics, and background knowledge; mission-setting, hypothesis
generation, and comparison. I’ll show how they’ve helped me in my testing,
and how I iterate over different approaches regularly to focus my
testing.
The takeaways from this talk will be a distillation of hard-won, hands-on
experience that has given me
- an expansive, iterative view of testing
- a comprehensive catalogue of testing tools
- the confidence to start testing anything from anywhere
--00--
How to test anything, then. The title felt gooooood when I proposed it after being invited to speak at the conference, but not so much when I came to write the talk!
I'm very
much not an egotist and the message I want to convey here is not that you should test in the patented, certified, Thomas Way. Rather, I
think that there are useful approaches to testing independent of the
application and the context, and I want to share the ones that I use and
how I use them.
Let's start with a thought experiment.
You are watching a robot and me — a tester — interacting with the same
system. Our actions are, to the extent that you can tell, identical and the
system is in the same state at each point in the sequence of actions for both
of us. The machine and me performed the same actions on the same system with
the same visible outcomes.
If I told you I was testing, would you feel comfortable saying that the robot
was testing too? I’d have a hard time saying that it was. Harry Collins and Martin Kusch, in The Shape of Actions, reckon that:
Automation of some task becomes tractable at the point where we become indifferent to the details of it.
I'm not bashing automation — I’m a regular user of automation as a tool in
testing — but whatever complexity you put into your robot, my instinct is that
it's not going to be as flexible as a human could be when encountering a given
situation, particularly an unforeseen one. Automation naturally can’t
consider all the details, filtering out only the ones that seem interesting
given knowledge of the context in the way that a human can.
For me, testing requires there to be intent, deliberate actions, agency, and
responsiveness to observation on the part of the tester. I also have a strong
idea of what is required for something to be tested.
In this post, I’ll describe what testing is for me, I’ll list some of the
testing tools that I think are useful across contexts, and I'll give a simple
heuristic for starting testing when you're stuck.
So what is testing? Arborosa has collected many definitions dating
back to the 1950s and I spent some time a couple of years ago looking over them
and reflecting on how I like to work, before coming up with a definition that
works for me:
Testing is the pursuit of relevant incongruity
Boom! It’s a mouthful, but I can unpack it.
Incongruity: Oxford Dictionaries define this as "not in harmony or keeping
with the surroundings". I interpret lack of harmony as a potential problem and
lack of keeping as an actual problem, and those two interpretations are
interesting and useful in testing.
Pursuit: Again, there are two senses that capture important aspects of testing
for me. You can pursue something that you don't know is there and that you may
never find, like a dream. Or you can pursue the solution to a problem that you
know you have, that's right in front of you.
Relevant: if this work doesn't matter to anyone, why are we doing it? Whoever
that is can help us to understand whether any incongruities we identify are
valuable to them, relevant to the project.
Which is great but, so what? Well, I can use it as a yardstick to gauge my activity against: I might want to be testing but realise I’m doing something else; I might be happy to do choose to do stuff that needs doing but isn’t testing.
Testing doesn't proceed in a linear fashion for me, either. I will typically choose to do something, get data from it, review that data, and then decide what to do next in a cycle.
To help me to test, I use tools. I've listed some of them here:
And what is a tool? For me it's simply a thing used to help perform a job and I've thought a lot about tools. (Take Your Pick: Part 1, Part 2, Part 3, Part 4.)
I have a toolbox that I carry with me, and I've taken care to become familiar with the tools so that I can
reach for a tool that looks appropriate when I need it. My shed is organised the same way:
I like also to have a cache of stuff that isn't tools I'm familiar with and skilled at using, but which might come in handy, like this box of bits I've emptied out onto my bench. Sometimes the shape of the problem in front of you doesn't fit the shape of any of your tools, but there may be something in the box that can be offered up to it.
Perhaps I've used Selenium and have a grasp of its workings, its pros, and its
cons. That's a tool and it's on my shelf. Let's say I've seen a webinar about
Cypress and talked to a couple of team members who have experimented with it.
That's in my box. If I see a problem that is similar to one I might use
Selenium for, but isn't quite the right shape, I might reach for Cypress.
It's also important to practice with your tools. Learn when they apply well
and when they don't. This tunes your intuition about when they'll be helpful
or when they're actively working against your need. It also helps you to keep
up to date and skilled with them.
Here's a few of the tools I use all the time:
The best testers will be layering their activities. They’ll have a mission in
mind but will be consciously trying to approach it in a way that gives them
the chance to uncover other things. For example, they might be able to think
of three ways to check some functionality and they’ll choose the one that
exposes them to a bit of the product they haven’t seen much of, or has
recently changed; maybe they’ll see a usability issue, or a performance
problem that way.
The skilled tester might leave environments around when they’re finished with
them so that some other later testing can be done in a dirty environment not
in something that has been set up just for the test. Sometimes just coming
back to a system that has been running by itself for a few days can show a
problem.
I urge you to do this kind of conscious, intentful testing! Of course, a prerequisite for
that is starting and sometimes it's not easy.
Yes, it can be challenging because you don't want to make a mistake, to look
foolish in front of new team mates, or set the project off down the wrong
path. But I have a helpful heuristic:
You don’t necessarily need to wait for the requirements, or stability, or even
a build of the application under test to start testing. Begin where you are!
Some factors that can help you to
understand where you are:
- constraints: budget, resources, time, ...
- context: what is this product for, who is it for, what do they want to do, ...
- value: who are your stakeholders, what are they looking for from you, ...
Choosing what to do next to deliver value to the project is setting your mission and I
like to frame my missions using this slight variant of Elisabeth Hendrickson's charter template:
On a recent project I joined, I thought that the biggest challenge to customer
and business value was (the way I saw it) disagreement amongst three stakeholders. In this case, I wrote a 2-page product description that
crystallised what I thought we were building and importantly what I thought we
were not building. When this was put in front of the team, and the
stakeholders, we were able to have a conversation that squeezed out the
differences.
You might reasonably ask whether I was testing. I think that in the main I
was, yes. I was pursuing relevant incongruity.
I said three key things were needed for testing but in fact there's a fourth:
something to test. I realised while I was writing the talk that I've encapsulated pretty much
everything I've said so far in a page on my team's wiki. I pair with someone
from my team every week. As a manager, ad hoc pairing is tricky for me to set
up, but a recurring calendar appointment works. So I came up with some
guidelines to help others help me to be involved:
I like to set the mission so that we are intentional and I like to reflect so
that we have a chance to learn and change, but the key thing here is that I'm
happy to start anywhere on anything completely from cold. I'm confident that I
can bring something to the party wherever, whenever, and whatever that party
is.
So that's how I test anything: I have an idea what testing means for me, I
find and practice with tools that help me to achieve it, and I'm not afraid to
start from where I am and iterate.
Here's the video and full slides:
Thank you James for your blog post, it was insightful. I am also to have found Elisabeth Hendrickson's charter template through your blog.
ReplyDeleteThanks, Trevor. I hope you find the template as useful as I have over the years.
Delete