1 / 43

Agile Acceptance Testing Software development by example

Agile Acceptance Testing Software development by example. Gojko Adzic gojko@gojko.com. An experiment with four active battalions in US Army . Commander expectations matched actions in only 34% of the cases. L.G.Shattuck, 2000 http://www.au.af.mil/au/awc/awcgate/milreview/shattuck.pdf.

moira
Download Presentation

Agile Acceptance Testing Software development by example

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile Acceptance TestingSoftware development by example Gojko Adzic gojko@gojko.com

  2. An experiment with four active battalions in US Army Commander expectations matched actions in only 34% of the cases L.G.Shattuck, 2000 http://www.au.af.mil/au/awc/awcgate/milreview/shattuck.pdf

  3. Agile acceptance tests solve this problem! It might be called testing, but it is still important!

  4. Better Names:Executable SpecificationsExamplesBehaviours

  5. “Fit is a tool for enhancing collaboration in software development. “ Ward Cunningham, 2002

  6. Step 1:Building a shared understandingof the domain

  7. How do we verify that this thing we are going to write is implemented completely and correctly? Can you give us a few examples?

  8. Pretend it is magic… …and we deliver this software. How would you test it?

  9. Inconsistencies and gaps are easy to spot when you write the rules down!

  10. Real-world examples help flush out incorrect assumed rules find real business rules!

  11. People have think at a more detailed level and can't brush questions off…

  12. The acceptance test threesome “A BA, a Developer and a Tester go into a room…”

  13. Back to the military example: Only 19% of Commander's Intent statements had anything to say about the purpose of the mission The Mission: The Dilemma of Specified Task and Implied Commander's Intent William Crain (http://handle.dtic.mil/100.2/ADA225436),

  14. BA/Customers must help developers understand business reasons behind technical requests

  15. User stories are a great complement acceptance tests They communicate intent and have just enough detail to start the conversation

  16. User stories are the scope.Story tests are the specification.

  17. Writing story tests • Chance to learn about the domain • Capture the conversation! • Make sure that everyone speaks the same language • Flush out inconsistencies • Build a complete description

  18. Communicating Intent • Here's what I think we face • Here's what I think we should do • Here's why • Here's what we should keep our eye on • Now, talk to me. • Revised commander’s intent document, Karl Weick "Managerial thought in the context of action"

  19. Step 2:Automated specification check Because we are lazy…

  20. The Toyota Way Check at the source Inexpensive Verifications Test to prevent defects, not to discover them

  21. Save time on manually (acceptance/smoke)testing Verify business rules with the click of a button

  22. FIT and FitNesse allow you to automate tests, but still keep them human-readable And you can add pictures as well….

  23. Step 3:Providing focus for development No just-in-case code

  24. Developers will have to code exactly what was specified … not just the rules they see

  25. Acceptance tests should focus on business rules

  26. Automated testreports show where we are… When all the tests are green, the job is done

  27. Step 4: Keeping in touch with changes

  28. Automated tests show straight away when something is obsolete or broken

  29. Business people can actually read and understand tests!

  30. [tests became a] “significant and valuable business resource” Rick Mugridge, Doubling the Value of Automated Tests, Google Tech Talks 09/2007

  31. “It’s extra work and I don’t have time” Save time by not writing those big requirements docs that nobody reads…

  32. “But they will only look at the tests and not read the requirements…” Tests ARE Specifications

  33. “What if I leave something out? If they are using tests as the scope, and we do not specify some tests, what happens then?“

  34. “That’s cheating! We give the developers exactly what we are going to test, and they develop the software only to pass those tests…”

  35. “I won’t understand user stories and tests, I’m used to use cases” Story tests still contain triggers, steps, exceptions…

  36. “It’s impossible to describe UI layouts as FIT tests” So use something else – share the knowledge when you discuss tests

  37. “Rules are too scattered, there is no big picture” Communicate intent when writing stories, clean up tests to isolate rules, add some general docs…

  38. “Describe-Demonstrate-Develop” by Jim Shore A very useful way to think about acceptance tests in wider context http://jamesshore.com/Blog/How-I-Use-Fit.html

  39. Step 1: Describe • use a short paragraph to describe part of the functionality that the software supports.

  40. Step 2: Demonstrate • Provide some examples of the functionality • show the differences in possibilities

  41. Step 3: Develop • Implement the functionality using TDD.

  42. …xUnit insures thecodeisbuiltright, and FitNesse insures therightcodeisbuilt. Andy Dassing on the FitNesse mailing list

  43. Where next? http://gojko.net http://www.fitnesse.org http://www.fitnesse.info

More Related