Benefits of Behaviour Driven Development

Die moderne Softwareentwicklung in agilen Teams bietet allerlei Vorteile. Allerdings ändern sich dadurch die Anforderungen an die Software und somit auch die Software selber. Dadurch kommt im Laufe der Zeit die Frage auf "Was wurde warum wie realisiert?", welche immer schwerer zu beantworten ist, was die weitere Entwicklung bremst, da alte Anforderungen aufwendig rekonstruiert werden müssen.

Diese Problemstellung verspricht Behaviour Driven Development zu lösen.

Wir werden zuerst die Grundlagen zu BDD erklären. Danach werden wir an einem Praxisbeispiel zeigen, wie man mit BDD ein Feature vom Anforderungsdesign bis zur Inbetriebnahme begleitet.

Dabei wird sowohl die technische als auch die fachliche Perspektive gezeigt und der Mehrwehrt für das Management erläutert.

Transcript

1. Benefits of Behavior Driven Development 30.08.2018
2. About us Michael Küsters Thought Provoker https://www.linkedin.com/in/michaelkuesters/ https://www.xing.com/profile/Michael_Kuesters8 Currently: Agile Coach Experienced Product Owner, Scrum Master, Analyst, Developer, Tester, Sysop, Supporter, Manager, CTO, Trainer. About me • Book Author: "The Spirit of Scrum", "Extreme Agility" • Blogger: www.failfastmoveon.blogspot.com • Agnostic Agilist: www.agnosticagile.org • Father of two Do certificaties matter? Finies Fenske IT-Consultant / Technical Coach https://heartfor.it https://www.linkedin.com/in/finies-fenske/ https://www.xing.com/profile/Finies_Fenske Currently: System Architect Experienced Developer, Tester, Devops, DBA, Architect, UX/UI Specialist. About me • Blogger (https://medium.com/@heartfor.it) • My heart beats for bytes • Father of one • Coach • Trainer • Consultant. 2
3. The PITA* (* = pain in the @)
4. Every project ever • Collect Requirements • Formalize Acceptance Criteria • Specify • Go into the engine room • Develop a solution • Test • Fix the problems • Present • Get Feedback • Hope the release works • Things have changed • “Go to Jail, do not pass Go, do not collect money.” • Run!!! 4
5. Traditional Quality Control (“agile”) (Friendly) User Tests Functional Tests Unit Tests Acceptance Criteria 5
6. Unresolved Consistency Acceptance Criteria Solution Specification Documents Test Suite TDD Analysis QA Development 6
7. Changes: Rework or Inconsistency Acceptance Criteria Solution Specification Documents Test Suite TDD Analysis QA Development 7
8. Changed Acceptance Criteria Acceptance Criteria Solution Specification Documents Test Suite TDD Analysis QA Development Scrum way: Freeze Acceptance Criteria at Planning. Problem: “Doing the wrong thing righter” 8
9. Specification Changes Acceptance Criteria Solution Specification Documents Test Suite TDD Analysis QA Development Agile way: Pairing, Rework. Problem: Scope creep. 9
10. Design Changes Acceptance Criteria Solution Specification Documents Test Suite TDD Analysis QA Development Agile way: Redesign, Rewrite. Problem: Expectation mismatch 10
11. Test Changes Acceptance Criteria Solution Specification Documents Test Suite TDD Analysis QA Development Agile way: Continuous Integration Problem: Misleading quality statements. 11
12. There’s a problem ... … for every solution 12
13. Risks (Friendly) User Tests Functional Tests Unit Tests Acceptance Criteria • Asynchronous • Different models • Gaps • Inconsistencies • Loopback • False Positives 13
14. The solution
15. Bring people together • Business Roles ◦ Product Owners, Stakeholders, Customer Service • Analytical Roles ◦ Business Analysts, Process Managers, Data Analysts • Executing Roles ◦ Developers, Administration, x-Level-Support • User Roles ◦ Customers, Business Users, Testers ⇒ Harmonize different goals, needs, understanding 15
16. Change everything! • One model for everyone • One language for everybody • One place for everything • One document for everything • One process for change One truth! ⇒ Common understanding 16
17. Why? • Business and technical people understand each other • Specification, system documentation and solution are aligned • Real user expectations are tested • Move from “test level thinking” to “design for quality” • The only truth is in the code!!! • Reduce waste and write versioned specifications which are in place Oh - and you no longer need JIRA 17
18. The test pyramid One design - refactor instead of duplicating 18
19. How do we get there? It’s a journey!
20. Basic process 1. Business Define what you want 2. Business Define what you expect 3. Developers Decide what is needed 4. Everyone Separate concerns 5. Business Offer examples 6. Everyone Close understanding gaps 7. Developers Incrementally implement behaviours 8. Everyone Adjust behaviour definition as needed 9. Developers Verify that all behaviours are correct 20
21. Step 1: Business - Define what you want Scenario: Order payment Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” 21
22. Step 2: Business - Define what you expect Scenario: Order payment Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” The customer is on the payment page Credit, Debit, Paypal Items are moved from basket to Order Verify that all basket items are available By mail “Thank you” page All order items Order amount Address, due date Fraud Shipping by DHL, GLS, Hermes Replacement Discount, Voucher Minimum Order Value Upselling DSGVO / GDPR? 22
23. Step 3: Developers - Decide what is needed Scenario: Order payment Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” The customer is on the payment page Credit, Debit, Paypal Items are moved from basket to Order Verify that all basket items are available By mail “Thank you” page All order items Order amount Address, due date Fraud Shipping by DHL, GLS, Hermes Replacement Discount, Voucher Minimum Order Value Upselling DSGVO / GDPR? Mail Service Order Service Legal Fulfilment Service 3rd party API 3rd party API UX Template UX Template ? ? ? ? ? Payment Service 23
24. Order Service Step 4: Everyone - Separate concerns Scenario: Order Payment Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” Credit, Debit, Paypal Items are moved from basket to Order Verify that all basket items are available By mail “Thank you” page All order items Order amount Address, due date Fraud Shipping by DHL, GLS, Hermes Replacement Discount, Voucher Minimum Order Value Upselling DSGVO / GDPR? Mail Service Legal Fulfilment Service 3rd party API 3rd party API UX Template ? ? ? ? ? Payment Service The customer is on the payment page UX Template 24
25. Scenario: Order Payment Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” Scenario: Order Payment: Payment page Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” Step 4: Everyone - Separate concerns (2) The customer is on the payment page UX Template Payment Service 25
26. Scenario: Order Payment: Payment page Given a customer wants to purchase their basket When The payment is made Then An Order is Placed And The customer is notified that “the order is paid and on it’s way” Step 4: Everyone - Separate concerns (3) Scenario: Payment Page Given a customer wants to purchase their basket When the customer is on the payment page Then The customer’s basket items are listed And The invoice total is presented And A “Buy now” button is displayed And A list of possible payment methods is displayed Payment Service The customer is on the payment page UX Template 26
27. Step 5: Business - Offer Examples Scenario: Payment Page Given a customer wants to purchase their basket When the customer is on the payment page Then The customer’s basket items are listed And The invoice total is presented And A “Buy now” button is displayed And A list of possible payment methods is displayed 27
28. Step 5: Business - Offer Examples(1) Scenario: Payment Page Given a customer wants to purchase their basket When the customer is on the payment page Then The customer’s basket items are listed And The invoice total is presented And A “Buy now” button is displayed And A list of possible payment methods is displayed 1. Item name 2. Item quantity 3. Item price 4. Tax 5. Line Total 28
29. Step 5: Business - Offer Examples(2) Scenario: Payment Page Given a customer wants to purchase their basket When the customer is on the payment page Then The customer’s basket items are listed And The invoice total is presented And A “Buy now” button is displayed And A list of possible payment methods is displayed 1. Item name 2. Item quantity 3. Item price 4. Tax 5. Line Total Your Order 2 Red Radish 0,79€ (7%) 1,58€ 1 The Healthy Juice 2,99€ (19%) 14,99€ 1 Pink Panther Figure 14,99€ (19%) 14,99€ 29
30. Step 6: Everyone - Close Understanding gaps Scenario: Payment Page Given a customer wants to purchase their basket When the customer is on the payment page Then The customer’s basket items are listed And The invoice total is presented And A “Buy now” button is displayed And A list of possible payment methods is displayed 1. Item name 2. Item quantity 3. Item amount 4. Tax 5. Line Total Your Order 2 Red Radish 0,79€ (7%) 1,58€ 1 The Healthy Juice 2,99€ (19%) 14,99€ 1 Pink Panther Figure 14,99€ (19%) 14,99€ How do I know tax rate? Aligned? align right? Table or flow text? Fixed position Yes Version 1: Assume 19% for all 30
31. Step 6: Everyone - Close Understanding gaps Scenario: Listing basket items on payment page Given The Customer’s basket contains a number of items When The basket list is displayed on the payment page Then A table is generated And The table contains the following fields in list order Item Quantity | Item Name | Unit Price | Tax | Line Total And The table contains an entry for each item in the basket And The table is correctly indented and aligned 1. Item name 2. Item quantity 3. Item amount 4. Tax 5. Line Total Your Order 2 Red Radish 0,79€ (7%) 1,58€ 1 The Healthy Juice 2,99€ (19%) 14,99€ 1 Pink Panther Figure 14,99€ (19%) 14,99€ How do I know tax rate? Aligned? align right? Fixed position Yes Version 1: Assume 19% for all Table or flow text? Field | Alignment Item Quantity | right Item Name | left Unit Price | right Tax | left Line Total | right 31
32. Step 7: Developers - Incrementally implement behaviours Scenario: Listing basket items on payment page Given The Customer’s basket contains a number of items When The basket list is displayed on the payment page Then A table is generated And The table contains the following fields in list order Item Quantity | Item Name | Unit Price | Tax | Line Total And The table contains an entry for each item in the basket And The table is correctly indented and aligned Field | Alignment Item Quantity | right Item Name | left Unit Price | right Tax | left Line Total | right And Item names are truncated at 30 characters basketService .getBasket() Empty page, div tag renderTable (basket) columList= [“qty”, “name”,”price”, ”tax”,”total”] foreach (item in basket) {...} 32
33. Step 7: Everyone - Adjust behaviour definition as needed Scenario: Listing basket items within payment table Given The basket contains a list of items: name | qty | price Milk | 1 | 1 ,00 Eggs | 1 | 1,50 Flour | 5 | 0,50 When The basket list is displayed Then All items are listed correctly name | qty | price | tax | total Milk | 1 | 1 | 19% | 1,00 Eggs | 1 | 1,50 | 19% | 1,50 Flour | 5 | 0,50 | 19% | 2,50 foreach (item in basket) {...} 33
34. Step 8: Developers: Verify that all behaviours are correct Scenario: Order payment Scenario: Payment Page Scenario: Listing basket items on payment page Scenario: Listing basket items within payment table 34
35. Summary • Living Documentation • Single Source of Truth • Ubiquitous language • Consistent, reliable, traceable, sustainable quality statements • Change as needed 35
36. Lessons learned from practice
37. Team facing challenges • BDD process must be well understood ◦ Learning curve! • High levels of discipline required ◦ Tools aren’t solutions! ▪ Developers must write proper glue code ▪ Pairing instead of assuming ◦ Can end up as “Big Upfront Design” ▪ Resist doing everything at once! ▪ Cut out small value slices! • Track Specification Files ◦ Status: “Doable” vs. “Draft” vs. “In Progress” vs. “Implemented” ◦ Have a Repo for “toDo” and move to Source Repo as soon as possible • Finding the right test level ◦ Move the spec as close to the code as possible, but not too close! ◦ Don’t break important links during spec refactoring! 37
38. Business facing challenges • Lots of questions asked ◦ Business availability ◦ Business stakeholders need patience ◦ Interrupting business people during implementation • Tracking progress ◦ Don’t make promises too early ◦ Get used to discussing “Green” with Business ◦ Business stakeholders must learn to demand test results • Traceability ◦ Annotate spec files with “who requested this, when” ◦ Never forget: “Why” 38
39. Technical challenges • Suitability ◦ Difficult to use reliably on Legacy Code ◦ Goes hand in hand with technical tests, but can’t replace e.g, JUnit, Gatling • Choice of wording ◦ “The same sentence means the same thing - everywhere!” ◦ Describe so precisely that you’re not going to have the same condition twice meaning different things. • Antipatterns ◦ “God Objects” / Feature Envy (states) ◦ Refactoring private to public hints at unclean code ◦ Complex scenarios with low reliability • Tip: Test Annotations to create suites 39
40. Tools
41. How to? (bird view) • Cucumber allows us to implement BDD-Files language agnostic • Use your human language and your programming language and your test frameworks in mixture with cucumber • As already mentioned test kind does not matter • We used Gherkin • We wrote German specs Further Information: https://docs.cucumber.io/gherkin/reference 41
42. Questions?