When developers start talking about test-driven development and automated testing, most product managers get antsy. They want to invest lots of time, without actually creating any new features. Oodles of cash disappearing, with seemingly nothing to show for it. Sounds like a terrible business idea.
Or is it?
By getting rid of waste in your product development, there are three main business reasons why automated acceptance testing will make you more money. Not only does acceptance test driven development (ATDD) help reduce really important structural costs and risks, automated tests bestow an existing product with a lot of sales and marketing mojo. A decent automated test suite helps the developers execute really fast on new ideas. Magic.
Enforcing well thought out specifications
First of all, a test can be used to enforce a specification. These specifications exist to be sure that the functionality isn’t changing, once it’s understood. Conversely, missing tests highlight missing understanding at the initial stage.
Historically, specifications have been written by reams of business analysts (BAs), negotiated, and nailed down as the ideal solution to a particular problem worth solving.
The spec would be tossed over the wall. Developers then try to make sense of it all. They turn it into code. Then testers use those same specs to confirm (manually) that the specifications been hit. Sounds great in theory.
In practice, you play Chinese Whispers. What the client said isn’t quite what the BA’s heard, which isn’t quite what the developers heard, which then is not what the testers heard.
This is hard work, particularly if you aren’t really clear your big-picture business goals. If it’s not clear what the main goal was, then it’s very difficult to justify having the specification handed over in this way.
In contrast, if those initial specifications are turned into acceptance tests, you are forced to take apart this bigger vision into specific functions in the code. Once the developers write code which passes those tests, the tests are essentially enforcing the original scope as specified. By converting the specification into code, the original spec becomes immortal like the code itself. Acceptance tests are testing the code from the point of view of the client or end user, typically exercising code all the way through the system. Unlike unit tests, they aren’t testing individual methods or classes.
Whatever it is the customer wanted, automated acceptance tests confirm that that’s what they get. Each time the tests are run. There could be edge cases which were missed in the original specification, but if there wasn’t a test for it, then it wasn’t initially specified.
Alternatively, the acceptance tests can be modified or expanded, as you discover new requirements, but then that’s a very conscious decision. Chris Matts has previously pointed out that writing your specifications as automated acceptance tests increases the amount of communication on a team, which maximizes learning and the embedded real options in your development process. By minimizing the Chinese Whispers between BAs and the manual testers, you are much more likely to deliver what you expect, and everyone is clearer on what needs to be done.
When you could use acceptance test driven development, you get a high level of certainty in the moment. You’re delivering what you expect. If you manage to build out your acceptance test suite, you genuinely verify the relevant edge cases. It’s much more likely that you’ll capture side effects of changes you didn’t consider earlier.
In the end, you also deliver a much higher quality product.