Petros Plakogiannis - To BDD or not to BDD
•Télécharger en tant que PPTX, PDF•
0 j'aime•46 vues
The reason Agile and now DevOps took off so strongly in the Development community is not because they were more technological approaches, but because they provided more value to the business aspects of our companies. These revolutionary practices allowed us to deliver features faster, made our companies more competitive and helped them to generate more revenues. As testers we have the opportunity of using what is being called Shifting Left & Shifting Right for the same goal of Business Value and to help our companies not only deliver functionality faster, but also to understand how this new value is being adopted (or not!) by our customers. In this session we will review how we can use techniques such as User Story Hypothesis Value, Instrumentation Planning, Behavioral Analysis in Production, and End-to-End metrics to help our companies navigate the hypercompetitive business environment we are all a part of.
Recommandé
Recommandé
Contenu connexe
Similaire à Petros Plakogiannis - To BDD or not to BDD
Similaire à Petros Plakogiannis - To BDD or not to BDD (20)
Plus de QA or the Highway
Plus de QA or the Highway (20)
Dernier
Dernier (20)
Petros Plakogiannis - To BDD or not to BDD
- 1. Poison Centres PCN Portal Milestones and Bacjklog 13 March 2018 Poison Centres PCN Portal Milestones and Backlog 13 March 2018 Poison Centres Service management workshop: Business overview 29 October 2018 To BDD or Not to BDD QA or the Highway, 17 May 2022 Petros Plakogiannis
- 3. @Petros_2 Petros Plakogiannis Test Team Leader Test Automation Engineer @ 13 years of software testing
- 7. What is BDD ?
- 8. @Petros_2 What is BDD Behavior Driven Development
- 9. @Petros_2 BDD TDD o Implemented by the Devs o Implemented by the team o Business language o Programming language o End to end behavior of app o Individual functions/methods VS
- 12. @Petros_2 Tools
- 13. @Petros_2 Gherkin Language Gherkin is a bussines readable language The five important keywords are Given When Then And But
- 14. Reasons why we fail
- 15. @Petros_2
- 16. 1 BDD as a testing tool
- 18. @Petros_2 Business users continued to send documents
- 19. 2 Keep the features hidden
- 20. 3 Misunderstanding, Bad Gherkin
- 21. @Petros_2 BDD examples An example of a badly written scenario is this: Scenario: As an existing chemical accessor add a chemical property to a formula. Given I have an accessor user And I input the username And I input the password And I press the login button And can view the chemical addition page And I have the permission to add a chemical property And the corresponding formula can have more than two properties When I press the button “add property” And I input the chemical property And I press the confirm button And I press the button validate to validate the chemical property And I press the button to confirm the addition to the formula And I press the button to confirm the new formula Then the chemical property added to the formula
- 22. @Petros_2
- 23. How to implement proper BDD
- 24. 1 Train people
- 25. @Petros_2 Important Conversations Having conversations Is more important than Capturing conversations Is more important than Automating conversations Liz Keogh
- 26. @Petros_2 Living Documentation a.k.a Executable specification Living documentation is a reliable and authoritative source of information on system functionality, which anyone can easily access. It is as reliable as the code, but much easier to read and understand Gojko Adzic
- 27. @Petros_2 Living Documentation Tools that can help to make your living documentation accessible SpecFlow+ LivingDoc renders feature files in Azure DevOps with filtering and linking capabilities Cucumber for Jira allows you to capture scenarios and visualize them as living documentation
- 29. @Petros_2 Ubiquitous language Martin Fowler, the creator of Manifesto for Agile Software Development, ThoughtWorks “The practice of building up a common, rigorous language between developers and users”
- 31. @Petros_2 Naming is valuable tool Establish the common language and use it everywhere. Use it in the specifications and use it in your design of your code Jedi Substance AllSubstances
- 32. @Petros_2 Naming is valuable tool IndustryUser
- 33. @Petros_2 Naming is valuable tool IndustryUser.createSubstance (String data)
- 34. @Petros_2 Naming is valuable tool IndustryUser.createSubstance (String data) .updateSubstance(String data)
- 35. 3 Pre-Flight Checks and meetings
- 36. @Petros_2 Pre-Flight Checks and Meetings A Greater team comes together to discuss what the software will do. Product Owners Developers Testers
- 37. @Petros_2 Pre-Flight Checks and Meetings
- 38. 4 Write Correct Gherkin Syntax
- 39. @Petros_2 BDD examples An example of a badly written scenario is this: Scenario: As an existing chemical accessor add a chemical property to a formula. Given I have an accessor user And I input the username And I input the password And I press the login button And can view the chemical addition page And I have the permission to add a chemical property And the corresponding formula can have more than two properties When I press the button “add property” And I input the chemical property And I press the confirm button And I press the button validate to validate the chemical property And I press the button to confirm the addition to the formula And I press the button to confirm the new formula Then the chemical property added to the formula
- 40. @Petros_2 BDD examples Here’s a better and clearer way to write the scenario: Scenario: As an existing chemical accessor add a chemical property to a formula. Given A user is authenticated with his accessor user And can view the chemical addition page And the user has the permission to add a chemical property When the user add a property to the formula Then the chemical property added successfully to the formula
- 41. @Petros_2 BDD examples Here are some important points about scenarios and steps in Gherkin: The statements must be written in order "Given-When-Then" Neither should " Given-When-Then" be repeated per stage. To extend any of the sentences, "And" is used. As much as possible, do not use many steps for a single scenario Write the sentences to be explanatory and brief
- 42. @Petros_2 BDD examples Other Key Words to Describe the Scenarios Background Data Tables Tags
- 43. @Petros_2 Background Background: Given the user has already accessed the new tool And the user navigates to the page 'Risk Assessments' And the user enters the following to the 'Assessments' table: | Name | Assessment| | Assessment | Rosin | And the user navigates to New Scope wizard @basicFlow @resetState Scenario: Distinguish empty numeric properties that are outputs Given the user clicks on the 'House scenario by amateur' link in the 'House uses' use table …
- 44. @Petros_2 44 Data Tables Data Tables are defined at the step level and not at the scenario level @basicFlow @resetState Scenario: Model Properties are displayed at Scenario level of a Complex Substance Assessment Given the user navigates to the chemical scenario When the user clicks on the tab 'Conditions of Use' Then the 'Conditions of Use' form is displayed with the following values: | Name | Value | Unit | | Daily use amount at site |10 | t.d-1 | | Daily local widespread use amount |20 | t.d-1 | | Annual use amount at site |30 | t.y-1 |
- 45. @Petros_2 Tags The tags are annotations that serve to group and organize scenarios and even features @CHRIII-1452 Feature: … @SmokeTest @CHRIII-1452 Scenario: … @RegressionTest Scenario: …
- 46. 5 BDD as a process
- 47. @Petros_2 Dev/ QA Start three Amigos meetings
- 48. @Petros_2 A fully Behavior-Driven Sprint
- 49. @Petros_2 What we gain from BDD High visibility / transparency Software development meets user needs Strong collaboration More confidence from the developers' side Improve Quality of the product - Lower costs
- 50. @Petros_2 Take aways We need a ubiquitous language BDD is not an alternative to manual testing BDD is about collaboration BDD is not responsibility of testers
Notes de l'éditeur
- you might just need a Ph.D. in techno-babble to make sense of the definitions you'll find online. So let me first attempt to simplify the definition: BDD is a product testing methodology based on what real (human) users might actually do. Practically, it is an extension of agile product development.
- The first thing is about Behaviour. It is not how you write your tests, is not about the tools you use. It is about thinking the behavior of the software that are you writing. The second word is the Driven, that means that you are driving your development using the Behaviour. It is like Testing driven development but we thinking how we want the software to behave for the customer. If you are starting writing Cucumber scenarios after you written software you are not driving development. And of course the final is the development but at the end of the day we want to involve our Business people.
- BDD and TDD may seem very similar since they are both testing strategies for a software application. In both cases, we write the test before writing the code to make the test pass. BDD involves product managers, developers, and test engineers who collaborate to come up with concrete examples of desirable functionality. TDD can be done by a solo developer The TDD test asserts the result of a specific method, FOR A FEATURE (Writing in Developers languague) BDD test is concerned about the result of the higher level scenario. (Writing in Business language) (Unit Tests are Written before the business logic. For a feature)
- First, we need to describe the desired behavior in a feature file then we have to write step definitions (Step definitions the glue between features written in Gherkin and the actual tests implementation.) and then the test fails. After some code refactoring, the test passes The code has to pass the test scripts defined in BDD. If it does not happen, code refactoring will be need
- So we used to follow the “traditional” agile sprint one that is not yet behavior driven. Product owners write user stories, developers implement the solutions, and testers test the deliverables.
- So we used cucumber that you can write feature files using Gherkin language that is close to the natural language. The five important keywords are. We will see later some examples. Let me at this point to tell you a funny story why Cucumber is called cucumber. So The story goes that Aslak that created Cucumber, he was in home and asked his wife how should calls his new software, and he was eating a cucumber sandwich and she said cucumber. So Unfortunately, is called with this funny name Anyway, So we chose the tools and we applied the BDD.
- When you see a feature file you should be able to describe what is actually validating from the end-user perspective so scenarios like this are just test cases and they do not represent requirements. It’s better to avoid writing scenarios in this way because it makes them very long, with many unnecessary details.
- Training. Train business people and engineers on how to communicate better. What is BDD. That is a process and not just a tool that you can download. What are the advantages, do some presentations, have conversations. If you can’t have conversations, stop. You can’t do BDD.
- I am saying this loud and clear in Bold, because BDD is not to have a better test automation. You WILL get test-automation but is a SIDE EFFECT. BDD Is about collaboration and Communication. Η Λιζ Keogh : Agile coach Thoughtworks kai htane kai Lead developer sto JBehanve
- Publish them somewhere that everyone on the team will be able to read them as documentation. Something that is called Living Documentation. It is living, because it is generated by the automated test suite, each time the application is built. So it is always up-to-date. Γκόικο Άντζιτς
- Try to follow an implementation that the living documentation is available linked from the project dashboard, so you just open it in your browser and check out the scenarios that you want.
- BDD encourages simple languages to be used across teams, known as ubiquitous languages. The simple and easy to use language should be used in the way the tests themselves are written, so that in theory, a business person can read a test and understand what it is testing. Tests are often written from the customer’s point of view; the focus is on the customers and the users who are interacting with the product
- Find with your business team a Ubiquitous language. Develop a domain specific language that we can all understand. Develop a glossary of all business terms with definitions. Have open discussions, analysis of existing documents etc. so you can come up with better common language. Not a new concept (this book in 90’s)
- This domain language is the language of the business. That doesn’t mean web servers, databases, APIs, HTML, CSS or Javascript. It is the language of the business - so in our case: Substances,Chemical Safety report, legislations ec We can think of Chemical safety report for example as an object with data like safety report number, risk assessments, substance name, date created and so on Using a common language is very powerful. The code is clear and everyone can understand what is about.
- For example, the name in our key class was used to be: Jedi. Any idea what is this doing? Mean either. It is a cool name. I am fun of star wars but I don’t know what is doing. It tells you nothing at all. Since I am writing software about chemicals. So Substances it makes some sense. Or AllSubstances. Again very sensible, very useful.
- For example, the name in our key class was used to be: Jedi. Any idea what is this doing? Mean either. It is a cool name. I am fun of star wars but I don’t know what is doing. It tells you nothing at all. Since I am writing software about chemicals. So Substances it makes some sense. Or AllSubstances. Again very sensible, very useful.
- For example, the name in our key class was used to be: Jedi. Any idea what is this doing? Mean either. It is a cool name. I am fun of star wars but I don’t know what is doing. It tells you nothing at all. Since I am writing software about chemicals. So Substances it makes some sense. Or AllSubstances. Again very sensible, very useful.
- For example, the name in our key class was used to be: Jedi. Any idea what is this doing? Mean either. It is a cool name. I am fun of star wars but I don’t know what is doing. It tells you nothing at all. Since I am writing software about chemicals. So Substances it makes some sense. Or AllSubstances. Again very sensible, very useful.
- For me this is the most important part of BDD. Pre-Flight Checks meetings. The collaboration between development, test and product owner. To have conversations with your team. Instead of one person, working alone to create given/when/then, a greater team comes together to discuss what the software will do.
- This discussion creates a shared understanding. All roles in development can contribute to the work.
- So in BDD business persons, developers and testers come up with examples of how the software should behave, and write them down as Cucumber Features and Scenarios.
- Analysis team did not follow the patterns to write correct Gherkin syntax
- It’s better to avoid writing scenarios in this way because it makes them very long, with many unnecessary details. Its harder to read them and understand them and maintain them.
- Remember behavior scenarios are more than tests – they also represent requirements and acceptance criteria. The First Person Dan North (considered the creator of BDD), as we found in a reference in Stack Overflow, recommends the use of the first person, and in fact it’s what he uses to write his scenarios in his article, "Introducing BDD.“ The Third Person The defenders of this position argue that the use of the first person makes the scenario reader lose reference to the role or the user that is being talked about. If I write in a step "I delete an article from the system," who is the one that is doing it? An administrator, a particular user? A set of roles? In some way, the use of the third person diminishes the risk or the difficulty of the reader making erroneous assumptions about who is the stakeholder(s) involved. Conclusion There is no general rule about the point of view to use to write the scenarios.
- Given" represents a precondition, "When" an action and "Then" a result or consequence of the action 3) Τhe idea is that a user who does not know the functionality should be able to understand it by reading the scenario. The less you have to read to understand it, the better.
- If in all the scenarios of the same feature, some preconditions are met, it is much more practical to use a Background than to write the same thing several times. This serves as a series of steps that will be executed before all the scenarios of the feature. Let’s see an example:
- Very useful. Data Tables serve to pass input data to a single step within the scenario.
- These are written with the @ symbol followed by a significant text, examples:
- It’s time to start shifting left. Schedule pre-flight checks meetings with analysts and devs to proactively discuss user story expectations. Analyst and dev folks are convinced of BDD’s benefits, encourage them to participate in writing Gherkin.
- Keep going. When they get comfortable, encourage product owners to write acceptance criteria in Gherkin when they write user stories, and hold pre-flight checks meetings before sprint planning as part of refining. Convince them that for them to help write Gherkin scenarios is a process efficiency for the whole team.
- So when we applied properly the BDD we had some results: With BDD, all the involved parties have a strong understanding of the project By using a common language, everyone gets strong visibility By focusing on the business’s needs, you get satisfied users Developers are much more confident that they won’t break the code By improving the quality of the code, you are reducing costs of maintenance and minimizing the project’s risks.
- These are my main takeaways and hopefully you will find then useful when you decide to use BDD methodology.
- Hence, paraphrasing the famous opening phrase of William Shakespeare’s play Hamlet “To BDD or not to BBD” I will say there is not a correct answer. In some cases adopting BDD might be the best solution but you have to apply it properly. Just remember there’s more than one way to create good software! Thank you!