AcceptanceTest Driven. Developmen t Julian Goddard 14/04/2015. (c) 2014 Plaxion Limited. All rights reserved.

Transcription

1 AcceptanceTest Driven Developmen t Julian Goddard 14/04/2015 1

2 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

3 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

4 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 plaxion@live.co.uk

5 Introduction - The audience

6 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 later

7 Business case for Agile Project benefits - RAVE R - Risk Mitigation A - Adaptability V - Visible Progress E - Early Value Personnel benefits - WoCoMo Wo - Work-rate Co - Communication Mo - Motivation

8 Project benefits - Risk Mitigation

9 Project benefits Adaptability

10 Project benefits - Visible Progress

11 Project benefits - Early Value

12 Personnel benefits - Work-rate

13 Personnel benefits Communication

14 Personnel benefits - Motivation

15 Business case for Agile Productivity Agile Higher Traditional Lower Higher Lower Higher Lower Lower Higher (Communication & Motivation) Adaptability (tenet) Robustness (Risk Mitigation & continuous testing) Costs (all of above)

16 Agile review

17 Agile review - Summary

18 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

19 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

20 Agile review Practices ATDD Automated build Backlog Burndown/burnup chart Continuous, iterative, incremental development Planning poker (Point estimation) Refactoring SCRUM Simplicity Sprint Daily stand-up meeting TDD Definition of Done User stories Kanban Velocity

21 Agile versus Traditional Traditional Agile Empirical Process Pre-defined Just-in-time Requirement s Fixed at Start Evolves Integrated & Verbal Self organising & Empowered Big design up front Collaboratio Remote & Written n Solution Developing Team Managed & Directed

22 Agile review project from A to B A B

23 Agile review project from A to B A A B

24 Agile review project from A to B A A B B

25 Agile review project from A to B A A B B B

26 Agile review project from A to B A A B B B B

27 Agile review project from A to B 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

28 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

29 Agile review Implementation Iterative SCRUM / Sprints / phases Incremental progression Complete at end of every cycle Practices such as ATDD and TDD

30 Description of ATDD An Agile practice ATDD 2010+, derived from TDD TDD (Kent Beck, Extreme Programming) derived from Unit tests Unit tests Process Exceptions Benefits Costs

31 ATDD Process Simplest High Priority Requiremen t Use (or write simplest) Acceptance Criteria Write Simplest Acceptance Test Failing AT Set When AT passes Backlog Passin g AT Set

32 ATDD Process 1) 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 complete

33 ATDD Exceptions New AT passes immediately New AT is wrong solution to requirement already implemented: duplicate requirement Never able to get New AT to pass New AT is wrong Not possible to implement solution: requirement is unachievable New AT passes, but other AT fails New AT is wrong Requirement is wrong: reverse it out and reconsider Requirement is mutually exclusive with another: ditto

34 ATDD Benefits (Simplest) Acceptance Criteria (Simplest) Requirement Duplicate Simplest Acceptance Test Avoid Regression Focus on Solutio n Simplest Solution Mutually Exclusive

35 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 regress

36 ATDD Costs If the project is going to be tested against requirements the benefits of using ATDD reduce testing costs using ATDD reduce downstream costs If the project is not going to be tested against requirements using ATDD reduce downstream costs

37 Description of TDD A long-established Agile practice Process Exceptions Benefits Costs

38 TDD Process Select Simplest TODO Write a Test to Confirm the behaviour Test should Fail Since code not written Commit all Write simplest code To pass the test TODO list Test should Pass

39 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

40 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

41 TDD Benefits Simplest Test Good Code Coverage Avoid Regression Focus on Passin g Test Simplest Testable Solution

42 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

43 TDD Costs If the project is going to be verified: the benefits of using TDD reduce verification and rework costs using TDD will reduce downstream costs such as failures in the field These 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 field These savings may cover the costs of TDD

44 Compare ATDD and TDD ATDD TDD Test Level High Low Test Sets Failing & Passing Passing Long Short Failed Test duration Coupling to requirements High Low Coupling to code Low High Number of Tests Low High Developer written No Yes Automated Yes Yes

45 Steps to using ATDD 1) 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

46 Conclusion

47 Conclusion ATDD is worth using to increase quality and reduce costs

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