Myths and Challenges of Behaviour Driven Developmen

1. Myths and Challenges Behaviour
Driven Development
Practical Challenges and Overcoming Effectively
Pankaj Nakhat
pankaj@qagile.co.uk
#pnakhat

2. Agenda
• What is BDD Anyway?
• Why?
• Myths
• Deep Diving in to Challenges
• Discussion

3. BDD ?
• Short Definition
– “Behaviour‐driven development is about impleme
nting an application by describing its behaviour fro
m the perspective of its stakeholders” –
Dan North

4. What is BDD ?
• Behaviour Driven Development methodology
– http://en.wikipedia.org/wiki/Behavior_Driven_Development
– A Technique to Specify requirement
• Specification by example (Gozko Adzic)
• ATDD
• Methodology by which QA, BA and SMEs get involved early
in defining requirement through a common language.
• Specify the requirements in form of Given/When/Then/And
(Not mandated) – But widely accepted
• There is no loss/Distortion of love in BDD as same language
is used/shared among all the stakeholders in the project.
QAInfoLabs

5. Why BDD ?
• Defining requirements by example.
• Allows Business to Define Requirements in an
executable (Commonly Understood) format.
• Enhances collaboration between Technical and
Non technical team
• Behaviour of the system eventually becomes an
executable Acceptance test
• Allows team to focus on Behaviour aspects rather
then technical details
• Living Documentation
aaaa

6. BDD A Communication paradigm
BDD
QA
Dev
SME
BA

7. #Myths

8. #Myth : BDD is Cucumber or Cucumber is BDD ?

9. Infact its not about tool at all .
It is all about -- Communication

10. #Myth : BDD is a Testing framework /
Tool
• Keyword Driven framework
• Data driven framework
• Business Process Testing
• Replacement of Robot Framework in Selenium
These approaches focuses on reusability NOT on
Behaviours
Focus on test cases rather then requirement itself.

12. #Myth : BDD is a Testing Tool
If we Do BDD – We
can write tests in
English. Awesome!
Does it mean we should
start teaching English
Grammar to our
Employees ?

13. #Myth : BDD is not TDD
• BDD Focuses on behaviours
• TDD focuses on small unit of code
(Design)
• BDD Does not replace TDD
• BDD complements TDD
• BDD IS LIKE TDD IF…” BDD the same as TDD? Yes. If you’re a
programmer, and your entire team is programmers, and all your
stakeholders are programmers and you have a single Subject Matter
Expert embedded in the team. ” – Dan North

14. #Myth : BDD – Scenarios should be UI
Driven ?
• Behaviours != UI
• Focus on Behaviours, rather then how to
test behaviours.
• Sometimes UI is the last things you want to
develope, so relying on UI to test behaviours
is dangerous.

15. #Challenges : Getting Business
Involved ?
- Why would business buy the idea of writing
story/test/scenario/BDD ?
- If not should we use BDD then ?

16. BDD with Business
• Writing Given/When/Then is challenge for
business, however they can express the
requirements in conventional way.
• Sometimes trying to limit the language of
writing requirement limits the requirement
itself.
• What if business is not involved ?

17. An Interesting Interaction

18. #Challenge : Language Used in BDD
?/Abstraction
Scenario 1:
--------------------
Given a user navigates to registration page by clicking the link user registration
When user click on registration click
And user enter text in username : xyz
And user enters text in password : password
And user click on submit button
Then user gets redirected to confirmation page
And a message is shown “User Registered Successfully”
Scenario 2 :
----------------
Given I start the registration process
When I complete the registration process with valid credentials
Then I am registered successfully

19. Then user gets redirected to confirmation page
And a message is shown “User Registered”
Contd..
Given a user navigates to registration page by
clicking the link user registration
When user click on registration click
And user enter text in username : xyz
And user enters text in password : password
And user click on submit button
Registration
Process
Successfully
Registered
Navigation –
But how user is
not really
interested here

20. #Challenge : Implementation
• Abstraction is good but…
– It still relies on teams to do underlying
implementation as realistic as possible.
– DON’T DO THIS
– Or This…

21. #Challenges : Requirement Traceability
• How do you what is my test coverage against a
feature ?
Use tools to intelligently generate documentation for you/
Avoid one to one mapping of a story and a BDD feature file
Track your features not necessarily user story
• How to manage a change in requirement.
 Maintain metadata of story/Acceptance criteria against Scenarios
Use story maps
Use Tagging
Engage all the stakeholders in the process

22. #Challenge : Forgotten Art of
Automation Testing
Taken original from : http://blogs.agilefaqs.com/2011/02/01/inverting-
the-testing-pyramid/

23. Taken original from : http://blogs.agilefaqs.com/2011/02/01/inverting-
the-testing-pyramid/

24. #Challenges : Code Refactoring ?
- Its Easy to manage changes in unit tests when
the code is changed ?

25. #Challenge : Refactoring
- How to manage failing tests post refactoring or code
change ?
- Start TOP down and asses the change in behaviour
first.
- Failing Behaviours are feedback, welcome them.
- As a developer, Liaise with BA/QA/SMEs on failing
tests and don’t assume things, even though it may
sound trivial.

26. #Challenge : Slow running and “Flaky
Tests”
• Avoid One to One mapping of User Story and
BDD Test files
• Rather Map features with the tests
• Always keep the intent of the test clear and
use the right language of abstraction.
• Keep refactoring the BDD scenarios and if
needed create user journeys from multiple
scenarios.
• Avoid Testing everything through GUI.

27. Contd.. Slow running and “Flaky Tests”
• Avoid setups from GUI based tests, rather use
API or Database scripts.
• Find overlapping scenarios, and avoid testing a
thing in multiple scenarios.
• Refactor/Add/Delete and Clean Scenarios as
on-going process.
• Don’t keep unused scenarios in source
control, understand its living documentation.

28. Other Usage Of BDD

29. NFR Using BDD
- Use BDD to specify Performance, Security and Usability Tests
- Allows business to specify and measure the non functional
requirements .
- Allows frequent feedback on NFR
Given there are 10000 trades in system
When trades are processed
Then trades should be processed within 5 seconds.

30. Exploratory Testing
• BDD scenarios can be used for manual
exploratory testing.
• Can be used for
– Setting up data
– Setting a context automatically to a point
• Allows business to easily execute the
scenarios and give feedback regularly.

31. Demo Using BDDs
• Use the executable acceptance criteria's to
showcase features
• Benefits
– Setting context using Given/When/Then
Scenarios, which business is already familiar with
– No manual efforts setting up data etc
– Confidence with stakeholders as they can see
scenarios being executed

32. Lets Talk!