A-TDD as an Efficient Design Tool & Productivity Booster


Been thinking a lot about A-TDD these days with ICST and the TDD workshop coming up next week. A-TDD can help you do more than validate your product against Acceptance criteria. A-TDD asks you to think about the definition of Acceptance in Customer terms, and prepares you to be Ready-Ready. This represents the black-box product tests that customers will run. A-TDD covers not only functional tests, but also covers tests related to performance, stability, reliability, security, and other “-ility” tests. A-TDD can help you do the following as well:

  • Break down large requirements into appropriately sized testable Stories – by applying A-TDD, over-sized stories become more visible and Acceptance Criteria can spawn new sub-Stories.
  • Crystallize architectural decisions – Acceptance definition forces thinking at the boundaries where architecture meets implementation, exposing architectural and design issues that may not have been considered before.
  • Re-factor your backlog – Defining Acceptance tests gives you a window into value and new sub-Stories which can help to re-prioritize and add more granularity to a product backlog.
  • Increase the behavioural predictability of your software – because tests define the acceptability of a product, developers have a clear goal that drives “coding to pass tests”, driving more predictable designs aligned to the desired customer visible behaviour.
  • Write less code – writing code to “pass tests” which are clearly defined can help developers avoid code for “What-ifs” which are not part of the Acceptance Test definition.
  • Close the Requirements Traceability Loop at the front end – reducing erroneous test cases and waste associated with investigating “issues” which are invalid from a customer perspective.

Even without Acceptance Test Automation, the act of good Acceptance Test Definition using A-TDD drives more coherent and predictable designs.

In the paper “Shock Therapy – A Bootstrap for Hyper-Productive Scrum”, Sutherland, Downey and Gravnik conclude:

“The difference between this and “ordinary” Scrum is that…Acceptance Test Driven Development (ATDD) was used. Testers/business analysts would deliver test cases that were implemented directly by the programmers. Only after this was the actual code completed. Testing was accomplished as soon as possible after code completion and before the end of the sprint.

“…ATDD will consistently double velocity and reduce defects by 40%…”

Automation allows stakeholders to watch value being delivered as Acceptance Tests pass. Automation provides quick feedback to developers, letting them know if they are meeting the Customers’ Criteria for Acceptance.

Collaborate with your PO, lead developer, lead tester, and architect in Acceptance Test Driven Development. The conversation and learning that takes place will drive innovative thinking about how we meet our Customers’ needs.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s