By Kate Paulk

What Does "Good Software Tester" Mean?

Before talking about what a good software tester is or what makes a good software tester, it helps to define what's meant by a "good software tester". Depending on who you ask, there are at least as many definitions of "good software tester" as there are testers, and any of them can be valid in someone's circumstances.

Testers get ranked by seniority, by defect count, by skill, by knowledge, even by how well they get on with their team. It all depends on the needs of their employer and the needs of the work they're doing.

That said, after a bit of trawling through job sites I came down to three main groupings that people use to define what makes someone a good tester. I used job sites because by definition someone hiring a tester wants a good one (for their definition of good, naturally).

Those groupings are based on:

Skills (can do these things) - job sites often have skills like writing test plans, communicating, creating bug reports, and so on. They might also include using a specific tool to create automated tests.

Attributes (is this kind of person) - words like "dedicated", "motivated", "passionate" tend to show up in job sites.

Knowledge (knows these things) - these tend to be a bit harder to parse out, but are usually identified by phrases like "familiar with". Software development methodologies are pretty common, as are domain-specific criteria like "familiar with the x industry"

Every definition of a "good software tester" out there has some skill-based criteria, some attribute-based criteria, and some knowledge-based criteria. What differs is the proportion of the three groupings, and what specifically gets listed in each criterion.

Knowing what makes a good software tester can help testers to target specific areas to improve on. The knowledge can also help managers mentor and evaluate their testers, and craft better job ads to hire new testers. The specifics might vary from workplace to workplace, but the general principles don't.

Some Definitions

Since there are so many ways to define a "good software tester", enough that I could probably find more definitions than testers if I tried, I'm going to set up my definitions for the purposes of this article. These are first and foremost my opinions. Disagreeing with me is fine. If a definition of "good software tester" works for the environment its used in, it's a valid definition. "Good" is such a relative term, after all.

I'll be covering what I consider to be the characteristics of an "OK tester" as well as what I consider to be the characteristics of a "good software tester". Both definitions are deliberately open-ended, because traits that make someone a good software tester in one environment can make them an OK tester in a different environment.

Definition Of An OK Software Tester

An OK tester is someone whose knowledge and/or experience is limited. They may have a lot of experience in a narrow field of testing and very little experience outside their field of specialization. They may need more structure than many modern environments provide, or they may simply need more experience and encouragement. Their skill-set, what could be called their tester toolbox, is likely to be focused on one, maybe two areas.

Many OK testers can and will grow to become good testers if they can find the opportunity and encouragement.

Definition Of A Good Software Tester

A good software tester has a broad range of knowledge, experience, and skills, and is very skilled/knowledgeable in at least two of them. Good testers are able to adapt to new environments and become productive in a shorter time than average when faced with an unfamiliar environment or skill-set.

Good testers are typically self-starters: they will teach themselves new skills and practices to improve their tester toolbox, and will often try to help others to build on their abilities and skills. They are also likely to seek out mentors within or outside their company to help them build new skill sets.

The Case For Skills

Skills are a large part of what lands in a tester's toolbox. In part, this is because some of the skills a tester needs can be measured, sometimes called “hard skills”. Things a good software tester can do are often easier to describe than things a good tester knows or things a good tester should be.

The Hard Skills

Hard skills are generally things that can be measured, like programming ability with a particular language, ability with a specific tool, and so forth. Job ads often list a lot of hard skills simply because they're easier to judge or measure than soft skills, like communication. It's also common for a hard skill to stand as a proxy for a softer skill, especially in job ads.

There are a number of hard skills that fall into the kinds of skills a good software tester needs. Some of the more common ones, and the underlying softer skills they may represent, include:

SQL - A good tester will be querying a database used by any application they're testing. Sometimes testers will also need to update and modify databases to prepare data. So understanding SQL and being able to recognize and use different "dialects" (every database provider has differences in syntax, although the core functions are usually the same) when needed is important. SQL skills are relatively easy to measure, either by online tests or in-person exercises.

Programming - Programming knowledge is often demanded for automation positions. A basic understanding of programming and limitations is a good thing for any tester. In my experience, programming knowledge is used as a proxy for the ability to define a problem in a way that makes it solvable by a programmer which is similar to the skills a test automator needs in order to determine what to automate and how to automate it. General programming skill is harder to measure than skill with a specific language but can be done by asking for structured English or pseudo-code.

Programming language experience - Having experience working with a specific programming language is another common prerequisite for test automation. Knowing the language an application is written in can help a good tester work with it, but it isn't essential.

