The Testing Dead Part 1

Posted on Posted in Everything, Software Testing

The zombie apocalypse has occurred. They walk among us even now – The Testing Dead. These dead-eyed, soulless creatures make sounds that seem human, but they’re an empty shell inside and will bite you if provoked. Left unchecked, Zombie Testers will infect an organization with their disease. Zombie testing is any rote application of testing practice or methodology without regard for how appropriate it is in that context. It often looks like one or more ‘skilled’ testers churning out test cases for meatbot automatons to execute, but there are no doubt those who identify with context driven methodologies who have missed the point and follow the same go-to patterns regardless of context.

While there is some amount of tongue-in-cheek in this analogy, it does describe actual patterns of dysfunction that I’ve observed. I want to be clear at this point that I’m having a go at a kind of behavior. I’m not trying to demonize people.

 

There are a number of different flavours of Zombie. See if you recognize any of them.

The Misled

These are the ones who finished whatever secondary or tertiary education they did and decided they were done learning for the rest of their life and could they please have a job where they could memorize and regurgitate the right answers like they did in school. Not particularly adventurous, they might have found some of the large amounts of crap online about software testing and decided that was just fine thanks. Give me a recipe to follow or a template to fill out, but the dark gods forbid I should have to think for myself.

The Template Weenie

A variant of the Misled. They discovered some testing templates online or perhaps their company had some already put together. Their belief is that if they fill out these templates and no gaps are left, then good testing will have been done. If they’ve got all the requirements covered and tests all trace back to them, and the test plan is all filled out and the schedule is set properly, then we’re all good. It appears that for them, reality is an obstacle to be managed with paperwork.

The Passenger

The passenger has fallen into testing but has no desire to be there. They have no desire to be a tester, but are using testing as a bridge to somewhere ‘better’ (typically programming, business analysis or project management). They tend to do only enough work to avoid reprimand and will often be found hanging around the group they’re trying to break into as though they might be absorbed by osmosis.

I generally try and cut a deal with passengers should I encounter them. It is in our combined best interests to move them on, so I promise them I will do everything in my power to get them where they want to go if they agree to be the best tester they can be while they are with me. If they have a strong body of work I can show the manager of the group they want to transition to, and I can honestly talk about the strength of their efforts, then that tends to lend great credibility to their application. Sometimes that approach works, sometimes not. If they won’t let you help them to get where they’re going, you may wish to help them out the door instead.

The Apathetic

Similarly to the passenger, these zombies have no real desire to get better at testing, they simply want to turn up between 0900-1700, go home, rinse and repeat. They won’t think about or do testing in their spare time, it is merely a job. To some degree there’s nothing inherently wrong with this, but personally I’d rather work with inspired, passionate people that genuinely enjoy what they do and want to do it better.

In some respects having a few apathetic zombies around can make your life easier – they tend to be the ones who enjoy predictable monotony and there’s often no shortage of that in testing. If you have repetitive work that is difficult to automate, these people can be handy.

The Confused

This lot think they’re doing Quality Assurance when what they’re doing is testing. Quality assurance is really a collection of roles and actions that have a direct bearing on the quality of the product, such as the hiring/firing of programmers, architects etc, Decision making about what to include or what to leave out, which design to go with, which vendor to go with and so on. In contrast, software testers reveal information about the product. Some testers write production code, but in their role as a tester, they do not directly influence the product itself. The Confused either do not get this, or vehemently believe that their role is to be the final bastion of quality before the software goes out into the world.

They tend to enjoy grandiose titles such as ‘Quality Assurance Engineer’ despite not doing quality assurance and not being an engineer. They also seem to actively position themselves as the gatekeepers of the software release decision, apparently blissfully unaware that it’s a lose/lose situation for someone with the word ‘quality’ in their title to be attached to. If they say no to a release, they’re either overridden by the people with real power (and who probably have a better business sense of what needs to occur), or they’re seen as the ones holding everything up. If a release goes out and something screws up in production, they’re the ones who get fingers pointed at them and asked questions like ‘Why did you let that bug out?’

I’ve seen on testing forums questions like ‘We had some bugs go to production. My manager is asking me why. Can someone give me some excuses I can tell them?’ Wow, just wow. The level of non-comprehension about one’s own job that this question requires is mind boggling.

The sadness doesn’t end there though. Not only do the confused make their own life hard, but they like to make life harder for their non-testing peers also. Things like testing entry and exit criteria, based on arbitrary bug counts of varying severity (e.g. no more than 1 severity 1 bug and 5 severity 2) tend to make people’s life unnecessarily difficult.

The Priest

A variant on the confused, these guys perform ritual testing. It’s testing theatre in much the same way that the TSA do airport security theatre. It may find some stuff, it may not. It gets applied to everything in the same way because that’s how it has to be done. It’s their religion. This is the way testing must be, for this is the one true way of testing. I’m not sure, but they may be an evolution of the template weenie, like some mutant fucking pokemon. Fortunately I haven’t encountered too many of these.

 

 

The Horde

