Acceptance- Test Driven Developmen · ATDD Process 1) Get the top priority requirement from (the...
Transcript of 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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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.
Business case for Agile
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Project benefits - Adaptability
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Project benefits - Visible Progress
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Project benefits - Early Value
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Personnel benefits - Work-rate
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Personnel benefits - Communication
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Personnel benefits - Motivation
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Business case for Agile
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Agile review - Summary
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
A B
Agile review – project from A to B
A BA
Agile review – project from A to B
(c) 2014 Plaxion Limited. All rights reserved.
A BA B
Agile review – project from A to B
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
A BA B
B
Agile review – project from A to B
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Agile review – project from A to B
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Agile review - Implementation
IterativeSCRUM / Sprints / phases
Incremental progressionComplete at end of every cycle
Practices such as ATDD and TDD
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Backlog
ATDD Process
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
ATDD Benefits
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
(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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Description of TDD
A long-established Agile practice
Process
Exceptions
Benefits
Costs
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
TODO listTODO list
TDD Process
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
TDD Benefits
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
Compare ATDD and TDD
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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
15/04/15(c) 2014 Plaxion Limited. All rights reserved.
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.