Quality of a Good Tester

Posted on Mar 2 2008 - 10:01am by Raj

What Makes a Good Tester?

A good tester performs the following key functions:

  • Verification. A good tester can certify that it is possible to accomplish certain tasks.

  • Detection. A good tester looks for problems that exist, either in the process or the product.




The tasks of verification and detection are two sides of the same coin. Both exist together, but the ratios of each vary from organization to organization, company to company, and position to position, often changing through the software cycle as well.

  • Prevention. A good tester identifies potential problems before they manifest themselves.

  • Reflection. A good tester looks back at how problems and bugs ended up in the product and analyzes this information to learn how to improve the process in the future.

To perform these functions effectively, testers must understand the general technologies used in their product and the product’s particular implementation of them. The tester must also have the mindset to break things and ask the questions that will let him learn more.

It makes sense then that one of the key qualities of a good tester is the ability to ask questions—the right questions. Some people let the old saying, "If you have to ask, then you don’t understand," prevent them from moving forward. Asking good questions is the best way to learn, though. There truly are no stupid questions, although there are questions asked of inappropriate resources. Identify the right resource to take various types of questions to. One reason why you find so many questions posed and answered in this book is to instill in your mind the habit of creating these questions and then searching out the answers. The best testers are constantly asking questions of the software—interviewing it and interrogating it. Once testers learn this skill they rapidly excel in their profession and exponentially grow their knowledge of the code they are working on. The approach is a Socratic method of learning and helps to teach you how to teach yourself.

Another vitally important, and sometimes forgotten, characteristic of a good tester is tact. Testers see the unfinished side of the company, even the ugly underbelly sometimes. They also directly see where bugs come from and who caused them—architects, developers, designers, or management. A good tester understands that the rest of the company often views their organization as a necessary evil at best (and an unnecessary evil at worst).

Consider the product development situation for a moment. Product and program managers work to correctly identify features and behaviors that have come from customer interviews and studies. Developers labor long hours to make the software, everything from the high level of the user interface down to the complex algorithms that dictate behavior. They need to identify potential error conditions and then handle them properly. Developers build a product very carefully; they put their knowledge and experience and effort into it. Then, this component, which so many have labored to produce, still in its infancy, gets handed over to the testing organization. Test is to pick up that baby and commence with telling the developer exactly how ugly that baby is and how deformed it is. That is a tester’s job. No component is perfect; if it were there would be no need for a testing organization. However, the way in which these issues are identified has a great effect on how you, as a tester, are viewed. This, in turn, affects the relationship you have with the other parts of the organization.

Practically, what this means for the individual testers is that they must hold themselves to a high standard of behavior. No finger pointing at the ugly babies! No laughing at the ones you find odd! There is a substantial difference between saying, "My God, Joe! How the hell do you manage to dress yourself in the morning? This code looks like something my cat coughed up," and saying, "The recent billing features that were added are unstable under basic user scenarios. I would like to go back and have the feature implementation reviewed before we continue testing." In the second example, the fault is where it should be—in the code. There is no need to question Joe’s abilities. The development manager or the testing manager has the job of tracking down where the bugs come from. Your job is to identify what needs to be fixed, and the easiest way to do that is to not set up an adversarial relationship with those who depend on you.

Here’s a real-world example of what I mean. Many projects use a process requiring all bug fixes to be built in isolation and certified by testers before any changes can be checked into the main build tree. In one instance, a developer put five bug fixes together and handed it to one of the testers. The tester found some immediate problems and sent out five emails to the group within 6 minutes, one for each problem with each bug fixed. Such an approach does not encourage a developer to work closely with a tester. In this situation, the tester could have communicated the same information by putting all the issues into one mailing and addressing all the issues at once, instead of pointing at the developer repeatedly in front of the organization.

Your role is to ensure a high-quality, stable product. A good tester makes any developer they work with look good. And a good developer realizes this and values the tester that finds the problems in the code by working cooperatively to identify further issues. Another real-world example illustrates my point. On one team I worked with, testers who found lots of problems would hold up developers from checking in their code to the main build tree. One day, in a discussion about these holdups, I apologized for holding up one particular developer’s check-in once again. Very firmly the developer told me no apology was necessary and that what I was doing was exactly what he wanted. He knew that having his code thoroughly tested up front meant that he would probably never have to revisit it. He would not have to worry about a bug being discovered in his code at the very end of the cycle when it would be most visible to management. In that short discussion, I learned that the developers on that team had divided the testing organization into two groups in their own minds—testers who would thoroughly check everything prior to giving the green light, and testers who the developers knew needed to be double-checked. He was one of the appreciative developers who knew how to use Test to his advantage—and he never forgot to thank the testers, even when it was in the late hours that fixes were given our approval. He was also one of the most demanding developers, insisting that testers understand the application they were testing and the technologies involved. Many testers make the mistake of avoiding developers at all costs. This cuts out important pieces of communication: Communicate with the developers and the program managers. Such communication makes you more effective and makes your job easier.

About the Author

Leave A Response