Acceptance- Test Driven Developmen · ATDD Process 1) Get the top priority requirement from (the...

Acceptance-Test Driven Development Julian Goddard

14/04/2015

15/04/15 (c) 2014 Plaxion Limited. All rights reserved. 1

Interactive seminar

Ask questions as they arise

Discuss points as they arise

Presentation will be available on the BCS website

Some slides will be skipped during presentation

15/04/15(c) 2014 Plaxion Limited. All rights reserved.

Contents

Introduction

Business case for ATDD

Agile review

Description of ATDD and TDD

Comparison between ATDD and TDD

How to use ATDD on your projects

Conclusion


Introduction - Julian Goddard

Commercial software contractor – 15 years

Medical Safety Critical software – 10 years

Planes and trains, SC software contractor – 10 years

Facilitated various Agile and Software Development Forums over the last 5 years

Interested in quickly developing robust, safe software

[email protected]/04/15(c) 2014 Plaxion Limited. All rights reserved.

Introduction - The audience


Business case for ATDD

Business case for Agile

Because Agile is a philosophy it is possible to just implement some of the practices (such as ATDD, TDD) that follow the philosophy

Each Agile practice provides some of the potential benefit, ATDD being one of the major contributors

ATDD and TDD will be described later15/04/15(c) 2014 Plaxion Limited. All rights reserved.


Project benefits - RAVER - Risk MitigationA - AdaptabilityV - Visible Progress

E - Early Value

Personnel benefits - WoCoMoWo - Work-rateCo - Communication

Mo - Motivation15/04/15(c) 2014 Plaxion Limited. All rights reserved.

Project benefits - Risk Mitigation


Project benefits - Adaptability


Project benefits - Visible Progress


Project benefits - Early Value


Personnel benefits - Work-rate


Personnel benefits - Communication


Personnel benefits - Motivation




Agile TraditionalProductivity(Communication & Motivation)

Higher Lower

Adaptability(tenet)

Higher Lower

Robustness(Risk Mitigation & continuous testing)

Higher Lower

Costs(all of above)

Lower Higher

Agile review


Agile review - Summary


Agile review - Manifesto Values

Individuals and interactions

over processes and tools

Working software

over comprehensive documentation

Customer collaboration

over contract negotiation

Responding to change

over following a plan


Agile review - Manifesto Principles (summary)

Cooperation between project sponsor and

development team

A continuous stream of requirements in

priority order

Iterative, incremental deliveries of

working software

Continuous adaption of development

processes 15/04/15(c) 2014 Plaxion Limited. All rights reserved.

ATDD

Automated build

Backlog

Burndown/burnup chart

Continuous, iterative, incremental development

Daily stand-up meeting

Definition of “Done”

Kanban


Agile review – PracticesPlanning poker(Point estimation)

Refactoring

SCRUM

Simplicity

Sprint

TDD

User stories

Velocity

Agile versus Traditional

(c) 2014 Plaxion Limited. All rights reserved. 15/04/15

Agile Traditional

Empirical Pre-definedProcess

Just-in-time Fixed at StartRequirements

Evolves Big design up front

Solution

Integrated & Verbal

Remote & WrittenCollaboration

Self organising & Empowered

Managed & Directed

DevelopingTeam

Agile review – project from A to B


A B


A BA


(c) 2014 Plaxion Limited. All rights reserved.

A BA B



A BA B

B



A BA B

BB

A project is developing from A to B in an environment

A is usually fully understood but sometimes won’t be

B may not be fully understood until the development has started

The planned route may change

The environment may change

Examples: a leopard chasing a gazelle / driving to work



Agile review - Philosophy

Embracing Change at any time during the project

Being flexible

Being proactive and reactive

Frequent preview and review

Continually reassess and adapt

In one word: Agile


Agile review - Implementation

IterativeSCRUM / Sprints / phases

Incremental progressionComplete at end of every cycle

Practices such as ATDD and TDD


Description of ATDD

An Agile practiceATDD 2010+, derived from TDDTDD 2000+ (Kent Beck, Extreme Programming) derived from Unit testsUnit tests 1995+

Process

Exceptions

Benefits

Costs


Backlog

ATDD Process


SimplestHigh PriorityRequiremen

t

Use (or write simplest)

Acceptance Criteria

Use (or write simplest)

Acceptance Criteria

Write SimplestAcceptance Test

FailingATSet

FailingATSet

PassingATSet

PassingATSet

When AT passes

ATDD Process1) Get the top priority requirement from (the top priority

feature in) the backlog

2) Use (or write simplest) Acceptance Criteria to write the new simplest Acceptance Test (AT)

