Last week I came across a tweet from James Bach on Twitter:

I break dreams about products, not products.

Since I am currently reading through Quality Software Management – Volume 4: Anticipating Change from Gerald M. Weinberg, I had the Satir Change Model in mind. Jerry cites Virginia Satir there:

It may look like a crisis, but it’s only the end of an illusion.

Adopting the citation from Weinberg, putting it into James Bach’s citation then became the following tweet:

Testers don’t break software, we end illusions about its usefulness.

Alistair Cockburn commented on this with the following:

I liked when a tester said, “My job is to see that once it gets past me, it doesn’t break for anyone else.”

This made me thoughtful. Finally, I realized that I need to put my phrase into context.

What I had in mind with testers ending illusions about software, is the fact, that testers do not put quality into the software just by their work. Tester interactions with the project manager, the business analysts and product owners, the developers and the customer probably end up in high quality software. Often, testers are the messengers of the bad news and might get the blame for their messages, but they shouldn’t. Testers just test the software they get handed and make evaluations about it. We collect the information and our reports maybe let developers fix bugs or make project managers delay product deliveries, but testers don’t create quality, we try to make it transparent. So, my statement is more against the management view on testing as it is prevalent in some organizations nowadays.

On the other hand, what Alistair is referring to is the attitude of a tester at work. Of course, I want to be proud of the job I did and sign for the testing I did. Taking it to the extreme that no one else will find a problem, when I’m finished with the product is a really good attitude. Most good testers I have met had just this attitude. When I have finished testing the product and the manager decides to ship it upon my report, it’s a moment of pride for the work I achieved.

But there is a problem with quality. Quality is time-effective. Software that is perceived to be of high quality, may be of poor quality tomorrow when a competitor delivers a new version of his product and puts my company out of business with it. As a tester, there is little I can do about that. I can communicate about the information I got while interacting with the software. I can communicate about the information that bug fixing seems to take longer and longer, which might indicate Technical Debt. But since I don’t have control over the business schedule, the developers and resources on the project, I cannot decide to do something about it. Instead, I make informations about quality transparent.

Of course, the right attitude for a tester is great, and as I learned the tester Alistair mentioned got promoted several times in the last two decades. But, testing attitude alone does not lead to quality software in itself. On the downside, there are decisions taken for testers and they receive the blame in the end, as Michael Bolton pointed out:

People give testers scripts with explicit steps and observations, then ask /the tester/ “Why didn’t you find that bug?!”

Now, that’s ridiculous!