The horde probably resembles their traditional zombie counterpart more closely than any other zombie type. Although they are a large group, They share nothing more than proximity and brain death. A website (or app or other software) will be left out in the open like a sacrificial virgin. The horde descends upon this website under the guise of crowdsourced testing whereupon individuals compete with the rest of the group in order to find something vaguely bug shaped upon the surface, like little zombie rhesus monkeys.They are paid by the bug, so when you take their bug away from them well, have you ever tried taking food away from a rhesus monkey? It’s a bit like that.

They are largely incapable of following instructions unless said instructions are very, very precise. Instead, these zombies have specific go-to patterns they use to find bugs, such as turning on Internet Explorer’s ‘bitch about everything javascript related’ mode. They will also report every single instance of the same bug despite the fact that they clearly have a single, common root cause. Their bug reports are somewhere between readable and atrocious because it doesn’t matter what quality the bug report is, it just has to be first. Once they have exhausted their suite of patterns, they will immediately leave the victim, generally unmolested but quite free of lice or other surface irritants.

There are no doubt more types of Zombie out there, but these are the ones I have encountered on my travels. There seems to be a common thread amongst zombie testers – the complete lack of desire to do anything differently to how they are doing it now. In a role that demands that we rapidly respond to a frequently changing environment, that seems antithetical to how a tester should operate.

In the next post I’ll talk about why zombie testing is a problem for thinking testers and what we can do about it.

 

The Testing Dead – Part2

14 thoughts on “The Testing Dead Part 1

  1. ” testing entry and exit criteria, based on arbitrary bug counts of varying severity (e.g. no more than 1 severity 1 bug and 5 severity 2) ” – were you on my last project ?

    Looking forward to Pt 2 and how to deal with them ( though thankfully I no longer have to deal with that crap, having moved onto a much better place )

    1. G’day Phil,
      There are some people that can hack working in a place where that sort of nonsense is seen as normal – I’m not one of them. Sounds like you’re not either.
      Glad you’re in a better place now.

  2. Awesome Ben, looking forward to the series.

    I have also worked with many of those you have mentioned above. I was part of a BIG testing center where people went to ‘avoid’ the other roles in the business… so these clowns made up variants of all the zombies you have mentioned.

    One thing that interests me is the sales side. The king zombies that head into companies and sell there little baby zombies… this is prolific! Would be keen on your thoughts.

    1. G’day David,
      You’re talking about sales reps for large testing companies? I’ve run into a few over the years. Most seemed to be genuinely well intentioned, but almost completely ignorant of what I’d consider a good tester to be. They’re well drilled in selling their key-turn solutions and are happy to tell you they’ll tailor them to suit, but I’ve never had one convince me their services were worth more than a small number of people that I’ve trained myself.

      I’ve met one or two snake-oil salesmen, real corporate sociopaths – guys that would say anything to make the sale. None of them knew a great deal about testing either, so it wasn’t that hard to see through the bullshit. I feel bad for people that don’t have the requisite bullshit filter though.

  3. Hi Ben,

    I think it’s important to note that zombie testers often aren’t born, they’re made… by zombie IT groups and managers that don’t encourage testers to learn or ignore their efforts when they do. Zombieism is infectious, after all!

    I’ve seen bigwigs go after newly-certified testers with “why didn’t you catch that” and nothing in the testers’ certification courses would have prepared them to defend themselves. Because of their low status in the company, which was subtly or not-so-subtly reinforced at every opportunity, the testers were expected to act as low-paid goalies.

    In an environment like that, learned helplessness is the norm and it’s hard to escape. The best the non-zombie tester can do in a situation like that is to try to learn all they can (quietly and often on their own tab and time), brush up that resume, and get the heck out of dodge.

    I did LOL at “mutant f**ing pokemon” and I’ll definitely revisit this post every so often to check myself. “Kill the brain, you kill the ghoul.”

    1. There are probably various degrees of indoctrination that go into the creation of a zombie tester. No doubt there are places where there is the sort of systemic behavioral conditioning you describe. It’s insidious. People who know how to think for themselves and are quite bright can still fall into these sick systems and buy into the crap they’re fed. I’ve been there and I have my friends to thank for pointing out to me just how much I’d become affected.
      I do think it’s worth trying to help people that show signs of higher brain function. I don’t think every zombie is a lost cause – that’s why I’m trying to point out behavior, rather than pointing fingers at people.
      My advice to anyone in a sick system would be get the hell out of dodge as soon as you can possibly manage.
      I think one of the big differences between zombie testers and thinking testers is that at some point a thinking tester doing work that doesn’t make sense will think ‘you know what? I think this is bullshit’ and then begin to explore where that thread takes them.

  4. “The 28 days later Infected”
    This testing zombie charges about mindlessly raising bugs about “faults” that no one cares about. They have no interest in solving problems or the value of the information they provide. They live only to destroy, without realising what they are destroying is any lingering respect people may have had for them, or testers as a whole.

    1. Interesting take.
      Most of the test zombies I’ve seen madly raising tickets were responding to management dysfunction (e.g. targets of x bugs per day). Can’t say I’ve seen so many that I’d describe as living only to destroy. If you have worked with anyone like this, then you have my sympathies.

      You do bring to mind a type that I really should have included though ‘The Horde’ – in fact I shall go and add them now. Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *