How to Be a Helpful Tester

Disclaimer: I have not worked as a full time software tester, so this point of view is from a developer who would love to see the following qualities in QA personnel that I work with.

Sometime early in my career as a software developer, I learned that my code was not perfect and needed testing before being released1. Since then I have worked with a couple of good testers, and unfortunately, some truly terrible ones as well. I would very much prefer to work with the good ones, so I thought I would list some characteristics that could help a would-be tester become a great one.

This is the biggest: Your goal is not a checklist. This one is partially attributable to poor management. Testers who are graded on the number of bugs they find tend to try to file as many as they can. Your goal is actually not to find a ton of bugs; your goal is to release the highest quality software possible. I can forgive many testing sins if just this one maxim is embraced.

Understand the application. I am always shocked to read a bug report that is completely at odds with what is written in the application’s requirements. “The app is supposed to work that way,” is far too often the answer. One way to mitigate this is to include testers in the design of the product they will be testing. This includes knowing which developer/department to assign the bugs. In most cases the poor UI guys have 95% of the bugs assigned to them and end up serving as triage for the rest of the group. A good tester knows that even though an error dialog is popping up in the UI, it may very well be because of a problem with the database.

Know your tools. If you are testing a web app, you had better have tons of extensions for debugging, header analysis, and browser tweaking installed. You need to know how to take a good screenshot and highlight the problematic area. This goes hand in hand with “Record important information” in a few paragraphs. Good tools make it easier to specify what the problem is. Taking a screenshot of your entire desktop and pasting it into Word is always a bad idea.2 Knowing the bug tracker inside and out is mandatory.

Leave your ego at the door. This goes for both testers and developers. There is naturally an adversarial relationship between both tribes; one group exists to find problems with the others’ work, but it doesn’t have to be ugly. I once worked with a guy who hated every single QA person he met because his ego would not let him accept that his code had bugs. Conversely, you are not King of the World for finding an obvious defect that the programmer should have caught.

Record important information. Taking a screenshot of an exception screen is a little better than writing “it dun broke” in the description field, but not by much. Does this exception happen every time? With different information? In different browsers? Are there any unique or special rules applied to this specific instance?

I once worked on a product that needed different rules applied to different customers’ accounts. These rules caused a bunch of validation issues and various one-off bugs that couldn’t be reproduced in the development environment (since the rules were different for development and production). It was beyond frustrating to get bug reports that lacked any bit of helpful information to track these nasty issues down, and resulted in many cannot-reproduce/close/re-open wars.

Be specific too! I recently received a bug report that said that the UI I created was different from the wireframe provided by the designer. It included a screenshot of my UI and one of the wireframe. I would have had to play the spot-how-many-differences game. Instead, a good bug would have been to list what was wrong.

You don’t need to know how to program. Though a little bit of knowledge helps. Knowing what an Exception is and how one shows up would be beyond helpful. Knowing how they are thrown in the app you are testing would be even better.

Just the other day, I ran into an issue where an Exception was being thrown, but was actually masking the real problem. The Exception stated that there was a problem with the AuthenticationService I was using. I spent a few minutes trying to figure out what happened since nobody had recently worked on that particular service. We soon realized that the service itself was fine; the problem was actually in the config file shared by all services. The AuthenticationService was just the first one called, so it bombed first. Having a solid knowledge of how an Exception works and why the application is throwing them would avoid red herring problems like this.

This list is by no means exhaustive, but I do feel that if more developers were working with more testers that had those qualities, software in general would be much better.

1. That would have been somewhere between 10 minutes and an hour of writing my first bit of code.
2. Why is this so awful? First, any decent bug tracker will automatically make images easy to browse through and view; hiding it in a Word doc prevents that. Second pasting a screen capture will automatically save it as an uncompressed bitmap and result in a large file size. Even over a corporate intranet, it would still take far too long to download and extract. Seriously, friends don’t let friends use a take poor screenshots.

Written by Scott Williams who lives and works in sunny Phoenix, AZ. Twitter is also a place.