Recommended
More Related Content
Similar to Bridging the gap between business and technology - BDD - Oslo, Norway, 2015
Similar to Bridging the gap between business and technology - BDD - Oslo, Norway, 2015 (20)
Recently uploaded
Recently uploaded (20)
Bridging the gap between business and technology - BDD - Oslo, Norway, 2015
- 1. Bridging the gap between business and technology Behaviour Driven Development with Drupal Marcin Pajdzik Twitter: @Marcin_Pajdzik Oslo, November 2015
- 2. How BDD works? Write scenarios that describe behaviours ▼ Execute the scenarios against your application Find me on Twitter: @Marcin_Pajdzik
- 3. How BDD works? Write each step of your scenario in plain English ▼ Write each step definition in PHP Find me on Twitter: @Marcin_Pajdzik
- 4. NHS - National Health Service Project started in 2002 Project terminated in 2010 Cost: €14 400 000 000 (billion) Find me on Twitter: @Marcin_Pajdzik Cost: 200 billion NOK
- 5. NHS - National Health Service €14.4bn would pay a salary of: 60000 nurses for 10 years in the UK 240000 nurses for 10 years in Poland Find me on Twitter: @Marcin_Pajdzik
- 6. NHS - National Health Service Result: IT system was not FIT for the NHS Find me on Twitter: @Marcin_Pajdzik
- 7. Why projects fail? 3. Unrealistic deadlines 2. Insufficient resource planning 1. Poor communication Source: Computing Technology Industry Association, 2007 Find me on Twitter: @Marcin_Pajdzik
- 8. Why projects fail? Source: Project Management Institute, 2013 Find me on Twitter: @Marcin_Pajdzik
- 9. Why communication is important? As developers we deliver business value Business value is what really matters to the business We find out what really matters to the business through Effective communication! Find me on Twitter: @Marcin_Pajdzik
- 10. Why communication is difficult? When two people communicate Misunderstandings! Find me on Twitter: @Marcin_Pajdzik
- 11. Why communication is difficult? When technical and business people communicate… …they speak different “languages” Even more misunderstandings! Find me on Twitter: @Marcin_Pajdzik
- 12. Why communication is difficult? When people work on a large project… …no one fully understands the project Misunderstanding all the time! Find me on Twitter: @Marcin_Pajdzik
- 13. The main idea behind BDD … … is to prevent communication gaps! Find me on Twitter: @Marcin_Pajdzik
- 14. The main idea behind BDD Tests written in PHPSoftware Developer QA Analyst Business Analyst Product Owner TDD BDD Scenarios written in English Find me on Twitter: @Marcin_Pajdzik
- 15. Benefits of BDD 1. Collaboration / Communication - same language for all 2. Quality – functional / integration / regression tests 3. Prioritisation - business and behaviour first 4. Documentation Find me on Twitter: @Marcin_Pajdzik
- 16. What is BDD? Agile technique based on TDD… …that promotes communication and close collaboration between everybody in the team… …and focuses on writing specifications of the system behaviour. Find me on Twitter: @Marcin_Pajdzik
- 17. BDD solves TDD shortcomings What to test and what not to test Where to start with development How to understand why tests fail Find me on Twitter: @Marcin_Pajdzik
- 18. BDD features / stories As a [Role] I want [Feature] So that I receive [Value] As a user I want to login So that I can access my account Find me on Twitter: @Marcin_Pajdzik
- 19. BDD scenarios Given some initial context When an event occurs Then ensure some outcomes Given I am on the login page When I login as “jsmith” with password “secret” Then I should see my account page Find me on Twitter: @Marcin_Pajdzik
- 20. What is BDD scenario? Specification that everybody understands Documentation that everybody can refer to Automated test that can be run any time Find me on Twitter: @Marcin_Pajdzik
- 21. BDD with Drupal Behat • Tests / scenarios in a human-readable language called Gherkin • Parses scenarios into executable test-cases Find me on Twitter: @Marcin_Pajdzik
- 22. BDD with Drupal Mink • Web acceptance tests • Provides step definitions for interactions with a browser Find me on Twitter: @Marcin_Pajdzik
- 23. BDD with Drupal Drupal Extensions • Provide Drupal specific scenarios and step definitions Find me on Twitter: @Marcin_Pajdzik • Set up test data with Drush or the Drupal API • Define theme regions and test data appears within them • Clear the cache, log out, and other useful steps
- 24. BDD with Drupal Drupal Extentions • Blakbox Driver • Drupal API Driver Find me on Twitter: @Marcin_Pajdzik • Drush Driver
- 25. Can everybody access scenarios? Tests written in PHPSoftware Developer QA Analyst Business Analyst Product Owner TDD BDD Scenarios written in English Find me on Twitter: @Marcin_Pajdzik
- 26. Can everybody access scenarios? Behat JIRA extention Find me on Twitter: @Marcin_Pajdzik
- 27. Can everybody access scenarios? TDD Tests written in PHPSoftware Developer QA Analyst Business Analyst Product Owner BDD Scenarios written in English Find me on Twitter: @Marcin_Pajdzik
- 28. Any drawbacks? Increases the cost of maintenance Before doing BDD make sure that there is… …enough return on investment to justify it! Find me on Twitter: @Marcin_Pajdzik
- 29. BDD in Business Find me on Twitter: @Marcin_Pajdzik
- 30. Dennis Publishing Find me on Twitter: @Marcin_Pajdzik
- 31. Dennis Publishing “After the decision to move our websites onto Drupal, adopting Behaviour Driven Development has been one of the best decisions we’ve made for our organization in years.” Find me on Twitter: @Marcin_Pajdzik Paul Lomax - CTO, Dennis Publishing
- 32. Funding Tree Find me on Twitter: @Marcin_Pajdzik
- 33. Find me on Twitter: @Marcin_Pajdzik
- 34. References Dan North & Associates - http://dannorth.net Behat - http://behat.org Mink - http://mink.behat.org DSpeak - http://dspeak.com/drupalextension/intro.html Find me on Twitter: @Marcin_Pajdzik
- 35. Thank you / Takk Marcin Pajdzik / pron.: pie – gic / Owner / Consultant @ Codewriters Ltd Find me on Twitter: @Marcin_Pajdzik Co-Owner / CTO @ Onlicar LinkedIn: uk.linkedin.com/in/marcinpajdzik/ Twitter: @Marcin_Pajdzik
Editor's Notes
- How many people in this room know what BDD is? How many of you use BDD? To understand and be able to implement BDD the right way within an organization, one must understand that BDD is not about testing. Ok, I exaggerated. What I want to say is that BDD is not primarily about testing. The primary reason for introducing BDD in your business should not be testing. It is a mistake to use BDD just for testing. If testing is the only reason you want to do BDD, you should rather consider something else. The goal of this presentation is to show you why and when you should consider using BDD in your organisation. Which is only when BDD can actually provide value to the business.
- Here is how BDD works. You need to write scenarios that describe behaviours. And then the scenarios are executed against your web application. These scenarios are tests. They describe the business logic in your application. When you think about this, the concept is similar to TDD. So let's see what is different here.
- Each scenario will consist of a number of steps. I will give you examples of scenarios later on. For now, what is important to notice is that you write each step of your scenarios in plain English (or any other human language). I know people doing that in French. Not sure if anybody does it in Latvian yet? Ok, so you write your scenarios in plain English. And now you have a problem because those scenarios should be executed against your application. How can you execute a plain English text? Well, you need to write a step definition for each step of your scenario in a programming language. In your case it would be PHP. Can you see the problem here? You have to maintain both plain English scenarios and corresponding PHP code. This is quite a lot of overhead. You would not want to do that only for testing because you can easily write all your tests in a programming language and have much less to maintain. So the question still remains. Why would you use BDD? Let's forget about BDD for the time being and let's have a look at one of the biggest (if not the biggest) IT projects in the UK
- National health service is UK's public health care. Many years ago, in 2002 the UK government started a very ambitious IT project. The goal was to bring all patient data together into one universal system. This system was supposed to help the doctors manage patients health records. The development had been going for long 8 years or so and then in 2010 the project was terminated. The development cost taxpayers over 14 billion Euro.
- For an investment of 14 billion Euro you would expect quite a sophisticated piece of software. This is a large amount of money. To put that into context, 14 bullion Euros would pay the salary of 60 thousands nurses in the UK for 10 years or 240 thousands nurses in Latvia or Poland.
- So what the taxpayers got after 8 years of development and 14 billions Euros pumped in? Nothing. A government enquire into the project concluded that the project was not fit for NHS. That means that after 8 years they realise that they were developing the wrong thing. How could that happen?
- I think that everybody can see now that communication is important. But why is it so important? Yes, we know, so many projects fail because of communication. But why? If we are not able to communicate with the business
- BDD is a used to facilitate communication!
- BDD is more than TDD because it focuses on collaborating with business people. Dan North, who originated the BDD moniker, noticed that business people switched off in conversations about "tests" as these seem to be too technical. He hoped that framing conversations about "behaviours" would be a way to engage the whole team.
- BDD is about figuring out what to build that helps flesh out behaviour. BDD isn't an Agile framework or project management approach. Teams using Scrum or Kanban with BDD will need to figure out what to put in their backlogs and boards for planning purposes. You might want to measure the number of BDD scenarios delivered instead of velocity but often these scenarios are too fine-grain for release planning purposes.
- Features identified are represented as User Stories[1]. Each user story provides a description of a feature that provides value to a user. Although User Stories do not define a strict format, many teams have found the following format useful:
- We need examples to understand. Realistic examples are a great way to communicate, and we use them often without even thinking about it. Working with real world examples help us to communicate better because people will be able to relate to them more easily.
- Not modules
- You can run the tests on a local or remote server, and all the actions will take place through the site’s user interface The blackbox driver allows you to create a map between a CSS selector and a user-readable region name so you can use steps like the following without having to write any custom PHP: The Drupal API Driver is the fastest and the most powerful of the three drivers. Its biggest limitation is that the tests must run on the same server as the Drupal site. Many tests require that a user logs into the site. With the blackbox driver, all user creation and login would have to take place via the user interface, which quickly becomes tedious and time consuming. You can use the Drush driver to add users, reset passwords, and log in by following the steps below, again, without having to write custom PHP. You can also do this with the Drupal API driver. The main advantage of the Drush driver is that it can work when your tests run on a different server than the site being tested.
- BDD is more than TDD because it focuses on collaborating with business people. Dan North, who originated the BDD moniker, noticed that business people switched off in conversations about "tests" as these seem to be too technical. He hoped that framing conversations about "behaviours" would be a way to engage the whole team.
- Behave Pro for JIRA Agile
- BDD is more than TDD because it focuses on collaborating with business people. Dan North, who originated the BDD moniker, noticed that business people switched off in conversations about "tests" as these seem to be too technical. He hoped that framing conversations about "behaviours" would be a way to engage the whole team.