Doneness Focused Processes
In a previous article, I described the three levels of doneness tests – business, customer/user, and technical. Corresponding to these levels of tests are three processes that are all focused on the doneness tests. These are Business Test-Driven Development (BTDD), Acceptance Test-Driven Development (ATDD), and Test-Driven Development (TDD). We’ll see how they differ and how they all relate to Plan/Do/Check(Study)/Act (PDCA).
Here’s a picture of the test levels from the previous article:
And here’s a diagram of the three process levels:
Business Test-Driven Development / Objective-Based Development
Business Test-Driven Development (BTDD) matches the “TDD” in the other two processes. However, some like to refer to this as Objective-Based Development (OBD). BTDD/OBD applies the PDCA cycle to software development. In the Plan phase, the business doneness tests (also called objectives) are created. These involve the expected business value to be produced by a changing an application from the “as-is” state to the “to-be” state. Business value includes increased revenue, decreased expenses, and improved customer satisfaction.
During the Do part, a feature or set of features is developed. After the new application is deployed, the business test is checked to see if the business value has been created (the Check or Study phase). During the Act portion, the results of the business test are analyzed. If the test passes, then a new cycle for a different business value or feature may be started. If the test fails, then a decision must be made whether to accept the failure and move to something else or to determine what other changes should be tried to make the test pass. It’s a balance between trying to achieve the business value and the effort required to create it.
Everyone involved in development should know the business tests and should be informed of their success or failure. Don Reinersten (a noted author of books on Lean) has said in practice that less than 5% of development teams ever learn of the business test result. From what I have learned in my own informal polls, the percentage may be well less than that.
The cycle time for BTDD/OBD is longer than a release cycle. An application must typically be deployed for a while before it can be determined that the business test passes. The parties that are primarily involved are the business customers – internal departments or marketing and sales.
Acceptance Test-Driven Development
The Do stage of BTDD involves Acceptance Test-Driven Development (ATDD). Some refer to this as Behavior-Driven Development (BDD) or Specification by Example (SBE). In the Plan stage of ATDD, customer/user doneness tests are created for feature scenarios. In the Do part, these acceptance tests become the context for the technical tests of TDD. When the implementation is complete, the Check stage ensures that the acceptance tests pass and the user can execute the functionality that the tests represent. In the Act portion, any feedback from the user can generate additional acceptance tests which become one more cycle of ATDD. The relative completeness of the acceptance tests developed in the Plan phase has a bearing on how many cycles are necessary.
The cycle time for ATDD ranges the amount of time to complete a story (if they are written when the story is pulled off the iteration backlog) up to an iteration (if some acceptance tests are written prior to a story being accepted into an iteration backlog). The main participants are the product owner, business analysts, developers, testers, and other stakeholders with a stake in the story.
Test-Driven Development (TTDD) is the third level. (To keep it consistent with the first two levels, it should be called Technical Test-Driven Development (TTDD), but TDD is a name in general use). The context for the technical doneness tests are the customer/user acceptance tests. In a tight cycle, the developer creates a technical test (Plan), implements the code to pass that test (Do), checks that the test passes along with any previous tests (Check), and then decides what tests to write next (Act). Designing the overall approach to the implementation can be part of the Plan or the Act part. In TDD, the tests may be revised as the implementation progresses or the design changes.
The cycle time for TDD is in the range of minute to a few minutes. The participants are either the developer or the developer/partner pair.
To emphasize that there is feedback from the Act part of the cycle, here’s the diagram with the feedback loops.
We’ve shown how three levels of processes – BTDD/OBD, ATDD/BDD, and TTDD/TDD – are interrelated and how they each reflect the PDCA cycle.