Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Myths and Challenges of Behaviour Driven Development

830 views

Published on

Myths and Challenges of Behaviour Driven Developmen

Published in: Software
  • Be the first to comment

  • Be the first to like this

Myths and Challenges of Behaviour Driven Development

  1. 1. Myths and Challenges Behaviour Driven Development Practical Challenges and Overcoming Effectively Pankaj Nakhat pankaj@qagile.co.uk #pnakhat
  2. 2. Agenda • What is BDD Anyway? • Why? • Myths • Deep Diving in to Challenges • Discussion
  3. 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. 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. 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. 6. BDD A Communication paradigm BDD QA Dev SME BA
  7. 7. #Myths
  8. 8. #Myth : BDD is Cucumber or Cucumber is BDD ?
  9. 9. Infact its not about tool at all . It is all about -- Communication
  10. 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.
  11. 11. #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 ?
  12. 12. #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
  13. 13. #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.
  14. 14. #Challenges : Getting Business Involved ? - Why would business buy the idea of writing story/test/scenario/BDD ? - If not should we use BDD then ?
  15. 15. 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 ?
  16. 16. An Interesting Interaction
  17. 17. #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
  18. 18. 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
  19. 19. #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…
  20. 20. #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
  21. 21. #Challenge : Forgotten Art of Automation Testing Taken original from : http://blogs.agilefaqs.com/2011/02/01/inverting- the-testing-pyramid/
  22. 22. Taken original from : http://blogs.agilefaqs.com/2011/02/01/inverting- the-testing-pyramid/
  23. 23. #Challenges : Code Refactoring ? - Its Easy to manage changes in unit tests when the code is changed ?
  24. 24. #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.
  25. 25. #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.
  26. 26. 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.
  27. 27. Other Usage Of BDD
  28. 28. 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.
  29. 29. 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.
  30. 30. 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
  31. 31. Lets Talk!

×