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.
Where are all the good testers?