Writing test cases/test plans - This skill is in most cases a proxy for the ability to decide what needs to be tested and the ability to communicate test results in a format that's easy for non-testers to understand. It's not easy to measure the ability to write test cases or test plans (or any other form of test documentation in my experience) simply because I've yet to see any kind of test documentation survive an encounter with the application in test unscathed.

Application lifecycle tooling - This can be in the form of a specific bug tracker or an all-in-everything application lifecycle management suite. Either way, using some form of tool to monitor the progress of development and testing is a core skill for a good tester. Measuring the ability of a tester to use ALM tooling effectively is rather more challenging, which is why most of the job ads I've seen ask for experience with specific tools rather than skills with tooling.

The Softer Stuff

Soft skills get their name because they are clearly skills that need to be learned before they can be used effectively, but aren't necessarily measurable. Sometimes the only way to measure a soft skill is by proxy using an associated hard skill. In other cases, the only measurements are subjective.

Testing being an activity that exists in the gaps between the creation of software and its delivery to one or more customers, and one that often focuses on gaps between expectation and reality, tends to be something that needs a lot of soft skills.

Some of the soft skills a good software tester needs are:

Communication - Communication skills is a very broad collection covering formal and informal, written, verbal, peer-to-peer, to-supervisor, to-subordinate, and every other possible combination imaginable. A good tester needs to be able to decide how formally to communicate, who to communicate to, and what data to communicate. None of this is easy to do, nor is it easy to measure.

Critical Thinking - Critical thinking skills is another broad collection covering analysis, deduction, problem solving, research, troubleshooting, and many more. For a tester, the skills in the critical thinking group are essential to deciding whether an anomaly is a problem, how much of a problem it might be, and what to do about said problem. They're also essential to deciding how to communicate our findings and to knowing what to test when. Of course, skills like this are almost impossible to measure. The most common thing I've seen is in job interviews where puzzle tests are used as a proxy - a very poor proxy in my view because the only thing puzzle tests really measure is how well a person can answer puzzle tests.

Leadership - Leadership skills for testers can include the typical set of "management" type skills for those of us in charge of a test team, but for most testers, the leadership skills used are things like leading by example and mentoring. Like critical thinking skills, these are not easy to measure and are typically judged by how many years a person has been in a leadership position along with the way the person presents themselves in interviews or internal evaluations.

Teamwork - Teamwork skills usually include a lot of overlap with the communication, critical thinking, and leadership skill sets, especially when a tester is working closely with non-testers who harbor misconceptions about testing. The only true measure of teamwork skills is a productive, well-functioning team, but this is not an individual measure: it's a measure of the teamwork skills of all the team members. From what I've seen, teamwork skills are usually judged by the impression a person gives in an interview or evaluation.

The Matter of Necessary But Not Sufficient

Most of the skills I listed are necessary to being a good software tester. Depending on the requirements of the position, some of the more technical hard skill may not be needed, but having them will give a good tester a better picture of what is going on behind the screens.

That doesn't mean they are sufficient. Most developers have many or all of the skills required to be a good tester, but it's not uncommon for developers who test to find and fix the immediate issue while missing some of the secondary or tertiary impacts. Good testers will keep the larger picture in mind even as they dig into the details, and will be able to catch - or even predict - many of the knock-on effects of a problem and a patch.

In order to do this (I like to call it tester-magic) good testers need more than just skills. They also need attributes.

The Problem With Attributes

Attributes are tricky if not impossible to measure well, not least because one person's curiosity is another person's insufferable nosiness: in short, it's impossible to judge someone's attributes with any degree of objectivity (or accuracy).

Some of the more common attributes of good software testers include things like:

Fast learner - Anyone can claim this and it's next to impossible to measure or judge unless you know the person. That said, a tester who isn't a fast learner will be overwhelmed any time they move from one business domain to another, or have to adapt to a new technology.

Adaptable - Again, this is an attribute which is easy to claim and very difficult to judge. Good testers can handle the way a tester's day can completely change in an instant (such as when a mission-critical problem occurs in production and nobody knows how to handle it - I think I've seen this happen maybe three times in my career, but being able to drop everything and deal with what's happening is essential if and when it does).

Multi-tasker - This attribute isn't, strictly speaking, accurate. Humans can't truly focus on multiple things at the same time. What we can do is minimize the cost of task-switching, and that is something a good tester must be able to do.

Detail oriented and big picture oriented - A good tester has to be able to focus on the details to keep the little things from becoming big ugly bugs, without losing sight of the overall goal. It's not an easy judgment call to make, but a good tester will do this all the time.