3) Add the new AT to the Failing AT set

4) Initiate development of the simplest solution for the requirement

5) Check the Failing and Passing AT sets frequently

6) Move passing ATs from the Failing AT set to the Passing AT set

7) When Failing AT set is empty, phase is complete15/04/15(c) 2014 Plaxion Limited. All rights reserved.

ATDD Exceptions

New AT passes immediatelyNew AT is wrong solution to requirement already implemented: duplicate requirement

Never able to get New AT to passNew AT is wrongNot possible to implement solution: requirement is unachievable

New AT passes, but other AT failsNew AT is wrongRequirement is wrong: reverse it out and reconsiderRequirement is mutually exclusive with another: ditto


ATDD Benefits


(Simplest)Requirement

(Simplest)Acceptance

Criteria

(Simplest)Acceptance

Criteria

SimplestAcceptance

Test

SimplestAcceptance

TestFocus

onSolutio

n

Focus on

Solution

SimplestSolutionSimplestSolution

DuplicateMutuallyExclusive

AvoidRegression

AvoidRegression

ATDD Benefits

Encourages development work to be focused on meeting requirements

Encourages development of testable solutions for the requirements

Encourages requirements to be testable

Confirms when requirements have been met (the right code has been built)

Identifies overlapping and mutually excusive requirements

Ensure project does not regress15/04/15(c) 2014 Plaxion Limited. All rights reserved.

ATDD Costs

If the project is going to be tested against requirements

the benefits of using ATDD reduce testing costsusing ATDD reduce downstream costs

If the project is not going to be tested against requirements

using ATDD reduce downstream costs


Description of TDD

A long-established Agile practice

Process

Exceptions

Benefits

Costs


TODO listTODO list

TDD Process


Select Simplest

TODO

Write a Test toConfirm the behaviour

Write a Test toConfirm the behaviour

Test should FailSince code not

written

Test should FailSince code not

written

Write simplest codeTo pass the test

Test should PassTest should Pass

Commit all

TDD Process

1) Keep a local TODO list, continually refining the operations therein

2) Find the simplest thing on the list

3) Build a new test for it

4) Run the new test which should Fail indicating code not implemented yet (other tests still pass)

5) Fabricate the simplest possible solution

6) The new test should now pass (and other tests should still pass)

7) Commit the source to the configuration management system

8) Repeat

9) When the TODO list is empty, we are done


TDD Exceptions

New Test passes first time

New Test is wrong

Code already built: TODO list is out of date

New Test fails after new code is written

New Test is wrong

New code is wrong

New Test always fails

New Test is wrong


TDD Benefits


Simplest TestSimplest Test Focus on

Passing Test

Focus on

Passing Test

SimplestTestableSolution

SimplestTestableSolution

AvoidRegression

AvoidRegression

Good Code

Coverage

Good Code

Coverage

TDD Benefits

Encourages development to be focused on passing tests

Encourages development of testable code

Rapidly produces robust code (we have built the code right)

Low-level tests closely linked to function of code

Written by the developer, for the developers

Ensures code does not regress


TDD CostsIf the project is going to be verified:

the benefits of using TDD reduce verification and rework costsusing TDD will reduce downstream costs such as failures in the fieldThese savings may cover the costs of TDD

If the project is not going to be verified:using TDD will reduce downstream costs such as failures in the fieldThese savings may cover the costs of TDD


Compare ATDD and TDD


ATDD TDDTest Level High Low

Test Sets Failing &Passing

Passing

Failed Test duration Long Short

Coupling to requirements High Low

Coupling to code Low High

Number of Tests Low High

Developer written No Yes

Automated Yes Yes

Steps to using ATDD1) Build/purchase an automated Failing/Passing Acceptance Test

runner

2) Ensure that there are Acceptance Criteria for the requirements, agreed with the project sponsor

3) Write Acceptance Tests, add to Failing AT set

4) Run Acceptance Tests frequently

5) Optional: Organise features/requirements into prioritised list

6) Optional: Implement solution in phases / sprints / iterations

7) Optional: Use TDD – can be done by coding engineers


Conclusion

Conclusion ATDD is worth using to increase quality and reduce costs

Conclusion ATDD is worth using to increase quality and reduce costs

Other aspects of Agile software development are strongly recommended: continuous, iterative, incremental development, TDD, etc.

Acceptance- Test Driven Developmen · ATDD Process 1) Get the top priority requirement from (the...

Documents

Transcript of Acceptance- Test Driven Developmen · ATDD Process 1) Get the top priority requirement from (the...