Testing doesn’t add value?

This entry was posted by on Friday, 2 May, 2014 at

I was at the London Tester Gathering last night where the mystery speaker was Michael Bolton.During his talk he said something that caused me to pause:

Testing is a cost of doing business, testing does not add value.

(I’m paraphrasing as I can’t remember the exact quote)

When it was said I had an alarm bell go off in my head (the sort that you get when you are testing a bit of software and suddenly something doesn’t feel right, so you stop and look around and try and work out what triggered that feeling because you know it’s probably a bug).

So I thought about it on the train on the way home and came to the conclusion that he is wrong, testing does add value.

Testing adds value because testing is not just a reactive discipline, it’s also a proactive discipline!

As a tester I look at code written by developers and find problems with it on a daily basis. I then report these problems so that they can be fixed and when the code goes live I like to think that I help those developers look even more awesome than they already are (Outside of the development community I regularly hear people say “Who wrote this shit” when something doesn’t work. I never hear people say “Who tested this shit”).

I agree that I’m not adding value at this point, if anything I’m adding cost. A worthwhile cost, but a cost never the less.

However as a tester I don’t just look at code produced by developers, I also get involved in planning and pre-planning and in my mind this is one of the most important testing activities I can perform.

I have been testing code for over 10 years now and during that time I have seen code that is awesome, code that looks like it was written by 100 drunken monkeys and a multitude of things in the middle. I have been involved in testing from many levels, from code reviews to running UAT workshops, from usability to security and all sorts of other things as well, even performance and load. I’ve been lucky, I’ve got to see a lot and because of this I have a broad range of experience. When I’m in planning/pre-planning sessions I can use all of this experience to add value.

How do I do this? I can help the PO shape the product. I can highlight things that I have seen implemented before and have been a disaster, and get them removed very early in the process. I can suggest additional value added features that I’ve seen before that the PO didn’t think of/didn’t know were possible. I can highlight things that may end up being extremely costly to test so that we can think of different ways to look at the problem that are more cost effective to implement.

But what is the number one thing I can do? I can turn a “Can we do this” into a “Should we do this” before it gets near a developer.

If that’s not adding value, I don’t know what is.