When Objective Judgment Isn't Possible

It's easy to judge someone by how well they perform in a test. Unfortunately, desirable attributes aren't things that can be measured by any exams in existence. This means that an organization that wants to hire a good software tester has to look for the attributes they need over the course of an interview.

In addition to the usual pitfalls of interviews like the interviewee being nervous or accidentally stepping on an interviewer's hot buttons, the relatively limited time frame means that someone who is determined enough and good enough at acting can appear to be the kind of person the interviewers want to employ. When someone does this, it can be difficult to remove them before they damage their team and sometimes their company.

Attributes can also be problematic when they aren't aimed in the correct direction or when the person doesn't have the necessary skills to use that attribute as effectively as it could be used. I'm quite prepared to admit that I have issues with getting caught up in something I enjoy to the detriment of the bigger picture goal. I also, as a fledgling tester, had issues with good judgment - I was more than dedicated enough to keep working on something, but I didn't know when to stop. There were times when I had to be reminded that my time was better spent on something more important to my employer.

Clashing Values

Sometimes there can be complications when the attributes an organization seeks during an interview aren't what is actually wanted, or the attributes the team values clash with the company culture. This isn't necessarily a bad thing: one of the more common ways to trigger a change in organization culture is to bring in people who effectively model what the organization wants from people. When a good software tester is brought in to help overcome a culture that's not as concerned about how well the product works for its users as the organization (or product management) would like, the challenges can be… interesting, especially if other team members are hostile towards the proposed changes.

There's also the rather common situation where the kinds of attributes that a good software developer has come into conflict with the kinds of attributes a good tester has. A good tester needs to be able to see where the software doesn't match up with its purpose in some way, which can lead to issues if the tester's communication skills need improvement - or if the developer is the kind of person who has issues with perceived criticism.

Knowledge Isn't Everything

Knowledge, the third grouping of criteria used to decide what makes a good software tester, has the dubious distinction of being both easier and more complicated to determine. The biggest reason for this is probably typical of testing as a career: much of the knowledge that's needed for any non-trivial testing task depends a lot on the exact nature of the testing task. The knowledge needed for testing an application intended to run as firmware in a medical device is rather different than the knowledge needed to test a social media app.

That said, there are certain types of knowledge that tend to be commonly expected of good testers:

Domain knowledge - Knowledge of the nature of the business the software serves is a common requirement for testing positions. Someone can be a good tester without that knowledge, but they may not be a good tester for that position without it. Or they may be good enough in other areas that they can take the time to learn the domain. Either way, testers are often most effective when they're deeply familiar with the business (or other) domain they're working in.

Technical environment knowledge - In job ads the need for knowledge of the technical environment is usually stated as "familiar with x" where x can be anything from an operating system to an automation tool. As with domain knowledge, if a tester can learn it quickly, they can usually go from an OK tester for that environment to a good tester for that environment in a reasonably short time.

Assumed knowledge - In my experience, no matter where a tester works, there will be a certain amount of assumed knowledge. Typically testers will be expected to know how to type, how to use software like Microsoft Office and its equivalents, and generally speaking how to find their way around a computer.

Knowledgeable But…

Of course, knowledge alone isn't as useful as it could be. It's one thing to have read the books and know the information, but if you don't know how to use what you know effectively, you're not going to do as well as someone who does use their knowledge. In short, while knowledge can be helpful, if it's not applied where it's needed, it's not going to be very useful.

Knowledge can also be subject to the old saying, "If all you have is a hammer, everything looks like a nail". Without knowing how to properly apply knowledge, the results can be less than ideal.

When I Was A Wee Little Lass

Knowledge goes out of date, especially in a field as changeable as information technology. People's knowledge tends to "freeze" at wherever it was when they last dealt with it in any depth, with the result that as time passes, what a person knows has a way of getting ever more outdated. The saying, "it's not what you don't know, it's what you know that ain't so" is one a good software tester will keep in mind.

Possibly one of the best examples of the speed at which the information technology marketplace is evolving is the security field. Encryption algorithms that were state of the art 5 years ago are insecure now. Similarly, there are newer and more effective tools for many common software development and testing tasks than there were a few years ago.

The way the testing marketplace is evolving, a good tester needs to build on the basic principles and techniques of testing with multiple areas of specialization covering what has become a vast ever-changing testing landscape.

Putting The Pieces Together

The combination of skills, knowledge, and attributes goes towards making a good software tester but doesn't completely cover it. Like baking a cake, having all the ingredients doesn't necessarily mean that the finished cake will be edible. To really excel, a tester needs to have what I've seen called T-shaped, Paint Drips, Broken Combs, and what I personally think of as a Lazy-E skill set

