1. Agile Acceptance Testing Software 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 Specifications Examples Behaviours

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

6. Step 1: Building a shared understanding of 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 1.Check at the source 2.Inexpensive Verifications 3.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 test reports 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 the code is built right, and FitNesse insures the right code is built. Andy Dassing on the FitNesse mailing list

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