9 Responses to “Testing doesn’t add value?”

  1. Hopefully Michael will see your post and explain himself more but if not you might want to read two of his posts that explain his thinking more fully:

    http://www.developsense.com/blog/2008/10/while-back-i-wrote-post-on-breaking/

    http://www.developsense.com/blog/2008/03/breaking-code/

    • Ardesco

      Again in both of those posts I would say that Michael is focusing only on one very specific part of testing, the part where we look at something that has been delivered. He also describes people adding value by finding new ways to use things that have already been built, or need to be documented so that people understand them better.

      I think that a core part of the testing effort is ensuring that the wrong thing isn’t built in the first place, before we have even got to the point where developers have started writing code. That is the point that I think we can add value.

  2. Jim Hazen

    You have inadvertantly fallen in to the trap that Michael set’s with this talk. And it is not a bad trap. He does this to fire people (testers) up to go and think about how they do add value to a project and how best they can explain/show it to other people (Developers and Management).

    He does this to get people to realize that testing is valuable. He does this to shake things up so that a complacent tester (someone just doing the job) gets motivated to learn and fight for their existence. He and James Bach are masters of motivation in the Testing world. Don’t be angry at him, be thankful that he has inspired you to be a better tester and contributor to the project.

    Now go forth and help to motivate other testers.

    • Ardesco

      Jim, I’m not angry, I just don’t agree with his point of view in this particular instance. I wouldn’t classify myself as a complacent tester and I don’t need “firing up” to be a better contributor of the various projects I work on.

  3. Hi, Mark…

    Thanks for responding to the talk. It’s a pity we didn’t get a chance to chat about this in the pub at the time, but at least we have a chance here.

    If I recall correctly, what I said was “Testing doesn’t add value; we help to defend the value that’s there.” (That’s my usual way of saying it.) Testing doesn’t add value in and of itself. What I mean by that is: we don’t put the quality in. We don’t add what some Agilists call running tested features to the product. That’s not saying that testing has no value, but in terms of adding value, our contribution is indirect.

    Imagine a program that doesn’t do very much—a program that adds two numbers. It took ten minutes to write (it has a GUI). No one really cares about such a program. We could test that program for a couple of minutes; we could test it for weeks. Whether we found catastrophic crashes or no bugs at all, the product has no value to anyone we can identify, and we would have added no value to it by testing it.

    Now imagine a colossal government project—say, a health insurance signup site. The product has immense value to many people, but it’s broken and it’s been rushed into production. Our testing revealed that before it was deployed. Not only that, but we were at all the design meetings too, and we identified lots of problems that threatened the value of the system. Yet no one did anything with that information. As valuable as the product might be eventually, we added no value to it.

    At some point, cooler heads prevail, and that project goes into a fixing phase. We dig up the bugs that we reported before, and we’re at the meetings where we identify a bunch of potential problems before they turn into real problems. Even so, none of the information that we provide adds value to the product unless someone else does something with that information.

    All this is not to say that testing doesn’t provide a valuable service, or that testing work has no value. On the contrary; it’s as you described:our work helps the people who put the value in, and it helps to defend the value that’s there. The information that we produce is potentially valuable, but not intrinsically so, and the value we provide is to the project, but not to the business as such. In a similar kind of way, code doesn’t add value to the product; code that delivers features does.

    I also mentioned that it was important for us to get out of the ROI trap. Testing is an expense; it’s a cost of doing business. In that, it’s like marketing. I found this an interesting read. http://www.copyblogger.com/social-media-marketing-roi/

    —Michael B.

    • Ardesco

      In my mind you are focussing on the reactive part of testing, the bit where we look at code that has been produced and try to find problems that can be fixed. I agree completely that we are not adding value at that particular point, and that it is a phase of testing that is a cost.

      However we can add value by getting involved in the process earlier and helping to drive the decisions made before the developers start creating the code. I still classify this as testing, I’m testing the ideas and finding problems with them before a line of code is written.

      Some of the value I add:

      1. I’m adding value by preventing bad ideas from going forward.
      2. I’m adding value by putting more good ideas into the mix and ensuring that the ideas that do go forward are well refined.
      3. I’m adding value by forcing people to listen to me, justify their position and explore all the consequences.

      I think the above is a little bit more than just “helping” people put the value in. There is a risk that people won’t listen to us in these early stages as you point out above, but that doesn’t mean we aren’t intrinsically adding value, that just means that people are burning some of that value that we add away on nothing. This happens to developers as well, they are sometimes told to write things that don’t produce value even when they have explained why it won’t add value. This doesn’t mean that developers don’t intrinsically add value.

      I’m aware that not all testers get involved in the proactive stage, I think that’s what we should focus on fixing. We should not be telling people that testing is a pure cost that doesn’t add value, because the truth is that if it doesn’t add value you’re either doing it wrong or you could be doing it so much better.

  4. steve

    Testing does not add value. We do not create tangible value that can add cost to the product. However testing does help to prevent loss and protect assets (value in the product). The value in testing is not an increase in value of the product but a defence against a devalued product. The are many ways you can evaluate the value of testing. But it has to be recognised that testing does not “add” value.

    • Ardesco

      Why not, what is preventing you from coming up with the killer idea that turns the product you are working on into an overnight success in your planning meetings?

      What is stopping you from getting that one bit of functionality that you know should be in the product into the backlog and developed.

      Testing can drive design, isn’t design where value is created?

Trackbacks/Pingbacks

  1. Testing Bits – 4/27/14 – 5/3/14 | Testing Curator Blog

Leave a Reply to Michael Bolton




four + three =