Implementing ATDD: A Practical Approach

Size: px

Start display at page:

Download "Implementing ATDD: A Practical Approach"

Madison Sutton
5 years ago
Views:

1 Implementing ATDD: A Practical Approach December 4, 2014 By: Chris Lawson

3 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

4 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.

5 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

6 4 Agile Pillars Manifesto Story AGILE Criteria Elements

7 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

8 Agile Overload?

9 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

10 The 3 C s of a User Story Card Conversa<on Confirma<on (Acceptance Criteria)

what it should do Promote conversa<onal &

11 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

12 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

13 Providing Focus for Development No just-in-case code Developers will code exactly what was specified not just the rules they see or interpret

14 Just-in-case code is the biggest source of waste in software development ~Mary and Tom Poppendieck Lean Software Development

15 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

16 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

criteria Focus the development of those tests Use the tests as

17 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

18 Begin with end in mind Product Backlog Concrete Examples with ExpectaBons Shared Understanding

19 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.

20 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

21 Concrete Examples Password Product Backlog passw0rd 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

22 Conclusion Don t accept requirements that are solutions to unknown problems Use concrete examples for clarification Examples can become Tests Requirements

Founda'ons of So,ware Engineering. Process: Agile Prac.ces Claire Le Goues

Founda'ons of So,ware Engineering Process: Agile Prac.ces Claire Le Goues 1 Learning goals Define agile as both a set of itera.ve process prac.ces and a business approach for aligning customer needs with