While conversing with my colleagues Bill and Shannon, Shannon threw out the phrase “Zombie Testing”. They had been talking about zombies and zombie survival all morning. As soon as the words came out of his mouth, the lights came on for Bill and I.
We chit-chatted a second about the concept, and I agreed to go flesh it out (pun intended) in a blog posting. Let’s start with my definition (I invite everyone to collaborate with me to come up with a richer and fuller definition.):
Zombie Testing: Mindlessly executing a program with the intent of filling spreadsheets with useless data, writing thick boiler plate bug reports, and meeting company metrics. Find bugs is a secondary pursuit. Any requirements verifications should be done to the letter; there’s no reason to check the intent of the requirements.
It’s true that zombies walk among us! Your fellow software testers might be zombie testers! But how do you know? I’m going to lay out some indicators that might out your colleague as a zombie:
- They act with mindless disregard toward their job (Passive not Proactive).
Testers that have turned display a mindless disregard for their job. They do not think; their brains are not buzzing with activity! They are not analyzing requirements, looking for ambiguities. They are not listening to conversations about new software implementation.
They are not engaged with investigating bugs to find the root cause. They don’t communicate their unsubstantiated concerns and hunches to the developers or the project managers. Zombie testers never pick up on disconnects between technical people and customers, nor would they intervene to increase understanding anyway. They particularly like it when these test cases are written by a QA manager and just executed by them. Less thinking = better!
- They protect the status quo, rejecting new methods of testing.
Not only are their minds soft, but they will seek to eat the brains of all who challenge the group think. They stifle creativity. They have a “not invented here” mentality. Zombie testers will continue to look for bugs using the same heuristics, and they will continue to believe that they are being effective.
Anyone that questions this status quo will be dealt with severely. Past successes will be used to give credence to their methods; they will point to the relative stability of the group’s code base. They will reject radical new testing paradigms like Exploratory Testing in favor of set, predetermined test cases.
Using their super lethargic strength, they will cursh all dissenters until they are assimilated as zombie testers too. Stay clear! Their complacency is overpowering!
- They don’t question developers, other testers, managers, authority figures, or process; they just march slowly and aimlessly in stride with everyone else.
A tester that doesn’t challenge anyone or anything displays traits of potential zombification. Zombie testers will never go against software developers; they will assume that since the developer is an eccentric genius they must know what they are doing.
After all, complicated and over-engineered code is better; right? When the developer makes statements like “I know what the business wants more than they do”, a zombie tester will agree that this technical person knows the business better than the business people.
Zombie testers won’t disagree with other testers that have more experience than them; after all, these senior testers have written more tests than them. These senior testers also protect the status quo, which is great! Zombie testers won’t disagree with their supervisors, even if their supervisor comes in with some crappie half-baked idea that he learned at a conference.
They won’t question the guru testers that have written the books. Never mind the fact that some of those grey hair gurus haven’t tested since COBOL was en vogue.
- They place too much faith in automated testing.
To a testing zombie, automated tests are the end all be all! Every test requires a hammer, and our automated test platform is a big ass hammer. Mindlessly crank these things out. It’s easy! Just model each test on the countless examples that are already in the massive suites.
There’s something so therapeutic about not having to think while writing test scripts. It’s like watching TV. These zombies love to push the button on the suite and watch as all their tests come up green. They are all green so that must mean that the tests are all valid, cover the code correctly, and actually test what we want to test.
If the tester starts to question the integrity of the testing harness or decides to manually check something, he or she is probably not a zombie. He or she is probably a healthy tester doing their job.
- They are more proud of the pretty documentation than the actual bugs they found.
One time, Bill had an interview with a tester candidate that was truly excited about the organization and prettiness of her bug reports. He told me that in his head, he was thinking, “NO! I don’t care about that. I want you to find bugs, not write reports!” If your testers really start to glow and brag about their documentation, then they might have already turned.
If they are overly critical about the way you write up your bugs or insist that you use boiler plate sheets, then be standoffish. They might be feasting on your brains at any moment! Tester zombies are slow, but they can be fast to protect the status quo. If your tester is not excited about they bugs they found or the innovative approaches they took to finding them, be very concerned!
Note: zombie testers tend to value metrics, methods, procedures, and systems more than they value making a difference in the quality of the software. If they constantly quote material from the ISTQB certification test, then analyze how pedantic their tone is. The more pedantic their tone, the more they’ve turned.
- No Related Posts