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!
Nice post. I have a small issue with your last statement:
“People give testers scripts with explicit steps and observations, then ask /the tester/ “Why didn’t you find that bug?!” ”
Who are these “People”? I haven’t seen non-testers giving test scripts to testers. The issue as I see it is rather the now common structure that the “good” testers, whatever good means, write the test scripts, then hand them over to other testers, either internally or off-shore.
In my experience this approach is popular with Project Managers and senior Managers as this seems to be a good way to save costs – let the experienced testers do the thinking and script creation, and the inexperienced do the execution.
The reason why I’m going on about this is that grouping the decision makers together is making it harder to grasp.
Make it personal!
If someone wants that approach, let them know the downside and make sure it’s understood and not glossed over. The message that execution is a mindless activity should be set right, otherwise it’s checking, not testing.
Well, I picked the quote from Bolton, while he spent some time in India last year. It seems that there are Indian testers treated in this way. Since I did not have the background about the larger context, I took it.
Your point is really valid, and I think you brought up a new blog entry about the downside of telling other people what to do, and just doing the planning, based on a story from my past. Hope to write it up today.