Implementing ATDD: A Practical Approach December 4, 2014 By: Chris Lawson
What exactly is ATDD? A lot of theory wri6en about ATDD, jus<fying its use with Agile principles Can be difficult to get from an implementa<on standpoint Really about people, communica<on, collabora<on, and delivering business value Easier to understand by doing it or by learning details of how someone else does it
How Wikipedia defines ATDD Acceptance Test- Driven Development (ATDD) is a development methodology based on communica<on between the business customers, the developers, and the testers. ATDD encompasses many of the same prac<ces as Specifica<on by Example, Behavior Driven Development (BDD), Example- Driven Development (EDD), and Story Test- Driven Development (SDD). All these processes aid developers and testers in understanding the customer s needs prior to implementa<on and allow customers to be able to converse in their own domain language.
Why ATDD? Be6er communica<on between the business and development teams Improve quality. Less defects in new features and less regression issues Increase developer produc<vity as a result of a more focused approach
4 Agile Pillars Manifesto Story AGILE Criteria Elements
Quick Agile Overview Individuals and interac<ons over processes and tools As a <user Working sozware over comprehensive documenta<on Customer collabora<on over contract nego<a<on Responding to change over following a plan Manifesto Story type> I want < a goal > So that <reason/ benefit> Backlog Condi<ons of sa<sfac<on (Success / acceptance criteria), ozen built around the so that value statement wri6en on the back of Criteria Elements Whole Team Sprint Scrum Burn down Chart the card Con<nuous Integra<on
Agile Overload?
Acceptance Criteria Overview Mission Purpose Prac<cal Applica<on Examples Value Benefit Realiza<on Condi<ons of sa<sfac<on (Success / acceptance criteria), ozen built around the so that value statement wri6en on the back of the card Criteria
The 3 C s of a User Story Card Conversa<on Confirma<on (Acceptance Criteria)
Acceptance Criteria Mission To form a complete requirements specifica<on when combined with the user story and the conversa<on Specify when the product does what it should do Promote conversa<onal & interac<onal context leading to shared understanding
Purpose of Acceptance Criteria Define the boundaries for a user story/feature Help the product owner answer what he/she needs in order for this feature to provide value (typically these are the minimum functional requirements) Help the team gain a shared understanding of the story/feature Help developers and testers to derive tests Help developers know when to stop adding more functionality to a story
Providing Focus for Development No just-in-case code Developers will code exactly what was specified not just the rules they see or interpret
Just-in-case code is the biggest source of waste in software development ~Mary and Tom Poppendieck Lean Software Development
Good Acceptance Criteria Focused on a single thing (rule, step..) Specification not a script Self-explanatory SMART Specific Measurable Achievable Relevant Time-bound
Building Shared Domain Understanding Specifications workshops Business people, developers, and QA in the same room Transfer the knowledge Ensure we all understand the same thing Discuss and suggest examples until the gaps and inconsistencies are flushed out Build quality in from the start by suggesting acceptance criteria that prevent problems
Key Prac<ces Discuss real-world examples to build a shared understanding of the domain Use those examples as acceptance criteria Focus the development of those tests Use the tests as a live specification to facilitate change Automate acceptance tests
Begin with end in mind Product Backlog Concrete Examples with ExpectaBons Shared Understanding
Discuss + Dis<ll = Develop Product Backlog As an Administrator, I want users crea<ng accounts to be required to choose secure passwords so that their accounts cannot be hacked by someone using a password guessing program.
Discuss Who s in the room? ü BA Product Backlog ü QA ü Dev and anyone else who will touch the story. And if a user provides an insecure password, display an error message. Dis<ll What does secure mean to you? At least 8 characters with at least one le6er, one symbol, and one number
Concrete Examples Password p@ssw0rd p@s7 Product Backlog passw0rd $#%@%123 p@ssword Can be expressed in tables or in other formats depending on context and/ or test framework Valid? Yes No No No No Given a user is crea<ng an account When they specify an insecure password Then they see a message, Passwords must be at least 8 characters long with at least one le6er, one number, and one symbol. Can be expressed in Given When Then format
Conclusion Don t accept requirements that are solutions to unknown problems Use concrete examples for clarification Examples can become Tests Requirements