In my first post on The Testing Dead, I identified a number of patterns of behavior that I like to call Zombie Testing.
Is this really a problem we need to be concerned about?
I think it is, for a number of reasons.
I think Zombie Testing has the ability to infect an organization. It’s a generally less grisly process than your traditional zombie, but the downside is it takes a lot longer to die and it’s only slightly less painful.
How does Zombie Testing infect non-testers? I mentioned in a previous post things like arbitrary entry/exit criteria. Have you ever seen programmers changing bug severity or priority (or reassigning them or closing them) to meet these bogus criteria? Ever been in sign-off meetings where project managers argued about which bugs were severity 1 and which were severity 2 and go on to (re)define what they meant?
This one little artefact that says ‘no more than 1 severity 1 bug and 5 severity 2 bugs or else your code doesn’t get signed off’. It’s a sign that zombie testing has taken hold. Anyone with kids will tell you — it doesn’t matter if it’s number one or number two, you just have to take action before it gets messy.
When Zombie Testers hold themselves up as the quality police, there’s a tendency for others to see them that way also. That invites dysfunction like the segregation of testers and programmers — because the dark gods forbid they should unduly influence one another. The testers need to remain “objective”. Segregation of testers and programmers is one of those ‘won’t someone think of the children’ arguments. It’s a solution in search of a problem that I’ve yet to ever actually see.
Imagine a straight-laced chaperone at a formal high school dance, insisting that testers and programmers may dance, but must keep at least two feet apart whilst they do so. That might seem very civilized and genteel, but everyone knows the real magic happens when the testers and programmers slip away behind the bike sheds and show each other their notes.
More recently I’ve heard and read about some programmers calling to do away with testers all together. It’s a misguided notion, but I can understand where they’re coming from. If your only exposure to testing has been with people that enforce unhelpful rules, have an adversarial attitude, waste your time and otherwise make your life difficult, (whilst adding questionable value) why wouldn’t you want to do away with them?
The problem for thinking testers isn’t so much that Zombie Testers exist. It’s that they’re so prevalent that they’re seen as the norm by non-testers. We need the people that hire testers, the people that manage testers and the people that testers serve to understand what it means to be a thinking, professional tester.
Moreover, we need to them to understand it in a way that’s meaningful to them.
Easier said than done. It’s a tough sell.
Can we go to upper management and tell them that quality will improve as a result of our participation?
No.
It may indirectly, but that’s not generally something we have direct control over. We don’t make design decisions, we don’t hire or fire programmers, we don’t decide what gets fixed or deferred — we might influence one or more of these things, but the final decision is not ours.
Can we tell them their product will be released bug-free?
No. Finding bugs is part of what we do and while we can test for their presence, we cannot prove their absence. Some less scrupulous companies (who may well have a large stable of test zombies corralled somewhere) might say otherwise, but that’s not a claim a tester can make in good conscience.
What then?
The alternative we have is to tell them that we can reveal risks and problems to them much earlier than they might otherwise find out about them, giving them time to take action.
It doesn’t sound like a particularly attractive alternative. In my experience, people don’t want you to tell them about problems (unless you’re also telling them about how you fixed them). They want solutions.
Moreover, many people seem to cling to the broken Taylorist model that software development is mass production. Programmers turn out widgets that come down the conveyor belt. Testers pick up these widgets, compare them to spec and/or known good widgets and if they’re within tolerable limits of variance then all is well.
It’s an attractive fantasy. It’s measurable. It’s controllable. The workers can be switched in and out because it’s repeatable labor. Unfortunately (for those that believe it), it’s complete bullshit.
So how do we put that alternative in a way that is more palatable to an audience that needs to hear such a message, but may not be ready to accept it?
There are no easy answers to that question (that I know of). There’s no silver bullet. In part three I’ll talk about what can be done to help educate our non-testing peers about what software testing is, and what can be done about stemming the flow of zombie testers.
Originally published at http://testjutsu.com on August 12, 2012.
