Note: Andrew presented this workshop a second time last night. As with any presentation or workshop, it has evolved slightly over time. I’m incorporating my additional notes into this post. -Sjv 23-May-2013
Over the past week or so, Andrew Fuqua (@andrewmfuqua) has given workshops on Acceptance Test Driven Development for both the Atlanta Quality Assurance Association — an organization that, I’m embarrassed to say, I didn’t know existed until I heard about it via Twitter (of course) — and the Atlanta Scrum Users Group.
Andrew comes to the topic from his role as an Agile Coach and emphasized communication, communication, communication. ATDD, as we discussed this evening, is all about getting “the three amigos” — Product Owner (a role he asked me to fill for the AQAA workshop), Developers and Testers — together to communicate. The intent is to discuss the details of requirements (often written as User Stories these days) and distill them down into a minimum set of examples in order to provide clarity. Another, perhaps better, term would be Specification By Example.
Here are a few of my scribbled notes from the two evenings:
- Why do software have bugs? Many reasons, but most often because of miscommunication between humans – especially around requirements.
- We humans have a tendency to assume ill intent (why is this?) where often misunderstanding is more likely the cause.
- A feature or product request often starts with some sort of concrete example, which gets thrown away as more general requirements documents are written. Let’s get back to examples as part of the requirements
- Business rules are more likely to be stable than user interfaces. Therefore examples should be in business language.
- Cognitive dissonance (discussion between people with different viewpoints, different skill sets, different ways of thinking) can facilitate exploration and improve understanding. Involve product owner, developer, tester, business analyst, customer if possible.
- Don’t get lost in the details.
- We all have too many meetings. Don’t create another one for this discussion/distillation activity. Hold a specification workshop instead.
- Discuss, Distill, Develop, Demo (explore). Lather, rinse, repeat.
- Distill the list of examples down to the bare minimum, a minimal set of both “passing” and “failing” examples. One example per business rule.
- There is value in the discussion and distillation even if the examples are never codified into automated testing. Communication is the goal.
- ATDD != TDD. TDD guides design of code. ATDD guides clarification of requirements.
- ATDD is done before — and throughout — coding/testing.
- Best captured in some sort of living document (no specific tool recommended, but a wiki was mentioned)
- The results should be owned by the product owner, not developers or testers.
- It’s not about testing, it’s about communication.
- “Don’t invest in something that nobody gets value from.” – Claire
- “Design a level of testing that is commensurate with risk tolerance. Don’t dabble in automation. Do it well to keep it – or toss it.” – Sellers
- Understand Brian Marick‘s Agile Testing Quadrant model. (see this and this) – Alex
And some of the resources Andrew mentioned:
- Specification by Example: How Successful Teams Deliver the Right Software, and its predecessor Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing.
- ATDD by Example: A Practical Guide to Acceptance Test-Driven Development
- The ATDD Arch and Driving Development with Tests: ATDD and TDD by Elisabeth Hendrickson (@testobsessed).
The discussions did also touch on the topic of test automation. Again, no specific tools or technologies were covered or recommended, but a couple of good points were raised. I was especially pleased to see many heads nodding in agreement when Andrew said that “test automation is software development, and should be treated as such.”
This was a good workshop, and I’d like to thank Andrew for his time (and for letting me help where I could be of assistance).