Presented at Sydney Testers Meetup with Priyank Singh Dhillon

1. JOURNEY OF ACCEPTANCE TEST DRIVEN
DEVELOPMENT
“Begin with the end in mind.” — Stephen R. Covey

2. About the speakers
Devesh Maheshwari
Blog: http://www.devmaheshwari.wordpress.com
Twitter: @demahesh
Priyank Dhillon
Blog: http://priyankdhillon.wordpress.com/
Twitter: @priyankdhillon
2

3. Agenda
3
 What is Acceptance Test Driven
Development?
 Where is it applicable
 How it differs from TDD
 See ATDD in action(Cucumber and Ruby)
 Touch point on various BDD tools
 Anti-patterns & Challenges

4. Some reasons why projects fail
4

5. Delivering late
5

6. Going over budget
6

7. Delivering wrong
product/feature7
Sales
Department
Development
Team
Customer
1. Initial requirements
Project was rejected by the customer
“Actually, we asked for something different”
2. Adjusted requirements
3. Wrong product

8. Wrong product contd…
8

9. Unstable
9

10. Maintenance cost
10

11. How to target these problems
 Communication
 Collaboration
 Automation
 Process improvements
 Shared understanding
11

12. Test Driven Development
12

13. TDD …
 Is a test first approach
 It leads to think about “How to use a
component” than “how to implement”
 As much about design technique as testing
technique.
13

14. Quote from Dan North
“TDD will cause me to have lots of tests, but it
won’t necessarily get me nearer the goal of
delivering business value through software”
14

15. ATDD is about…
15
 Communication
 Collaboration
 Automated acceptance criteria
 Living documentation
 Shared understanding
 Process improvements
 Building the right software
15

16. ATDD Cycle
16

17. ATDD & TDD go hand in hand
17
 TDD helps to develop product right
 ATDD helps to develop right product

18. Shared understanding
“Having the conversation
is more important than
recording the conversation
is more important than
automating the conversation”
– Liz Keogh
Source: http://lizkeogh.com/behaviour-
driven-development/
18

19. How to build shared
understanding
Shared
understanding
Story
Examples
Automated
Acceptance
Criteria
Working Software
and Living
documentation
19

20. Acceptance Criteria
+
Examples (data + scenarios)
_____________________
Acceptance Tests
_____________________
Given some precondition
When I do some action
Then I expect some result
Acceptance Tests
20

21. Good Acceptance Tests
S – Specific: Explicitly defined and definite
M – Measurable: Possible to observe and quantify
A – Achievable: Capable of taking place
R – Relevant: Having a connection with the story
T – Time bound: When will the outcome be observed
Rules
 Focus on “what” you are testing and not on “how”
 Eliminate irrelevant details
 Consolidate similar tests with readable tables
 Use decision tables and boundary analysis to get high
coverage
21

22. Acceptance Criteria
Feature:
As a Customer
I want to borrow money from the bank
So that I can go on Holiday and enjoy myself
Acceptance Criteria:
In order to get the Holiday Loan approved
1. The Customer must be 18 or older
2. The Customer’s salary must be > $20,000.00
3. The Customer Time in employment must be >= 6
months
4. The Loan amount < (Customer salary)/5
22

23. 23

24. Step 1 - basic test
24

25. Focus on “what” you are testing not on
“how”
25

26. Eliminate irrelevant details
26

27. Cont..
27

28. Consolidate similar tests with
readable tables
28

29. Scenarios – looking back
29
 Define system behavior, not steps
 Simplifies long term maintenance
 Captures domain knowledge
 Do not rely on implementation details
 Test should be self-describing
 Define allowed and disallowed scenarios
 Provide right and failing examples
 Use iterative approach
 Start with defining of the happy path
 Use domain language

30. ToolsFrameworks
30
 JDave - http://jdave.org/
 Concordion - http://www.concordion.org
 Easyb - http://easyb.org/
 Thucydides- www.thucydides.info
 Jbehave (Java) - http://jbehave.org/
 Cbehave (C) - https://code.google.com/p/cbehave/
 Cucumber - http://cukes.info/
 Igloo (C++) - http://igloo-testing.org/
 Cuke4Nuke
 SpecFlow
 Spinach

31. Will cucumber test the
features?
No, not really
 Parse the gherkin
 Match gherkin with your test functions
 Execute the matched test functions
 Generate a report
31

32. Lets see it in action
32

33. Benefits
33
 Better definition of scope and “done”
 More scenarios identified upfront
 Preventing defects is cheaper than fixing them
 Prevents system regression
 Same visibility for all roles on the team
 Provide visibility
 Living documentation
 Remove the ambiguity
 Customer can give you early feedback
 Customer can read and write some of them

34. Challenges in adopting ATDD
Works best in an iterative environment
34

35. Challenges cont...
Writing good scenarios takes practice
35

36. Challenges cont...
Poorly written tests
can lead to higher
test
maintenance cost.
36

37. Challenges cont...
Treat test automation code like production
code.
37

38. Challenges cont...
It requires high business engagement and
collaboration
38

39. Anti patterns
 The product owner/business analyst writes the
scenario and then gives them to the other
team members.
 Scenarios are UI focused and missing context
(business value).
 Testing team writes the scenario at the end to
implement an automated test suite.
 Developers coming up with scenarios without
having conversation with the team.
39

40. Way for a better specifications
40
 Collaborative approach
 Specify behavior, not implementation
 Testable requirements
 Automate specification tests
 Control specification maintainability

41. Other names of ATDD
 Behavior Driven Development
 Specification by example
 Executable specification
41

42. 42
ATDD is not just about
frameworks
It’s about conversation

43. Making Hard Decisions
Usually early in the project
 Should I use ATDD at all ?
 Should I use Gherkin, will I get value out of it ?
 Should I test UI or only the core ?
 How much UI should I test ?
 Will my customer would read the gherkin ?
 Will my customer be available to participate in
conversation ?
 Is my technical team is the customer ?
 I would like to change my mind in the future.
43

44. Want to learn more
 Dan North’s blog
http://dannorth.net/introducing-bdd/
 Elisabeth Hendrickson blog
http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview
 BDD in action by John Smart
http://www.wakaleo.com
http://www.thucydides.info
 Lisa Crispin and Janet Gregory
http://www.agiletester.ca/
 Wikipedia
http://en.wikipedia.org/wiki/Behavior-driven_development
 Few other links
http://www.extremeprogramming.org
http://lostechies.com/derekgreer/author/derekgreer/
http://mysoftwarequality.wordpress.com
https://blog.codecentric.de
http://mysoftwarequality.wordpress.com/2012/12/14/how-to-transform-bad-acceptance-
tests-into-awesome-ones/
https://blog.codecentric.de/en/2013/08/cucumber-setup-basics/
44

45. The End
45