Acceptance Test-Driven Development is one of the first things all companies should adopt when they start Agile. Whether it be Scrum or Kanban you start with. Besides being a good thing to do in its own right, ATDD tends to help both Scrum and Kanban avoid the pitfalls most initial users of the framework/method fall into.
In the case of Scrum, it is the common ignoring of technical practices and that testers tend to fall behind developers. In Kanban’s case, it’s the lack of attempting to form teams of some form. The main reason we think this happens is that people think ATDD is an all or nothing thing. It isn’t. There are four discrete levels of ATDD adoption. The first takes virtually no extra work, the second one takes very little. Both return great value. The third and fourth can return even greater value but do, admittedly take more of an investment. The important thing to remember is that you can start at any level. Each level requires more investment but each level provides a greater return. Identifying the levels this way is in no way intended to caution you into implementing in steps. Rather it is to provide a smooth transition path if there is reluctance to start at all.
Level 1: Use test specifications as an analysis tool and to validate the requirements
In this case developers use acceptance tests as a way to discover what they don’t know and to validate their understanding with the BA/PO/Customer. Before writing code they need to make sure all acceptance criteria have been defined. This is not ideal by any means. But I like this first level because this is not additional work so is easier to enroll developers into doing. All they are really doing here is developing their tests to writing the code. It is a rearrangement of the people’s workflow and therefore and doesn’t actually add additional work.
Level 2: Get Business analysts, Product Owners, customers, developers, and testers talking at the same time
One of the biggest advantages of ATDD is that it changes the nature of the conversation between whoever is representing the customer, the developers and the testers. It is a great way to uncover assumptions that will cause waste. It has been said many times it’s become somewhat of a cliche, but there is what you know, what you don’t know and what you don’t know you don’t know. Many times we make assumptions without realizing they are assumptions (something we don’t know and we don’t know we don’t know it). In these cases, we don’t know the right question to ask to discover the mistaken understanding. When the different roles talk to each other and create acceptance tests, these tend to be discovered.
Level 3: Put results in a test tool/harness
Writing the acceptance tests, once they have been defined is often not very difficult. Especially if one uses a test harness. While you’ve got them might as well capture them.
Level 4: Automate the tests
Some test harnesses will make this automatic. However, even if you have to do some work here, it will pay itself back quickly by reducing regression testing. Think of all the places where tests currently don’t exist and manual regression testing slows you down. Don’t keep adding to that pile.
Note the increasing return for step-wise investments.
It should be noted that Level 1 ATDD takes almost no effort. Each of the other levels take a bit more but each returns fantastic results. And typically each one requires less than one would think once the fact that you are going from level n to level n+1. That is, while at the beginning it may look daunting to create automated acceptance tests, once one considers the different levels of ATDD one realizes going from one level to the next requires a minimal investment.
While it may be difficult to start at level 4, virtually every development group should start at at least Level 2. It’s really not that hard. Happy to have a 1-on-1 for 30 minutes to let you know how.