I introduced ATDD (Acceptance Test Driven Development) to a team I was recently working with. It’s been used by agile teams for years (sometimes referred to as BDD — Behaviour Driven Development), but I do not see it used much in the wild nowadays. This is a massive shame because it is a simple yet powerful technique for building quality into a product.
The automated tests will initially fail because no code has been written to make them pass! Once the code is written and the tests pass, we now all have confidence as a team that the product is behaving in the way it is supposed to for the customer. If we miss something, we can add new scenarios or update the existing ones, and the corresponding code can then be updated/added.
An added bonus is that each time we add a new test or update an existing one, we are also documenting the behaviour of the product’s features. This means that we all know at any given time exactly what the customer can accomplish with the product.
Not to mention that, because these tests must all pass before we release the software into production, the suite of tests represents the functionality that we KNOW WORKS! We can be confident that when we add new capability to the product, so long as all the acceptance tests pass, we have not created any regression bugs.
If you have any questions about any of the concepts in this article, or need a hand with your service design, lean/agile product development or agile transformation endeavours, please reach out directly to me or my company Hypothesis.