().

Lazy-E Or Broken Combs

The Lazy-E (taken from old cattle branding terminology where a letter on its side was referred to as "lazy") tester’s skill set is one where a tester has a broad base of skills, attributes, and knowledged, with two or more areas where they have deep skills, attributes, and knowledge. I consider T-shaped to mean one single very strong area, where Paint Drips and Broken Combs, like Lazy-E imply that there are multiple very strong areas.

Of course, it's possible to have a Lazy-E skill set and still not be a "good tester". A person can be a highly skilled test automator, and have trouble defining test cases for automation. Or be extremely good at following defined test cases and tracing inconsistencies, but not able to deal with unstructured work environments.

To move from okay to good, a tester also needs to fill in gaps.

Filling In The Missing Pieces

In many ways, a good software tester looks for things that aren't there: functionality that's missing from the application in test, gaps in process that make getting the application to market more difficult than it needs to be, missing checks and balances, and so forth. It's a little like looking at a jigsaw puzzle with half the pieces missing and being able to see what should be in those gaps, then using one's skills to find the missing pieces and fill in the gaps.

Learning to find gaps includes setting up processes to the point where they are working for the team, learning new skills in order to do what needs to be done, not to mention continuing to hone those skills. Creating this kind of learning environment is moving into the territory of skills, attributes, and knowledge that is almost impossible to measure and starts to fit the saying, "I know it when I see it."

The combination of skills, knowledge, and attributes which are required to be a good tester don't necessarily guarantee that a person who has them is a good tester. That hard-to-define something that makes the difference is quite noticeable when it's present. It's worth noting that even having "it" is not necessarily going to help in an interview if the interviewers are looking to check off specific skills before they consider hiring.

Becoming A Good Software Tester

So how does a tester make the jump from being an okay tester to being a good software tester? As always in the testing field there's a big "it depends" factor. If you're looking at what makes a good tester from the perspective of being the best tester you can be, then there are a number of things you can do.

Changing From Gatekeeper To Advocate

Possibly one of the biggest is stepping away from the mindset of testing as a quality gate. The belief that a tester can control the quality of a piece of software is one of the most damaging ideas in software development. We testers don't write the software, we don't fix bugs, and we don't have the authority or information to make a decision about whether or not to ship it. What we can and should do is report to our stakeholders about the state of the software we're testing in a way that allows them to make the ship/don't ship/fix/don't fix decisions.

Letting go of the quality enforcement role allows testers to really shine. We can do what we do best; namely digging into an application and finding the gaps between what users are likely to expect and what the software actually does. By enabling others to make informed decisions and advocating for a good customer experience, we're transforming ourselves into better testers.

Keeping A Good Perspective

Another huge step to take between okay and good happens when a tester can remember that "Perfect is the enemy of good" - if an application is good enough to please customers, it's good enough that the cost of improvement probably isn't justified. Keeping this in mind is a matter of perspective that a good software tester can't do without. The balance between good enough to keep your customers coming back and good enough to keep the often perfectionist inner-tester happy isn't easy to keep, but remembering that catching those last few bugs can be more expensive than the returns from fixing them justifies is helpful. So is remembering that extending and maintaining slow or flaky automation can be more expensive than a carefully selected manual regression test suite. Return on investment (ROI) is important to good testers because it allows them to use their time in ways that give themselves and their employers the best ROI they can.

So What Makes A Good Software Tester?

While the exact nature of a "good" software tester can depend on the situation, a good tester can adapt to most situations they encounter as testers, and provide many benefits and advantages to their employers. Yes, it is a frustratingly vague definition, but with the way testing works, this is likely to be the best definition available. After all, every organization is different, every piece of software is different, and every test task is different.

As long as testers can adapt to the rapid changes in their field, and they're continuing to learn and find ways to improve the skills, attributes, and knowledge in their tester toolbox, they'll be good testers. They just have to find a place where their abilities are valued and their toolbox is a close enough match to the company needs that they will be able to fit in and grow without too much conflict.

References

Author Bio

Kate Paulk refers to herself as a chaos magnet, because if software is going to go wrong, it will go wrong for her. She stumbles over edge cases without trying, accidentally summons demonic entities, and is a shameless geek girl of the science fiction and fantasy variety, with a strange sense of humor.

In what she ironically refers to as her free time, she writes. Novels, short stories, and more recently, articles for the Dojo.

What Makes A Good Software Tester