Kevin Klinemeier, Davisbase
“The customer does not like what we made this week” is a bigger problem than “The customer does not like what we made this morning”. But the natural inclination of programmers is to program until they are out of one of the following: time, features, or food & water. Much of the Acceptance Test Driven Development (ATDD) literature talks about tools for automation, for example Cucumber, Robot Framework, or RSpec. These tools can be a means to an end, but are not required and may be more of a hindrance than help especially when a team is just starting ATDD.
Instead of tools, focus on planning and task creation. Turn the planning of work items (stories) upside down by asking “where is the risk?” rather than “what needs to be built?” A set of standard starting questions that borrow from the traditional QA skillset of Risk Analysis gets the conversation started. These answers lead the planning of the work, starting from the areas with the most risk. Rather than build the feature in its entirety, programmers build just enough to test, based on this plan. No tools are needed, but sticky notes help.
In our team, identifying these testable subsets of work in advance allowed the testers to receive work every day, shortening the bug’s life cycle and reducing the cost of their fix. It also allowed the team as a whole to demonstrate to the business approximately every other day, with similar benefits. When the team then adopted automated testing, this experience helped them identify where it would be most beneficial. This experience also translated to better estimates on the part of the testing work, as the habit of discussing risk and mitigation was carried to those activities.
This low-tech ATDD approach is especially applicable to two kinds of transitions a team may be in. The first are those who are taking the first steps to moving away from a big-handoff approach and toward a continuous testing approach. The second are teams that are attempting to work more closely with their business stakeholders. Generally, this approach is useable for both legacy projects as well as new-development. It is appropriate in both the Scrum and Lean paradigms, making no assumptions about when the planning takes place.
Target audience: Introductory
Kevin Klinemeier, 2014 Technical Paper, Paper
