Automated Testing – Explaining Its Business Value

bddseleniumtddunit testing

To start I don't think this is a repeat of other questions on unit testing. What I'm looking for help with is articulating its value to a team of programmers, analysts, managers and testers. By automated tests, I don't think I need to make a distinction between unit tests (e.g. JUnit), BDD (e.g. JBehave, Fitness) and UI (Selenium , Watir) because I think they all provide similar value (but feel free to write an answer that disagrees :))

The following is a list I've identified, I'm looking for answers that help expand or refine:

  1. Time/Cost Savings: writing automated tests can take more time than written test cases. However, considering tests are run multiple times, the marginal work (i.e. cost/time) to execute automated tests is several orders of magnitude less. That the automated tests are cheap to run facilitates changing the system over time.
  2. Documentation: there is no truer way to know how a system works than its tests. Any other documentation is usually out of date the moment its written, but tests (at least those that pass) reveal how things actually work. This is true for both end-user AND API documentation.
  3. Code Quality: test writing forces you to:
    • consider clients because tests are a client
    • breaks dependencies where making code testable often means figuring out how to make that code not require some other large system be available

Best Answer

A few of my thoughts:

  1. Be honest that writing automated tests will take more time. If you're doing unit level TDD (which I would recommend as a starting point if you're going to invest in automated testing), you can expect about 30% extra time needed to code a feature. The key here is explaining that this extra 30% (which is probably higher than 30% in the beginning as your team learns how to write good tests) is an investment built to save costs over time. As least with unit level TDD, the design of your system is loosely coupled and highly cohesive, which makes your system adaptable to change over time. New requirements and unexpected bugs always require changes to your system, so keeping your system in a state where change is easy (from the nice design that comes from TDD) and safe (the set of automated tests that continually verify your system) means that it will cost less money to make those changes.
  2. There's lots of debate about the value of Acceptance level and UI level tests given the amount of time it takes to write these tests, how long it takes to run them, and how much maintenance they require. I'd recommend reading this article by James Shore about this.
  3. In the world of automated testing, there are good ways and bad ways to do it. If you are pitching automated testing to your management, I would pitch alongside it how you're planning on getting your team trained in writing good tests. The Art of Unit Testing by Roy Osherove, Working Effectively With Legacy Code by Michael Feathers, and The Art of Agile Development by James Shore are all great books that deal with these topics directly or indirectly. You should also look into some sort of coach or formal training as well. It's a big change.
  4. In terms of Business Value, #2 and #3 of your points above actually serve your first point, so I'd hammer home on point #1 and talk about how #2 and #3 serve that greater point. Documentation makes your system more understandable, which makes your team work faster. Code Quality makes your system adaptable to change, which makes your team work faster. For business people, it's all about maximizing the flow of value from the time an idea is pitched to the time the idea is delivered as working software.
Related Topic