Specification by example and agile acceptance testing, presentation given to HSBC developers on 21/09/09 for more info see http://specificationbyexample.com

1. Specification by Example and Agile Acceptance Testing Bridging the communication gap in software projects Gojko Adzic [email_address] @gojkoadzic http://gojko.net

5. http://www.flickr.com/photos/lambdachialpha/157986473/

6. http://www.flickr.com/photos/mulesafpilot/3513588967

7. http://www.defenseimagery.mil/assetDetails.action?guid=68cf92e35ce13e6c7c9c066f0b48b6daaa9bf8d8

9. The process is very much like a telephone game http://www.flickr.com/photos/mataniere/3107073262

10. How many points are there?

11. How many points are there?

13. B2 bomber crashed and $2bn went up in flames "the aircraft actually performed as it was designed. In other words, all the systems were functioning normally." Maj. Gen. Floyd L. Carpenter http://www.foxnews.com/wires/2008Jun05/0,4670,B2Crash,00.html

14. You can't help a lot when the party is already over... http://www.flickr.com/photos/biolog/3457774800

15. F-16 design team was asked to do the impossible - a cheap 2.5 Mach airplane! “ When asked […] why they need Mach 2 - 2.5, the answer was to be able to escape from combat. Their solution was […] providing acceleration and maneuverability, not maximum speed.” http://97-things.near-time.net/wiki/Seek%20the%20value%20in%20requested%20capabilities

16. Refuse requirements that are a solution to an unknown problem! http://www.flickr.com/photos/sylvancatharsis/3783608640/

17. 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 !

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

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

23. Iteration flow (just a suggestion)‏

24. Step 1: Building a shared understanding of the domain

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

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

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

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

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

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

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

34. This is a specification:

35. It is also a test

36. This as well

37. And this

38. And this 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

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

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

43. Automated test reports show where we are… When all the tests are green, the job is done

44. Step 4: Keeping in touch with changes

45. Live documentation As relevant and reliable as executable code, but much easier to read!

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

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