Why I Won’t Go Back

I was going through some of my old notes yesterday and stumbled across a sketch I made of a diagram of effects showing how test managers become ineffectual. (I re-created it in Illustrator since no one but me could have read my original sketch.)

I’d like to say that back when I was a test manager I never succumbed to this cycle. Alas, I’m sure I did. It’s almost inevitable.

Reading through those old notes was a good reminder about why I don’t manage independent QA/Test groups anymore.

I’d much rather work with organizations to integrate testing activities throughout the cycle and across all roles. The traditional role of a test manager in organizations that practice test-last development is a miserable job. Add in a sprinkle of dysfunctional QA blaming while simultaneously undercutting any efforts the QA manager makes to increase quality? The job becomes a recipe for depression and substance abuse.

Fortunately, I escaped in time.

Subscribe

Subscribe to our e-mail newsletter to receive updates.

11 Responses to Why I Won’t Go Back

  1. Aruna Venkataraman October 12, 2012 at 11:01 pm #

    Hi,

    Looks interesting. BTW, what’s CYA?

    Regards,
    Aruna

  2. testobsessed October 13, 2012 at 12:15 am #

    Hi Aruna,

    CYA stands for Cover Your A**. It’s anything someone does solely to justify their actions. In highly political, fear-driven organizations, people spend most of their time on CYA activities, leaving precious little time to actually get stuff done.

    Elisabeth

  3. Maaret Pyhäjärvi October 13, 2012 at 3:40 am #

    Thanks for sharing, I find something strangely familiar with this. It just left me wondering: not all test team / QA team organizations I’ve ended up in are big in CYA activities. But the level of fear would seem to have something to so with that.

  4. Sharath Byregowda October 13, 2012 at 8:56 am #

    WOW! Love this cycle. I always wondered why would any one invest in such bulky, tester unfriendly test management tools and things explains it all.
    Regards,
    Sharath

  5. Raymond Li October 16, 2012 at 3:05 am #

    The cycle is all too familiar. Sometimes… despite the “agileness” of the team, blame finds its way back to the Test Team. The fear of being blamed is consistently lingering in the background. As a result (as your sketch indicates), we frequently default to CYA activities which generally do not equate to activities that help “catch the important issues.” Is escape the only way? Are there no alternatives?

  6. testobsessed October 16, 2012 at 3:37 am #

    Hi Raymond,

    Is escape the only way out of the cycle? I don’t think so.

    I believe the first step out of the cycle is to recognize that it’s happening. Then you get to decide what to do about it. If you choose to go in the direction that fear suggests, toward CYA activities, you’re stuck. But fear is a lousy compass.

    This cycle flourishes only in organizations that perpetuate a culture of fear and blame. Fix the culture and you’ll fix the cycle.

    You could try saying:

    “I think the best use of my time is to spend more time on <valuable things>, but that means not spending time on <CYA things>. The only reason I do <CYA things> is to be able to defend my work. I’d like to not feel like I have to defend my work at all, and would rather spend all my time on the work that has the most value. What do you think? Can we dispense with <CYA things>, and take responsibility as a whole team for the quality of the final result?”

    Or you could try:

    “I am concerned that I have to spend so much time doing <CYA things> that I don’t have sufficient time to do <valuable activities>. If all those things need to be done, how can we work together to finish all the work?”

    However, the bottom line in both approaches is that the whole team has to take responsibility for testing and quality. If that’s not possible within the organization, escape may indeed be the only way out of the cycle.

    Elisabeth

  7. Leviathon November 10, 2012 at 10:21 am #

    Gave me a chuckle this, absolutely true. The way to defeat this is to push back and start demanding detailed specifications, unit test results and anything else you can think of to hinder and slow development. Yes, I said that out loud!

    Within a very short space of time (one or two sprints) the company stops blaming you and starts asking why these articles are not being delivered by the dev team. After that you can have a sensible conversation with the customer about what can be done in the time available. You can then introduce MoSCoW and ask the business to put in time to decide what gets tested and what does not.

    Once the beast is tamed and the parameters established you must deliver on your promise, so don’t offer what you can’t deliver!

    Oh, and if you haven’t got a thick skin don’t be a test manager. It takes guts to turn up day after day and get brow beaten by a dozen people and if you can’t fight your corner your life really will be as miserable as you say Elizabeth. Lovely diagram, you have nailed this absolutely.

  8. Pat Maddox November 12, 2012 at 10:47 pm #

    @Leviathon I’m curious as to what you mean by “hinder and slow development” and why that would be desirable? I can share a story that I *think* illustrates what you’re getting at:

    A software team has 12 developers and 2 testers. The developers work against a backlog of stories, assigning them to testers when the stories are “done.” The developers use no automated testing, and rarely do any sort of manual testing at all. Because of the ratio of developers to testers, and the fact that the developers have little quality control amongst them, the backlog of stories to be tested grows massively out of control. The developers finish more stories than the testers can address, with the testers sending back 80% of stories due to problems.

    There are two key problems in this (sadly very true) story. The first is that the developers were creating backlog for the testers at a pace far greater than the testers could ever work through it. The second is that nobody bothered to do the obvious math and realize that the situation would never, ever get better unless they changed their working style.

    The solution, in this case, is to break down the artificial wall of developers versus testers. The team is a team of software makers, with each individual person having his and her own unique abilities. Ideally the team’s needs align with everyone’s abilities. Sometimes we find ourselves in a mess like this, and the developers have to pitch in and help the testing team more. And then figure out how to avoid this in the future.

    I don’t think we ever want to hinder development. We might slow down the pace of coding, if the quality-absent breakneck pace of coding is what hinders development.

  9. A. T. September 7, 2013 at 5:02 pm #

    Copyright symbol and CC license on same picture? Not sure this is proper mix. And then CC has standard means to say “retain me mentioned” ;)

  10. testobsessed September 8, 2013 at 1:32 am #

    Copyright is about ownership. Creative Commons is about licensing. Or, as the Creative Commons website puts it, “Creative Commons licenses are not an alternative to copyright. They work alongside copyright and enable you to modify your copyright terms to best suit your needs.”

  11. Ron Wilson December 8, 2013 at 9:44 pm #

    Great article. It is a real issue in most organizations where everyone does not own the responsibility of ensuring the product has high quality. From the PM to Requirements, to Development and Testing, everyone’s job is to make sure the applications have the highest degree of quality. It is a shame that this point is so rampant in most companies today, Quality is not an exclusive job in QA.

Leave a Reply