Can you remove a Tester and get better quality?


whaatHave you ever been in a conversation like this?

Manager: “The last release is very buggy, why didn’t we spot the issues before?”

Tester: “We did all we could with the resources and the time given to us”

Manager: “What can we do so that it doesn’t happen in the future?”

Tester: “We need more testers”

Manager: “OK let’s get Michael form the 4th floor help us from Monday”

I have been hearing this conversation for more than 20 years. I have even been the tester and the manager in these conversations.

But what happened the following release? Did Michael from the 4th floor manage to help improve the situation? Not at all, and the same would have happened if also Frank and Jane from the 5th floor helped, and so on.

One day, over 10 years ago (before I even knew what agile or lean was), I thought that insisting with the same approach would have been insane, so I started to look at what different possibilities we had and I tried a crazy move.

When challenged with the same “too many bugs in this release what do we do?” I said:

Why don’t we remove a tester instead of adding one?

People laughed at me, but I had enough influence to be able to try this.

Against all odds, things got a lot better. The one tester remaining in the team was swamped with work and developers felt they needed to help to avoid getting everything on hold.

Guess what, they started to help.

Some of the activities that were “tester zone only” before, became accessible to developers. A different perspective helped identify some inefficiencies in such activities and developers adapted some of their own process to help.

All of a sudden giving developers visibility over the test activities had triggered a lot of curiosity and interesting hypothesis. Some developers, challenged with repetitive tasks, created small tools to make them faster, some other saw how sharing the test plans with the developers could help prevent issues that otherwise would have been caught much later, and so on.

This was many years ago, it wasn’t perfect, but taught me a great lesson.

If people don’t have skin in the game they won’t improve the system. If they are affected by a problem they will resolve it instead.

If you ask your developers to write code, that’s what they will do, defects and all.

If you empower them with delivering customer value they will look beyond the code and make sure that what they deliver is also useful for their customers.

This is one of the foundations in today’s agile software development teams where role silos are gone, collaboration is fundamental and team members care about customer value rather than lines of code or number of tests executed.

We’ve come a long way

 

Advertisements

12 thoughts on “Can you remove a Tester and get better quality?

  1. Hi Gus! Another interesting post. I agree to a degree…
    If you teach people everything about what testing is and how to do /good/ test effectively, then they will be good testers regardless of what roles they are called.

    There are 2 problems though:
    1) many companies don’t teach the developers about good testing. Instead they think testing is just checking requirements and they pass it on to the developers just to do this task. Quality still suffers (usually gets worse if its good testers that the company are “reducing” – aka making redundant)…

    And
    2) there are a lot of developers who don’t actually want to test, even if they find out about good testing and it’s value. They studied to be developers and chances are all their previous experiences didn’t require them to do all this extra investigative testing activities, so they’ll resent that and push back.

    I like hearing your experiences,as it sounds like you are in a really good place with really good people, but I’m increasingly finding that that is a rare thing…
    What can you advise to people who aren’t at that good place and suffer from points 1 or 2 above? 😉

  2. Thanks for your feedback Dan.
    Let me first clarify that my post doesn’t want to say that removing testers is always good, my post is mainly about the fact that poor quality cannot be resolved adding new testers, but I appreciate your sentiment.

    On your 2 points:

    1) If you are a good tester then you can teach your developers about what good testing is about. I have done that several times in many contexts. I certainly wouldn’t wait for my company to get to my same conclusion and budget for training developers.

    2) On the developers that don’t want to test, I am afraid they are their own worst enemy and are destined to extinction or relegated to minor roles in the future.
    A few years back I wrote this while I was working on training developers https://mysoftwarequality.wordpress.com/2013/08/10/should-developers-test/
    I shared it with the developers I was working with first, before I published it. Why did I publish it? Because it generated a lot of interesting conversations with my developers.

    I also read a very good piece on Quora on a similar topic
    https://www.quora.com/I-do-not-use-any-testing-tool-am-I-a-bad-programmer/answer/Noah-Sussman-1?srid=zUbP

  3. Collaboration isn’t unique to agile. It’s a corner stone for most all lifecycles. Developers helping during a testing phase? That’s been going on for years. Who’s writing code while your developers are testing? I’ve never worked in a place where develop just goes on hold. Usually we have multiple projects lined up and we’re developing the next while the first is undergoing UAT.

    • Thanks for your feedback CP.
      Yes collaboration is not unique to agile, but nothing in my article says the contrary.
      I know that collaboration between testers and developers has been going on for years, I don’t claim I was the first, did you actually read my post?
      When people test something, development does not go on hold, testing is part of development, isn’t it?

  4. Very nicely framed. Collaboration is important. Also, we can have lessons learned. Removing or adding people may not work.

    The lessons learned in such situation would be to not get the same problems again. We should take the reverse also into consideration i.e. involve testers in the development phase as well as it will help the same way developers are being involved in testing phase if we have few people. But ultimately having a single person may not help.

    Yes but i agree to sarcasm why don’t we remove a person instead of adding.

    Thanks for the article

  5. Good post Augusto!

    Out of interest, why didn’t you remove the developer (the weakest link) instead of tester in your case study before? 😀

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s