Specification-By-Example mit Gherkin

Transkript

1 Specification-By-Example mit Gherkin VON ANWENDERBEISPIELEN ZU LEBENDER DOKUMENTATION Christian Hassa - ch@techtalk.at OOP Munich 2013,

2 Über mich Managing Partner bei TechTalk Gegründet 1993, ~50 Mitarbeiter Agiles Consulting und Delivery Teams in: Wien, Budapest, Zürich Vienna/Austria

3 Wie definieren wir Anforderungen? 3

4 Wofür verwenden wir User Stories? Benutzeranforderungen Priorisierungseinheit Planungseinheit Erinnerung an Diskussion Verzögerung einer Diskussion User stories are really the artifact at the heart of the continuing dialog between what is possible and what is desirable. ~ Kent Beck ( 4

5 Herzstück eines kontinuierlichen Dialogs Warum? Auswirkung, Ziel Deliverable, Ergebnis Ben.Aktivität Specification-By-Example Impact Mapping Epic Story Mapping User Story Akzeptanzkriterium Beispiel Code Erinnerung an eine Diskussion Isoliertes, formalisiertes Beispiel Fehlerreport Wie? Einfacher vorab festzulegen Schwieriger vorab festzulegen 5

6 Sammlung von Akzeptanzkriterien Als Power-Shopper will ich Bücher in einem Einkaufswagen sammeln weil ich mehrere Bücher auf einmal bestellen will. Stellen Sie sich vor, die Story ist bereits implementiert: was würden Sie ausprobieren? Ich würde ein Buch in den Einkaufswagen legen Ich würde ein Buch aus dem Einkaufswagen entfernen Ich würde prüfen, ob der Einkaufswagen leer ist, wenn ich den Shop betrete Ich würde versuchen, das gleiche Buch mehrmals in den Einkaufswagen zu legen Bücher sollen in den Einkaufswagen gelegt werden können. Bücher sollen aus dem Einkaufswagen entfernt werden können. Der Einkaufswagen soll leer sein, wenn der Shop geöffnet wird. Das gleiche Buch soll mehrmals dem Einkaufswagen hinzugefügt werden können. 6

7 Wofür brauchen wir Beispiele? 7

8 Beispiele für User Stories UI Wireframes, bestehendes UI Regeln, Schlüsselbeispiele Bestehende Artefakte, Mockups 8

9 Besprechung von Akzeptanzkriterien Wir wollen neue Benutzer zu einer Bestellung in unserem Shop animieren. Daher bieten wir 10% Rabatt für die erste Bestellung. public void TestInitialOrderDiscount() { Customer newcustomer = new Customer(); Order neworder = new Order(newCustomer); neworder.addbook( Catalog.Find( ISBN ) ); Assert.Equals(33.75, neworder.subtotal); } Register as bart_bookworm Go to /catalog/search Enter ISBN Click Search Click Add to Cart Click View Cart Verify Subtotal is $ Original idea for the illustration: George Dinwiddie

10 Specification-by-Example Beispiele Machen abstrakte Beschreibungen besser verständlich Jedoch Beispiele werden nicht formal ausgetauscht oder dokumentiert Brian Marick Beispiele beschreiben bestehen aus Anforderungen Tests überprüfen die Erfüllung von 10

11 Besprechung von Akzeptanzkriterien Wir wollen neue Benutzer zu einer Bestellung in unserem Shop animieren. Daher bieten wir 10% Rabatt für die erste Bestellung. public void TestInitialOrderDiscount() { Customer newcustomer = new Customer(); Order neworder = new Order(newCustomer); neworder.addbook( Catalog.Find( ISBN ) ); Assert.Equals(33.75, neworder.subtotal); } Register as bart_bookworm Go to /catalog/search Enter ISBN Click Search Click Add to Cart Click View Cart Verify Subtotal is $ Original idea for the illustration: George Dinwiddie

12 illustriert mit formalisierten Beispielen Angenommen der Benutzer hat noch keine Bestellung Wenn der Benutzer ein Buch zum Preis von EUR 37,50 in den Einkaufwagen legt 12 Dann zeigt der Einkaufswagen eine Zwischensumme von EUR 33,75. Original idea for the illustration: George Dinwiddie

13 Entdeckung versteckter Annahmen Eigentlich stimmt das nicht ganz: Bücher im Sonderangebot sind vom Rabatt ausgenommen. 13 Original idea for the illustration: George Dinwiddie

14 Zusammenarbeit: 3 Amigos Happy Path Technische Machbarkeit Ausnahmen, Extremfälle 14 Original idea for the illustration: George Dinwiddie

15 Abstrakte Akzeptanzkriterien Als Power-Shopper will ich Bücher in einem Einkaufswagen sammeln weil ich mehrere Bücher auf einmal bestellen will. Bücher sollen in den Einkaufswagen gelegt werden können. Bücher sollen aus dem Einkaufswagen entfernt werden können. Der Einkaufswagen soll leer sein, wenn der Shop geöffnet wird. Das gleiche Buch soll mehrmals dem Einkaufswagen hinzugefügt werden können. 15

16 Beispiele für Akzeptanzkriterien Als Power-Shopper will ich Bücher in einem Einkaufswagen sammeln weil ich mehrere Bücher auf einmal bestellen will. Bücher sollen in den Einkaufswagen gelegt werden können. Angenommen der Einkaufswagen ist leer Wenn ich das Buch Harry Potter in den Einkaufswagen lege Dann enthält der Einkaufswagen 1 Exemplar von Harry Potter 16

17 Beispiele für Akzeptanzkriterien Als Power-Shopper will ich Bücher in einem Einkaufswagen sammeln weil ich mehrere Bücher auf einmal bestellen will. Bücher sollen in den Einkaufswagen gelegt werden können. Das gleiche Buch soll mehrmals dem Einkaufswagen hinzugefügt werden können. Angenommen der Einkaufswagen enthält 1 Exemplar von Harry Potter Wenn ich das Buch Harry Potter in den Einkaufswagen lege Dann enthält der Einkaufswagen 2 Exemplare von Harry Potter 17

18 Struktur der Beispielszenarien Titel: Beschreibt Intention/abstraktes Akzeptanzkriterium Arrange: Kontext, initialer Zustand des Systems Act: Ausführung des Features Assert: Überprüfung von Verhalten/Ergebnis Das gleiche Buch soll mehrmals dem Einkaufswagen hinzugefügt werden können. Angenommen der Einkaufswagen enthält 1 Exemplar von Harry Potter Wenn ich das Buch Harry Potter in den Einkaufswagen lege Dann enthält der Einkaufswagen 2 Exemplare von Harry Potter Und die Warnung Buch bereits im Einkaufswagen wird angezeigt Triple-A constraint Checks Verkettung von Schritten 18

19 Wie lange brauchen wir die Beispiele? 19

20 Zweck der Beispiele Gemeinsames Verständnis: Akzeptanzkriterien Dokumentation: Referenz für Detail- aspekte des Systems Regressionstests: Klarheit, welche Annahmen verletzt wurden 20

21 Kontinuierliche Validierung durch Automatisierung Step Definitions binden individuelle Schritte an automatisierbare Schnittstelle der Applikation. Automatisierung muss nicht über das UI erfolgen. Automatisierbarkeit des Systems entsteht und erweitert sich mit Entwicklung. Angenommen der Einkaufswagen enthält 1 Exemplar von Harry Potter Wenn ich das Buch Harry Potter in den Einkaufswagen lege Dann enthält der Einkaufswagen 2 Exemplare von Harry Potter UI Automatisierung System Automatisierbare Schnittstelle 21

22 Demo Gherkin Automatisierung für.net Visual Studio plugin (VS-Gallery) NuGet Package 22

23 Was bedeutet das für Testen? 23

24 Testautomatisierung wird teuer wenn Manuelle Tests automatisiert werden Tests durch Automatisierung unlesbar werden Automatisierung nach der Entwicklung erfolgt Struktur Lesbarkeit Zeitpunkt 24

25 Struktur Asserts Struktur Manueller Test Mehrere Features in Kombination ACT-ASSERT- ACT-ASSERT- ACT-ASSERT- Abhänging von anderen Features Langer Testpfad mit hoher Anfälligkeit zu brechen Automatischer Check Einzelner Aspekt eines einzelnen Features ARRANGE ACT ASSERT Unabhängig von anderen Features Kurzer Testpfad mit geringer Anfälligkeit zu brechen 25

26 Automatisierbarkeit Testautomatisierungspyramide wenige Exploratives Testen schwieriger User journeys Akzeptanzkriterien/ Beispielszenarien Units viele leichter 26 Source: Mike Cohn

27 Lesbarkeit // Go to web page ' using new browser instance BrowserWindow localhostbrowser = BrowserWindow.Launch( new System.Uri(this.RecordedMethod1Params.Url)); // Click 'Register found item' link Mouse.Click(uIFundstückerfassenHyperlink, new Point(56, 9)); // Click 'Save' button Mouse.Click(uISpeichernButton, new Point(44, 14)); int fundnr1 = int.parse(uifundnr127pane.innertext.substring(9)); // Click 'Register found item' link Mouse.Click(uIFundstückerfassenHyperlink, new Point(63, 7)); // Click 'Save' button Mouse.Click(uISpeichernButton, new Point(34, 11)); int fundnr2 = int.parse(uifundnr128pane.innertext.substring(9)); Assert.IsTrue(fundNr1 + 1 == fundnr2); // Click 'Close' button Mouse.Click(uICloseButton, new Point(26, 11)); 27

28 Ein Lesbarer Testfall Szenario: Neue Fundstücke sollen eine fortlaufende Nummer im aktuellen Jahr erhalten Angenommen das letzte Fundstück im aktuellen Jahr hat die Nummer 145 Wenn ich ein neues Fundstück registriere Dann soll das letzte Fundstück im aktuellen Jahr die Nummer 146 haben 28

29 Definition des Produkts Zeitpunkt des Tests fachliche Sicht Acceptance criteria (ATDD, BDD) Unit Tests (TDD) technische Sicht Exploratory tests Workflow tests Performance, Scalability, Usability,Security, Agile Testing Quadrants: Brian Marick Kritik am Produkt Neue Dimension: Definition des Produkts Synergie: Spezifikation von Anforderungen und Tests 29

30 Cross-funktionale Teams Co-creation Schnelles Feedback 30

31 Cross-funktionale Arbeit Limitierung WIP US1 Plan Zusammenarbeit Definition von Akzeptanzkriterien Erweiterung Testfälle Zusammenarbeit Automatisierung Zusammenarbeit im manuellen Test Implement & autom. test US2 US3 Plan Plan Implement & autom. test Implement & autom. test Exploratives Testen US4 US5 Plan Plan US6 Implement Plan & autom. Implement test & autom. Implement test & autom. test Spezifikation und Test US7 US8 Plan Plan US9 Implement Plan & autom. Implement test & autom. test Implement & autom. test Sprint 1 Sprint 2 Sprint 3 Kurze Iteration Vermeidung von Fehlern anstatt Fehler zu finden! 31

32 Automatisierbarkeit Manuelle Tests sind immer notwendig! Unentdeckte Akzeptanzkriterien Hauptpfade durch Applikation Manueller Check wenn Story implementiert wenige Exploratives Testen User journeys Akzeptanzkriterien/ Beispielszenarien Mehr Zeit für Erforschung Wenige Pfade sind ausreichend Keine/(wenige) manuelle Regressionschecks schwerer Units viele einfacher 32 Source: Mike Cohn

33 Was bedeutet das für die Entwicklung? 33

34 Workflow: TDD 34

35 Erweiterung von TDD für Business 35

36 Transparenz für alle Beteiligten In Progress 36

37 37 Current Sprint Report: Alle Szenarios d. Sprints

38 38 Beginn mit dem ersten Szenario

39 39 Fertigstellung erstes Szenario

40 40 Fortschritt Szenario für Szenario

43 43 Parallele Implementierung von Stories

44 44 Erste User Story bereit zum Test

45 45 Manueller Test ist bereits früher möglich

46 46 Fertige Arbeit kann wieder brechen

47 47 Fertige Arbeit kann wieder brechen

48 48 Klarheit, was nicht funktioniert

49 Lebende Dokumentation 50

50 Optimierung des Umfangs Warum? Auswirkung, Ziel Deliverable, Ergebnis Story Mapping Ben.Aktivität Epic User Story Wie? Einfacher vorab festzulegen Akzeptanzkriterium Beispiel Code Schwieriger vorab festzulegen 51

51 Story Maps Konzept von Jeff Patton Unterstützt beim iterativem Produktdesign Optimiert für gewünschtes Ergebnis oder Deliverable, das vom System unterstützt werden soll 52

52 Notwendigkeit Erstellung von Story Maps Populäre Bücher schnell und bequem geliefert bekommen Gewünschtes Ergebnis oder Deliverable Buch finden Bücher sammeln bestellen Warten auf Lieferung Lieferung empfangen Benutzeraktivitäten Zeit Bestseller d.stöbern Lieferschein Auslieferungsbenach -richtigung Einkaufskorb Adresseingabe Systemfeatures Suche nach Titel Merkliste Kreditkartenzahlung Bestellstatus 53

53 Notwendigkeit Build Measure Learn ermöglichen Populäre Bücher schnell und bequem geliefert bekommen Buch finden Bücher sammeln bestellen Warten auf Lieferung Lieferung empfangen Zeit Bestseller d.stöbern Manuelle Umgehung ausgelassene Schritte Adresseingabe Lieferschein Walking skeleton Suche nach Titel Kreditkartenzahlung Bestellstatus Merkliste Einkaufskorb Auslieferungsbenach -richtigung 54

54 Story Map Beispiel 55

55 Sprint 1 56

56 Sprint 2 57

57 Sprint 3 58

58 Sprint 4 59

59 Nicht implementierte Funktionalität 60

60 Zusätzliche Funktionalität 61

61 Demo Story Maps als Lebende Dokumentation 62

62 User Stories vs. Features Product/Sprint Backlog Lebende Dokumentation User Story 1 User Story 2 User Story n AccCrit 1 AccCrit 2 AccCrit 3 AccCrit 4 AccCrit 5 AccCrit m Done Feature 1 Feature n AccCrit 1 AccCrit 2 AccCrit 3 AccCrit 5 AccCrit 4 AccCrit m Zukünftige Optionen des Systems Organisiert/verfeinert nach Priorität, Nutzen, Aufwand, Risko,... Nächste mögliche Erweiterungen des Produkts (Arbeitspakete) Aktueller Zustand des Systems Organisiert/verfeinert nach funktionalen Überblick Versioniert und verwaltet gemeinsam mit Source Code 63

63 Lebende Dokumentation Fachlich lesbare automatisierte Tests aus Source Control in Story Maps verlinken Story Maps mit Ausführungsergebnisse anreichern 65

64 66 Tipps für die Praxis

65 Erstellung von Gherkin Szenarios Dokumentation einer Konversation Neue Fragen statt nur Spezifikation Unendlich viele Formulierungen und Beispiele Lesbarkeit und Automatisierbarkeit 67

66 Smells bei der Zusammenarbeit Silos und zu formelle Hand-Overs Ausarbeitung hinkt Umsetzung hinterher Szenarien ersetzen Kommunikation Szenarien behindern Lösungsfindung Szenarien verhindern neue Erkenntnisse Pflichtübung nach der Entwicklung Unlesbare Szenarien ohne Mehrwert Hoher Aufwand Erstellung und Wartung Technische Probleme bei der Automatisierung 68

67 Ebene der Automatisierung Out-of-process Browser automatisierung In-process View Verhalten auf Modell, DB, überprüfen Auslösung von Verhalten über Controller Model Controller Business Layer Setup des Zustands zu Szenariobeginn durch Schnittstellen Data Layer 69

68 Performance Gruppierung von Tests Aktueller WIP Fertiggestellte Features Datenbank In-memory Vorlagen für Setup Parallele Ausführung Intelligente Ausführungsreihenfolge 70

69 Interne vs. externe DSL Example Source: Liz Keogh scenarios/com/lunivore/tictactoe/scenarios/ Three_in_a_row_wins.java 71

70 Nicht funktionale Akzeptanzkriterien Given there are 100,000 users registered on the system When I create a new account Then I should be taken to my dashboard within 5ms Given 1000 users are hitting the homepage simultaneously Then each user should get a response within 2ms Matt Wynne 72