CAST 2012: The Testing Dead

At CAST 2012 Ben Kelly spoke about the Testing Dead. I think it was a reference to some folks claiming testing to be dead, while Ben rather pointed out that testing is not dead, but rather undead with zombies carrying their undead bodies in front of a computer to do a 9-5 job.

Ben defined zombie testing in the beginning. Ben spoke about Frederick Taylor, and how he introduced scientific management. Taylor broke down activities from craftsmen to smaller steps, and worked with them to make these steps more efficient. Basically he introduced process in order to turn craftsmen into zombies following it, Kelly claimed.

This refers to zombie testing with all of its templates, test plans, and biasing the work of us testers by a particular context. Of course this does not help if the context changes over time. Kelly claimed that any thinking tester should be able to be dropped into any context, and be able to adapt to it within seconds. I think we need a large tool belt of practices and approaches in order to do that.

Kelly provided several classes of zombies, and especially testing zombies. The Passenger is riding the testing bus on the way to a better destination. He typically does enough to avoid reprimand but little more. He also doesn’T see a point in improving their testing skills.

The Confused believes that they are in ‘Quality Assurance’. He enjoys the prestige of the title – like Quality Assurance Engineer – despite having none of the authority that should accompany it. He doesn’t seem to recognize the blame for failure accompanying this position as ‘you’re doing it wrong’.

Kelly raised whether or not this is really a problem. Why wouldn’t we just live and let them (un)live besides us? Are they hurting anyone, anyways? Kelly pointed out to a culture of Zombie testers that hurts us indeed. The segregation of programmers and testers, and backlash against testers in general. Kelly pointed out to a discussion between project managers for half an hour discussing whether this or that bug would be prio 1 or 2. Everyone with children knows there is no point in discussing who is first or second. You eventually have to deal with both. The main problem with these actually is not so much that they exist, but that they are seen as the norm by non-testers like programmers and managers.

What should you do with zombie testers in your office? How do we deal with them? Blog about thinking thinking testers, testers who are not dead. For not influencing the culture of your company, you should probably keep them out of your building. This reminded on the No-asshole rule by Bob Sutton – a great book that you should read, if you haven’t already. You can keep undead testers out of your building by looking properly on their resumes when they apply for a job. Do they have 6 or rather 2 years of experience for three times? Can they define testing in a way that you agree with?

Kelly described the real issue as other people we work with believing zombie testing is the norm. The challenge lies in presenting this to them in a way that is both meaningful and compelling. This is easier said than done, especially for management level people.

Thinking testers are often faced with responses such as “how do you measure your testing?”, or “how do you know if people are doing their job? Kelly explained that depending on the level of organizational dysfunction – I would claim how infected your company by the testing undead is – you will likely need to do a degree of re-education of your non-testing peers. A testers code of conduct sets expectations and lets them know what you will and will not do. From my experience this is proper expectation management that we need anyways.

Help other people get the message. We should go out to non-testing conferences. Present at conference for programmers, project managers, and recruiters. HE also picked up a topic I am currently working on to offer guest lectures at universities for students of computer science and information systems. Get together in user groups and gatherings for programmers. Talk to them about testing, and help them improve their work with testers. Also make sure to invite them to your own testing events.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

3 thoughts on “CAST 2012: The Testing Dead”

  1. I love the Zombie metaphor. This issue has bothered me for years, I’m glad to see so many people now trying to raise the bar in the testing profession and helping also to blur the lines – testers should be part of a whole, diverse development team where everyone is passionate about quality.

  2. I agree with Lisa, the idea of the 9-5 testers as Zombies, is an analogy I’ve used before myself. Some times it’s like watching monkeys doing a task they’ve been highly scripted out to do, and sometimes it shows in a general lack of interest in improving, growing, learning, or being involved in the larger areas of testing. Just leave me alone and let me test, some may say, but never questioning, what are they testing, and are they really ‘testing’, or even ‘testing’ well. Great article Markus.

  3. I am not exactly sure what you mean when you say…
    “You can keep undead testers out of your building by looking properly on their resumes when they apply for a job. Do they have 6 or rather 2 years of experience for three times? “.

    Are you saying a person who has spent 6 years in organization is better or worse than someone who has worked at 3 different organizations for 2 years at a time.

    My assumption is that you are saying that someone who has worked 6 years in one organization is inferior to someone who has moved around more.

    To me, that seems a little too simplistic a measure. I have worked in one organization for nearly 8 years. I’ve worked on many different projects/business divisions, with different teams and technologies.

    I recognize the zombie simile but I think looking at tenure without context is a dumb way to measure a testers ‘zombieness’.

Leave a Reply

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