Agile Acceptance Testing Closing the communication gap in software projects

1. Gojko Adzic gojko@gojko.net http://gojko.net http://www.neuri.co.uk Agile Acceptance Testing Closing the communication gap in software projects

2. Why should you care (PM/BA)? • Developers will actually read the specifications • They will understood the stuff correctly • They will not skip parts of the specs • You can track the development progress • Save time on acceptance/smoke testing

3. Why should you care (dev)? • Requirements will be unambiguous and without functional gaps • Business analysts will really understand those special cases you mentioned • You will have automated tests to guide development • It will be easier to take-over and hand-over code

4. Why should you care (QA)‏ • Finally stop those guys from making the same mistakes over and over • Avoid doing the same stuff all the time • Build quality in from the start • Vefify business rules by a click on a button

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

6. Traditional process is like the Telephone game! http://www.sxc.hu/profile/scol22

7. How many points are there?

8. How many points are there?

9. A “small” misunderstanding can cost lots of money!

10. Pay ₤2 for a 1000 clicks • what about 2500 clicks? • what about 500 clicks? • what about 999 clicks? • what about 1000 clicks over 2 days?

11. One of the most effective ways of testing requirements is with test cases very much like those for testing the completed system Donald Gause and Gerald Weinberg Exploring Requirements - 1989!

13. As formality increases, tests and requirements become indistinguishable. Robert C. Martin and Grigori Melnik Tests and Requirements, Requirements and Tests: a Mobius Strip IEEE Software January/February Issue 2008

14. Key practices • Discuss real-world examples to build a shared understanding of the domain • Use those examples as an acceptance criteria • Automate acceptance tests • Focus the development on those tests • Use the tests as a live specification to facilitate change

15. It is not UAT! • It is not even “testing” in the QA sense. • Customers, developers, business analysts involved as well as QA.

16. Better names • “Acceptance testing” is misleading! • Behaviours • Executable specifications • Examples

17. It is about improving the communication and providing guidance for development Although it is called “testing”, it is not really about QA

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

19. Step 1:Building a shared understandingof the domain

20. The Example-Writing workshop • Business people, developers and QA in the same room • Transfer the knowledge • Ensure that we all understand the same thing

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

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

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

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

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

26. People approach the same problem from different perspectives, so this avoids groupthink!

27. Step 2:Select a formal set of acceptance tests and automate them

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

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

30. Automate tests, but still keep them human-readable And you can add pictures as well….

31. This is a specification:

32. It is also a test

33. This as well

34. And this

35. Given a stock of prices 0.5,1.0 When the stock is traded at 2.0 Then the alert status should be OFF When the stock is traded at 5.0 Then the alert status should be OFF When the stock is traded at 11.0 Then the alert status should be OFF And this

36. The only technical slide...

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

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

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

40. Tests promote a consistent use of the DDD ubiquitous language!

41. Iteration flow (just a suggestion)‏

42. Step 4: Keeping in touch with changes

43. Previous examples help you ensure to discuss all important edge cases.

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

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

46. Common Excuses for not using Agile Acceptance Testing

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

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

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

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