When we get used to an application, because we’ve logged
into it 100 times and ran our test cases 1000 times, we start to miss things.
Things like regression defects or the fact that the behaviour we’ve accepted as
normal may not be normal to others. We miss things because our testing
perspective and habits become locked, invariable, familiar, efficient.
Familiarity breads contempt.
“They run twice as many cases as anyone else in the team, they
really know the system!”.
Which to many, means they are a good tester.
Conversely, when we’re not used to an application we poke at
it with great intent and focus, everything seems new and interesting, we test
in variable ways, unhabituated to the testing regime that applies, we’re
inefficient (slow), but very precise about what we do. We don’t understand why that data the user enters is in that format, why the user journey is
like that when we’d expect it to be
like this instead, where that message
comes from or goes to, what it means when that status up there in the right
corner flashes orange.
“Is this new tester any good? They’re asking a lot of
questions, raising a lot of defects that are just getting rejected!”
Which
means they’re not a good tester.
But define good.
Good is not procedurally efficient in a way that sees
planned testing executed by or within project timelines, with little or no
issues raised. Though far too many people still need educating in this fact.
At either end of the scale there’s a place where testers are
not ‘good’ at the job. They don’t find defects that are meaningful or they’ve
stopped looking. They don’t … well nothing else actually, if we do nothing else
in a given day we should test well and that’s means a high likelihood of finding
defects. The oft repeated mantra of ‘shipping working software’ is why our
profession exists. You don’t ship working software by just running tests, of
course you also don’t do it by not finding defects.
So surely somewhere along the scale of these perspectives, there
must be a happy medium that is where we need to reach and stay. A place where
the Good Testers are.
There is. That happy medium sees us executing well-structured,
well-thought out, strong test cases, finding meaningful defects, remaining
interested and curious about the application or system we’re testing,
questioning why and how things work as they do, critically evaluating the
efficacy of the test pack we run, intuiting new ways to explore the system,
testing in an aura of familiarity with the system, yet attuned to pick up those
gut-feel tester smells that suggest something is not quite right. Month, after
month, after month, after…
It obviously takes time, experience, and proactive
engagement to reach a point where we represent what ‘good looks like’, to
become a deep technical expert that isn’t floundering about but who also isn't
falling asleep. But, we can adopt many of the behaviours as a standard,
irrespective of our experience. Being actively interested in the world around
us, critically thinking about what is presented to us, carefully analysing the
way things are now, were and could be, reflecting on how we acquire and build
knowledge, practising building mental models.
When we stay in that mode of
thinking and add in an evolving technical understanding of what we’re testing,
enhanced by a growing professional experience, then we are where the Good
Testers are.
Mark
Where are all the good testers?