Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

First steps in Test Driven Development

47 views

Published on

Slides from a presentation given by Simon Lynch to a meeting of IIBA UK's South West branch on 15 March 2018.

Published in: Business
  • Be the first to comment

  • Be the first to like this

First steps in Test Driven Development

  1. 1. Aviva: Public Test Driven Development Develop what you need…not what you think you need Simon Lynch BSc (Hons) SFC (Open) Lead Business Analyst Aviva UK Health Create TDD story Point story for test activity only Perform test Pass / fail? TDD or other functionality? Create / redevelop bug to fix functionality that has been broken Create a new story for development required, with a test sub-task TDD element only has failed – requirement identified Fail Other functionality Close off TDD story as a successful test Pass Close off TDD story as a successful test Develop functionality Perform test of specific scenario, including a re-test of TDD functionality Pass / fail?Fail Close off development story / bug as a successful test Pass Develop / redevelop bug fix Other scenarios require testing? No Perform a retest of all applicable scenarios Yes Have we identified something else wrong with the system not connected with our TDD process? Will the change impact other TDD scenarios that will result in a retest?
  2. 2. Aviva: Public About me… Business Analyst since 1999… When I’m not being a BA…
  3. 3. Aviva: Public What is Test Driven Development? Why use Test Driven Development? • It’s about putting the testing effort first to define the development required • Test scenarios are run through the undeveloped, ‘as-is’ system • If the actual matches the expected outcome, then no development is required • If the expected outcome is not seen, then a development requirement is identified • It is a ‘Test on failure’ approach • You are looking to adapt an already complex system • The system’s current functionality is fine, and doesn’t need to change • You want to build new functionality that you think isn’t already there, but could be…
  4. 4. Aviva: Public How do you use Test Driven Development? Identify scenarios Create a TDD story Perform tests Close TDD stories Create dev stories for failed tests
  5. 5. Aviva: Public Select a Network (Y/NA)? Select "No Valid Network" (Y/NA)? 1 N Y Y 1) Copy thethe original treatment page as-is. 2) Display a message saying "Network Exists- Select a Network". 3) Make the Candidate Network button active. 1a NA Y N 1) "No Valid Network" is selected in Candidate Network Screen. 2) Show the message "No Valid Network" and update the Network Direct Reason Code with NOVA code. 3) Allow the user to process the copied page as a non- Network page without mandating the use of Spec Finder. 4) Candidate Network Audit should be written. Step 1 - Click of Copy Button Step 1 Excepted ResultsScenarios Step 2 - Updates on Copied Page Step 2 Expected ResultsSub Scenarios Candidate Network Action Specs and/or TU changed in the copied over Treatment Page (Y/N)? "No Valid Network" or Network Switch Reason Code on Original Page (Y/N)? Specs and TU on the Original Treatment Active (Y/N)? Network Avialable Now (Y/N) ? TDD scenario example
  6. 6. Aviva: Public TDD as a flow
  7. 7. Aviva: Public What are the pitfalls of Test Driven Development • Not all scenarios are identified on day one – be prepared for several iterations of your scenario list • Scenario building can be a confusing exercise! Especially with a concept that has many permutations of expected outcome • Getting a collective understanding of the TDD process across the whole of the team took time: • What is a development story vs what is a bug? • When should the TDD story be closed? • Who is doing what in the process?
  8. 8. Aviva: Public • A great tool for building ‘over the top’ of an existing system • The test community like it – their work is at the start of the process • Business has certainty that the post- TDD system covers all their real-life scenarios • Developers only develop what is required, not what we think doesn’t work Token final slide motivational picture! Conclusion • TDD takes a bit of up-front work, and can be a brain-ache, but it is worth it!
  9. 9. Aviva: Public Thanks for your time Any questions? Email: simon.lynch@aviva.com Twitter: @SimonNLynch

×