The ATDD Arch

The ATDD Arch

It seems like everyone is suddenly talking about Acceptance Test Driven Development (ATDD) these days.

I have worked with several organizations as they’ve adopted the practice. And I’ve watched each struggle with some dimension or another of it. The concept behind the practice is so simple: begin with the end in mind. But in order to gain traction and provide value, ATDD requires massive, fundamental changes from the traditional organization mindset where testers test, developers develop, product managers or business analysts write requirements documents, and each role works in its own little silo.

As one person said to me, “ATDD is moving some people’s cheese really hard.”

Sometimes when organizations contact me about helping them with ATDD, they start by talking about tools. They tell me they’ve selected a tool to do ATDD, or that they want me to help them with tool selection. They’re suffering from delayed feedback and slow manual regression cycles and they want to do ATDD because they see it as a path to automated acceptance tests. They think ATDD stands for “Automated Test During Development.”

What they don’t see is that ATDD is a holistic practice that requires the collaboration of the whole team. We collaborate on the front end by working together to define examples with expectations for stories, then articulate those examples in the form of tests. On the back end, when the team implements the story, testers and developers collaborate on connecting the tests to the emerging software so they become automated.

Handoffs don’t work with ATDD. The product owners don’t establish examples with expectations unilaterally; they work with developers and testers. The testers don’t create the tests unilaterally; they work with the product owner and developers. And when the team is ready to hook those tests up to the emerging software, there is no automation specialist just waiting to churn out reams of scripts. Instead, testers and developers collaborate to create the test automation code that mades the acceptance tests executable.

Starting an adoption of ATDD with the tools is like building an arch from the top. It doesn’t work.

The tools that support ATDD—Fitnesse, Cucumber, Robot Framework, and the like—tie everything together. But before the organization is ready for the tools, they need the foundation. They need to be practicing collaborative requirements elicitation and test definition. And they need at a bare minimum to be doing automated unit testing and have a continuous automated build system that executes those tests.

It’s best if the engineering practices include full-on Continuous Integration, Collective Code Ownership, Pairing, and TDD. These practices support the kind of technical work involved with automating the acceptance tests. Further, they show that the team is already heavily test-infected and are likely to value the feedback that automated acceptance tests can provide.

14 thoughts on “The ATDD Arch

  1. Hi,

    Good points. We should definitely work on the human factors before we get into the tools part.

    If the distinction between the roles of testers and developers will get blurred out in ATDD, are the testers expected to understand code? I think it requires training to help testers get comfortable reading and understanding the code correctedly for this transition to succeed.

    “The intersection of Technology and Leadership”

  2. Hi Aruna,

    You said, “I think it requires training to help testers get comfortable reading and understanding the code correctedly for this transition to succeed.”

    This is why collaboration on the code is so important. In many organizations, the developers write the test code (fixtures) as part of the development process. They often pair with testers in doing so.

    But testers who have no programming background are not suddenly expected to be able to write test code in Java.

    The few organizations I’ve seen attempt such a transition with non-programming testers requested to write the test code discovered quickly that it didn’t work without a whole lot of training and support (as you said).


  3. Hi Elisabeth,

    I like this a lot. It’s simple and accurate, but (there had to be a ‘but’, didn’t there?-)…
    …isn’t Test Automation ‘just’ another Technical Practice? In which case might ATDD be the top of the arch, rather than the space inside the arch?

    And I wonder if there isn’t an ATDD viaduct waiting to be articulated, with multiple columns supporting ATDD. That would allow you to:
    1) enumerate specific practices in the columns
    2) liken the flow of delivering ‘business value’ to the flow of water in a viaduct

    This would open the door for an animation showing the journey of a story (represented by a barge) from elicitation to implementation.

    Maybe there’s even scope to get Nick Park to do a movie with Wallace & Gromit …


  4. Hi Seb,

    I think there are three separate things, but I haven’t named them right.

    Honestly, I struggled with the words. I considered “Engineering Practices” instead of “Technical Practices,” but that leaves us with the same problem plus the additional problem of perpetuating the engineering myth for software development.

    The distinction I see between the top (automation practices) and right side (technical practices) is that the technical practices are how we build the software itself. The thing across the top is the code that bridges between the software under test and the business-facing expectations.

    Recommendations for better names are most welcome.

    As for the viaduct – yes, I agree. There are a host of supporting practices. Though I tend to visualize them as bricks in the columns of the arch.

    And yet, if changing the visualization means we could get Nick Park to do a Wallace & Gromit short to explain ATDD? Um, drool. (Picturing the car motoring past columns now.)



  5. Pingback: QuickLinks for February 2011 | (Agile) Testing

  6. Pingback: Acceptance Test Driven Development brings teams together « Stephan Schwab

  7. hello madam….

    i am a fresher… ia m doing my acadamic project on NEXT GENERATION TESTING TOOLS” . I am not getting the approach… is this ATDD will be a next generation testing methodology? or else please suggest me some next generation testing tools or methodologies…

  8. Hi Ram,

    ATDD is a practice that fits well with Agile methodologies. The tools that support ATDD well (like Cucumber, Robot Framework, Fitnesse, etc.) could be called “next generation tools.” However, before taking my word for it, I recommend asking your professor for an example of what he or she thinks is “next generation.” Good luck on your project.


  9. We have adopted ATDD process.. Using cuceumber tool. I see sometime testers are not thinking the way they should be thinking.. The test is always happy path and very narrow focus in itegration. Also how much automation makes sense for old application and appication is going to be replaced by another year.

  10. Can ATDD work when you partner with an off-shore team? What are some of the challenges that we could mitigate up front? Is this even possible?

  11. Do you have a picture of how you would set up your org. utilizing the ATDD approach?

  12. Pingback: Steven’s Notebook » Blog Archive » ATDD at AQAA

  13. Hi,

    I read few posts on ATDD and interested to know, how do you perform estimation for testing the code using the automated approach.
    Secondly, when a project manager who follows the traditional approach, wants to move to ATDD approach, what strategy (implementation) should he/she adopt ?

    Thanks in advance

Comments are closed.