A Recipe For A Great Software Tester

A Recipe For A Great Software Tester

Thoughts on what makes a great software tester

What are the fundamental qualities of a software tester? What differentiates great software testers from the pack? What differentiates a tester from a developer? Don’t developers also possess these qualities? What’s more, don’t all software engineers have these qualities? If they do, they will always excel at getting high quality software delivered to customers. 

That said, the skill set of a great software tester is somewhat unique. When you add one of these testers to your team, you will find that they discover the most interesting bugs that otherwise would have escaped into the wild.  

In my experience, the best software testers are one part Godzilla, two parts Sherlock Holmes, a dash of Barry Sanders, and a healthy helping of Ernest Hemingway.  Let me tell you why.

One Part Godzilla: Breaks Stuff And Ignores Traffic Signals

A great tester is usually a little bit excited to think about how they will break the software under test.   Unlike the developers and customers, great software testers want to tromp like Godzilla through a city – lumbering and smashing all manner of things. 

When a developer tries to direct or limit testing efforts, great testers take what they are saying and mentally file it… and then they explore the area anyway. They do not ignore the developer’s advice, and they will incorporate it into their test plan. But they do ignore pleas to leave an area untested, or to stop testing when they sense there might be a defect lurking beyond. 

Godzilla does not stop at stop signs. Great testers do not either.

But the tester as Godzilla takes no pride and levels no blame in the amount of smashing done. The trail of devastation left by this Godzilla does not include shell shocked developers.  This Godzilla smashes to find problems before the customers do.  In testing, although rough around the edges, large and lumbering, this Godzilla is a team player.

Two Parts Sherlock Holmes: Solve The Mystery With Deductive Reasoning

Like Holmes, the great fictional detective, great testers are extremely observant. As they are testing, they notice the small out-of-place details, the little things that most others don’t see  – the extra space in the message text, the “i” before “e” spelling mistake on the page.  

These are but the warmup. The game is afoot! After they use their Godzilla tendencies to find a defect, they must now change hats to see why the defect is occurring. 

Great testers find the root cause of the issue. They move forward and follow the mysterious behavior first to where it leads, then backwards whence it came. 

Many testers are easily able to determine why the error occurred. But the great testers are like Holmes. They investigate difficult mysteries whose solutions elude others. They use logical reasoning and deduction to determine all the possible ways an error can occur. And they foresee the implications of the issue, which are the risks to the business or the customer if it is not fixed. 

Like Holmes, based on their deductions and analysis, great testers arrive at logical conclusions. And like the great detective, they solve many thorny mysteries.

A Dash Of Barry Sanders:  Using Intuition And Field Vision, Find And Exploit The Gaps

Great testers can be compared to NFL Hall of Fame running back Barry Sanders. Ludicrous, you say: no one is trying to tackle the testers! But a good tester knows that a gap, if exploited after product release, can result in a real loss for the team and maybe the whole organization. 

Often the developers,  business analysts, specification writers, and product owners think they are all talking about the same thing… but they are not. There is a subtle gap, and none of them can see it. This is because they are on the defensive line, too close to the issue to notice. 

As the play starts, the great running backs watch from the backfield  and have the vision to see the gap as it develops. When the ball is handed to them, they deftly maneuver through the gap, ahead to the open field for a big gain at the expense of the defense. 

But on the next play, the defense is ready. This gap will not be there again, even for hall of fame running backs.

The great testers start watching and listening for these gaps before a single line of code is written. They tell their teams where the gaps are so that they can be closed early and definitively, with luck before the software is even coded. 

And if their coaching prior to coding doesn't help, great testers draw up plays (called tests) that will exploit the gap and demonstrate its severity and impact. And like a good defense line, the project team corrects and ensures that the gap is closed for next time.

A Healthy Helping Of Ernest Hemingway: Tell The Story Accurately And Succinctly 

To convey the importance of the issue or bug to others, you must tell a compelling, detailed, and concise story. 

The best testers succinctly describe the issue, providing accuracy using facts they discovered with their Sherlock Holmes hat on. They tell: what happened, how they broke it, what was expected, the impact to the customer, and the perceived risk to the business if the issue is left unfixed. 

Sometimes the story is very brief. Other times, it seems like a novel. Like Hemingway, they write in a straightforward style, making sure to convey clearly all the information to the reader. If you believe this issue must be resolved, your story must be a bestseller. You should be prepared to convince anyone on your team that your conclusions are sound.

The Finished Products: A Great Tester And High Quality Software

The best software testers possess all these skills and qualities in the right proportions. Not enough of Hemingway’s brevity, and the story just drones on. Too much Barry Sanders, and you wind up hunting for gaps that are not there. Too much Holmes may send you down rabbit holes that aren’t relevant to your end users. Too much Godzilla just makes a mess of things. 

Great testers know how to provide the right mix of these ingredients to ensure your team delivers high quality software that your customers will love.

Further Reading

Garry L. Hahn
Garry L. Hahn
Senior Software Testing Leader
Explore MoT
Test Exchange
A skills and knowledge exchange to enhance your testing, QA and quality engineering life
MoT Foundation Certificate in Test Automation
Unlock the essential skills to transition into Test Automation through interactive, community-driven learning, backed by industry expertise
This Week in Testing
Debrief the week in Testing via a community radio show hosted by Simon Tomes and members of the community