6 Things You Should Never Say to a Software Tester

1. “Can you hurry up and finish testing soon? We’re under a very tight deadline.”

Good testing cannot be rushed. Ideally, testing should begin with the design phase of a project and continue all the way through. Software testing is ultimately about validating the design requirements, but to be effective at that, the testing process must begin with the design stage itself. When testing is started later, it can be less effective. Designers must sync with testers, developers must sync with testers, and valuable time is wasted getting teams and technology expectations to mesh. This is a recipe for delays, confusion, and budget overruns.

Starting the testing process with design lets testers be involved  from the beginning. They can contribute early, get to know the product early, and be involved early. That makes for better testing and that makes for a better product.

2. “Promise me there’s no bugs in this, okay?”

It’s been argued (correctly, in my opinion) that the role of testing is not “quality assurance” but rather “quality assistance.” I believe that phrase originated with Jon Bach, but don’t quote me on that. Basically, quality cannot be tested into a product, thus a tester’s job is not to verify that a product is error-free, but that it has passed (or failed) to meet a certain set of standards, which vary from company to company. Leave the outlandish promises to the marketing and sales departments. Keep testing in the realm of reality.

3. “You must be bored out of your mind.”

This is a huge myth of software testing, but one that’s easy to dispel. Go to a testing conference, read a few blogs and articles and you’ll quickly see how passionate testers can be with their craft. 

Here’s a nice quote from Michael Bolton that pretty much sums it up:

“Testing is something that we do with the motivation of finding new information.  Testing is a process of exploration, discovery, investigation, and learning.  When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing.  We’re testing when we’re trying to find out about the extents and limitations of the product and its design, and when we’re largely driven by questions that haven’t been answered or even asked before.”

4. “I didn’t have time to read your bug report. Give me the 5-second version.”

Testers (the good ones, anyway) spent a great deal of time crafting their bug reports with precision, accuracy and steps to re-produce. When a developer (or other department) doesn’t care to understand the full severity of a bug, it not only wastes the tester’s time, but it can lead to huge problems down the road. The reasons for this should be rather obvious. Instead of the five second version, how about the five word version? Read the freaking bug report.

5. “You’re actually a very nice person. I don’t care what the developers say.”

I had to throw a little humor into the post. On a more serious note, the relationship between testers and developers is not always – how shall I say this – pleasant. As testing guru James Bach once wrote: “Anyone who creates a piece of work and submits it for judgment is going to feel judged. That’s not a pleasant feeling. And the problem is compounded by testers who glibly declare that this or that little nit or nat is a “defect,” as if anything they personally don’t like is a quality problem for everybody.” In other words, don’t stir the pot.

6. “Couldn’t a machine do this much easier?”

Depends on what they’re doing, but even if the answer to that question were “yes” who would manage the automation? Who would analyze the results? Who would choose the tool to use and decide where and when it’s going to be implemented? This doesn’t even touch on the need for manual testing. Machines can do a lot of things, but replacing testers is not – and never will be – one of them.