Testen in agilen Projekten, Swiss Testing Day Zürich 2013 Agile Projekte verursachen massive Probleme im klassischen Testvorgehen: Detailspezifikationen sind erst (wenn überhaupt) kurz vor der Implementierung verfügbar und der Test soll gleichzeitig mit der Entwicklung am Ende jeder Iteration abgeschlossen sein. Bei Iterationslängen von wenigen Wochen verursacht das beträchtlichen Mehraufwand für den Test, der sich noch dazu am Ende der Iteration konzentriert, wodurch das Ziel eines voll getesteten Systems am Ende jeder Iteration oft nicht erreicht werden kann. Der Vortrag stellt drei wichtige Erfolgsrezepte für Testen in agilen Projekten vor (1. Multifunktionale Teams, 2. Testautomatisierung und 3. Spezifikation mit Beispielen) und zeigt, welche Änderungen notwendig sind, damit Test und Entwicklung effizient in agilen Projekten zusammenarbeiten. Neben der Vorstellung von wichtigen Konzepten für agiles Testen (agile Testquadranten, Testautomatisierungspyramide und Specification-By-Example) zeigt der Vortrag auch, wie diese Methoden mit Werkzeugen unterstützt werden können, und berichtet von deren praktischer Anwendung in unterschiedlichen Projekten. Video: http://www.youtube.com/watch?v=LL2kOToKUF0

1. Testen in agilen Projekten
Wettlauf mit Entwicklung oder
gemeinsames Ziel?
CHRISTIAN HASSA, TECHTALK
CH@TECHTALK.CH, @CHRISHASSA
Swiss Testing Day Zürich, 13. März 2013
COPYRIGHT, TECHTALK - WWW.TECHTALK.CH

2. TechTalk auf einen Blick
• Agile Software Entwicklung
• Beratung und Umsetzung (Nearshoring)
• Standorte: Zürich, Wien, Budapest
• Ca. 50 Mitarbeiter
• Gegründet: 1993
TechTalk office, Vienna/Austria
COPYRIGHT, TECHTALK - WWW.TECHTALK.CH

3. Herausforderungen
• Was tun zu Projekt- und Sprintbeginn?
• Wann wird das Sprintergebnis getestet?
• Regressionstests?
4

4. Erfolgsrezepte
• Cross-funktionale Teams
• Testautomatisierung
• Spezifikation mit Beispielen
5 5

5. Cross-funktionale Teams
Mix aus Rollen
Schnelles Feedback COPYRIGHT, TECHTALK - WWW.TECHTALK.CH

6. Wasserfall im Sprint
Planung Planung Planung
Analyse Analyse Analyse …
Design Design Design
Implement. Implement. Implement.
Test Test Test
Konflikt
Deploy Deploy Deploy
Sprint 1 Sprint 2 Sprint 3
Die “eigentliche” Iterationsdauer
7

7. Cross-funktionale Arbeit
Limitierung Erweiterung
Mitwirkung Definition Zusammenarbeit
WIP “Test Cases” +
Akzeptanzkriterien Automatisierung
US1 Ziele Explor. Test
Plan
Implement & US4 US7
Exploratory Test
autom. test US5 US8
gemein- Plan Plan
US6
Plan US9
Plan
same Implement &
Plan Implement &
Plan
US2 Implement & Implement &
manuelle US3 autom. test autom. test
Testaus- Plan autom. test &
Implement autom. test &
Implement
Plan autom. test
führung Implement & autom. test
autom. test &
Implement
autom. test Spezifikation und Test
Sprint 1 Sprint 2 Sprint 3
Kurze Iteration Retrospektive: Fehler vermeiden anstatt
Optimierung nur Fehler zu finden!
Zusammenarbeit
8

8. Regression
If something
hurts, Test-
do it
auto-
more matisierung
often!
(frequency reduces difficulty)
9

9. Testautomatisierung wird teuer,
wenn …
• man versucht,
manuelle Tests zu Struktur
automatisieren
• Tests durch die
Automatisierung Lesbarkeit
unlesbar werden
• man nach Abschluss
der Entwicklung Zeitpunkt
automatisiert
10

10. Struktur
Manueller Test Automat. Check
Überprüft Mehrere Features Isolierter Aspekt
in Kombination eines Features
Struktur ACT-ASSERT- ARRANGE –
ACT-ASSERT- ACT –
ACT-ASSERT- ASSERT
…
Abhängige Features Unabhängige Features
Langer Testpfad: Kurzer Testpfad:
änderungsanfällig robust f. Änderungen
Ursache/Wirkung Ursache/Wirkung
schwer zu korrelieren leichter zu korrelieren
11

11. Testautomatisierungspyramide
wenige
Exploratives schwieriger
Testen
Automatisierbarkeit
User-
journeys
Akzeptanz-
kriterien
Units
einfacher
viele
12
nach Mike Cohn

12. Lesbarkeit
// Go to web page 'http://localhost:40001/' 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));
13

13. Ein lesbarer Testfall
Szenario: Ein neues Fundstück bekommt die
nächste Fundnummer des laufenden Jahres
Angenommen das letzte Fundstück des
laufenden Jahres hatte die Fundnummer 145
Wenn ich ein neues Fundstück erfasse
Dann hat das letzte Fundstück des laufenden
Jahres die Fundnummer 146
14

14. Zeitpunkt des Tests
Anwendersicht
Definition des Produkts
Kritik am Produkt
Akzeptanzkriterien Explorative Tests
(ATDD, BDD) Workflow Tests
Unit Tests Performance, Skalierbarkeit,
(TDD) Sicherheit, …
Technische Sicht
Agile Testing Quadrants, Brian Marick
Neue Dimension: Definition des Produkts!
Synergie: Spezifikation für Anforderungen und Test!
15

15. Besprechung von Akzeptanzkriterien …
Wir wollen neue Benutzer ermutigen, etwas
zu bestellen.
Daher bieten wir 10% Rabatt für die erste
Bestellung eines Kunden an.
public void TestInitialOrderDiscount() Register as “bart_bookworm”
{ Go to “/catalog/search”
Customer newCustomer = new Customer(); Enter “ISBN-0955683610”
Order newOrder = new Order(newCustomer); Click “Search”
newOrder.AddBook(
Catalog.Find(“ISBN-0955683610”)
Click “Add to Cart”
); Click “View Cart”
Assert.Equals(33.75, Verify “Subtotal” is “$33.75”
newOrder.Subtotal);
}
Originalidee Illustration: George Dinwiddie
http://blog.gdinwiddie.com
18

16. Spezifikation mit Beispielen
Beispiele …
• machen abstrakte
Beschreibungen besser
verständlich
• werden normalerweise nicht
formalisiert ausgetauscht/ dokumentiert Brian Marick
bestehen aus
Beispiele Tests
beschreiben verifizieren
Erfüllung von
Anforderungen
19

17. Besprechung von Akzeptanzkriterien …
Wir wollen neue Benutzer ermutigen, etwas
zu bestellen.
Daher bieten wir 10% Rabatt für die erste
Bestellung eines Kunden an.
public void TestInitialOrderDiscount() Register as “bart_bookworm”
{ Go to “/catalog/search”
Customer newCustomer = new Customer(); Enter “ISBN-0955683610”
Order newOrder = new Order(newCustomer); Click “Search”
newOrder.AddBook(
Catalog.Find(“ISBN-0955683610”)
Click “Add to Cart”
); Click “View Cart”
Assert.Equals(33.75, Verify “Subtotal” is “$33.75”
newOrder.Subtotal);
}
Originalidee Illustration: George Dinwiddie
http://blog.gdinwiddie.com
20

18. … 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
Dann zeigt der Einkaufswagen eine Zwischensumme von
EUR 33,75.
Originalidee Illustration: George Dinwiddie
http://blog.gdinwiddie.com
21

19. Aufdeckung impliziter Erwartungen
Eigentlich stimmt das nicht ganz:
Bücher im Angebot sollen davon
ausgenommen werden.
Originalidee Illustration: George Dinwiddie
http://blog.gdinwiddie.com
22

20. Zusammenarbeit: 3 Amigos
Ausnahmen,
“Happy Technische Grenzfälle
Path” Machbarkeit
Originalidee Illustration: George Dinwiddie
http://blog.gdinwiddie.com
23

21. Abstrakte Akzeptanzkriterien
Als Webshop Besucher
will ich Bücher in einen Warenkorb legen
weil ich mehrere Bücher auf einmal bezahlen können will.
Bücher können dem Warenkorb hinzugefügt werden
Bücher können aus dem Warenkorb entfernt werden
Der Warenkorb ist zu Beginn leer
Das gleiche Buch kann mehrmals hinzugefügt werden
24

22. Beispiele für Akzeptanzkriterien
Als Webshop Besucher
will ich Bücher in einen Warenkorb legen
weil ich mehrere Bücher auf einmal bezahlen können will.
Bücher können dem Warenkorb hinzugefügt werden
Angenommen ich habe einen leeren Warenkorb
Wenn ich das Buch “Harry Potter” in den Warenkorb lege
Dann sollte mein Warenkorb 1 Exemplar von “Harry Potter” enthalten
25

23. Beispiele für Akzeptanzkriterien
Als Webshop Besucher
will ich Bücher in einen Warenkorb legen
weil ich mehrere Bücher auf einmal bezahlen können will.
Bücher können dem Warenkorb hinzugefügt werden
Das gleiche Buch kann mehrmals hinzugefügt werden
Angenommen mein Warenkorb enthält 1 Exemplar von “Harry Potter”
Wenn ich das Buch “Harry Potter” in den Warenkorb lege
Dann soll mein Warenkorb 2 Exemplare von “Harry Potter” enthalten
26

24. Struktur der Beispiele
Titel: Beschreibt Intention/abstraktes Akzeptanzkriterium
Arrange: Kontext, Zustand des Systems vor Ausführung Triple-A
Act: Ausführung des Features constraint
“Checks”
Assert: Prüfung beobachtbares Verhalten
Das gleiche Buch kann mehrmals hinzugefügt werden
Angenommen mein Warenkorb enthält 1 Exemplar von “Harry Potter”
Wenn ich das Buch “Harry Potter” in den Warenkorb lege
Dann soll mein Warenkorb 2 Exemplare von “Harry Potter” enthalten
Und eine Warnung wird ausgegeben: “Gleiches Buch hinzugefügt”
Verkettung
von
Schritten
27

25. Fachlich lesbare Automatisierung
„Step Definitions“ binden einzelne Schritte
an eine automatisierbare Schnittstelle der Applikation
Automatisierung muss nicht unbedingt über das UI erfolgen.
Unterstützung der Automatisierbarkeit mit der Entwicklung.
Angenommen mein Warenkorb enthält 1 Exemplar von “Harry Potter”
Wenn ich das Buch “Harry Potter” in den Warenkorb lege
Dann sollte mein Warenkorb 2 Exemplare von “Harry Potter” enthalten
UI
System
Automatisierung
Automatisierbare
Schnittstelle
28

26. Manuelles Testen ist immer notwendig!
wenige
Nicht entdeckte
Akzeptanzkriterien Mehr Zeit für
Exploratives Exploration schwieriger
Testen
Hauptpfade
durch Applikation Wenige Pfade
Automatisierbarkeit
User sind ausreichen
journeys
Manuelle
Keine/(wenige)
Prüfung
manuelle
wenn Akzeptanz- Regressions-
User Story
Done kriterien checks
Units
einfacher
viele
29
Source: Mike Cohn

27. Fallbeispiel: Aufwand vs. Nutzen
• Individualentwicklung: Finanzdienstleistungsbereich
• Testaufwand klassisches Vorgehen: 15% des Gesamtaufwands
• Einführung agiles Vorgehen: Auswirkung auf Anteil Testaufwand
Projekt Gesamtaufwand Testaufwand
Projekt in PT Anteil
Agiles Projekt mit ~200 35%
manuellen Test
Agiles Projekt ~600 19%
mit
Testautomatisierung
30

28. Exploratives Testen
Lernen
Design Ausführung Entdeckung
Simultan in einer time-boxed Sitzung
• Ziel: Entdeckung von impliziten Annahmen,
neue Akzeptanzkriterien, unerwartetes Verhalten
• Testcharta mit priorisierten Zieldefinitionen
für unterschiedliche Explorative Testing Sitzungen
31

29. Beispiel: ET-Sitzungsdefinitionen
Bereich der Applikation:
Feature, Modul, Workflow, ...
Ressourcen:
Werkzeug, Konfiguration, Datensets,
Technik, abhängiges Feature, …
Explorationsziel:
Inkonsistenzen, Unsicherheiten,
Risiken
Verletzung von: spezifizierten ACs,
Geschäftsregeln,
“Menschenverstand”,
Nicht-funktionale Anforderungen,
Cross-Cutting Concerns, …
32 Quelle Template: Elisabeth Hendrickson

30. Nie wieder Bugs? Quellen für mögliche
Explorationsziele
manuelle
Unerwartetes Exploration
Risikoanalyse
Fehlverhalten Source Code
Neue Annahmen aufgrund Eindrücke aus Team
der Planung Kommunikation
des Ergebnisses
Root Cause Analyse
Vergessene implizite von Bugs
Annahmen Cross-cutting Nicht funktionale
Concerns Anforderungen
Vergessene dokumentierte
Annahmen Definition of Done
Verletzte dokumentierte
automatische
Annahmen Regression
33

31. Werkzeuge
Exploratives
Testen
Test Manager 2010
Virtual Lab Management
CodedUI
User-
journeys Fachlich lesbare Test:
.NET, Java, Ruby, JavaScript, PHP, C++
Akzeptanz-
kriterien
CodedUI, Selenium, …
MS-Test, NUnit, …
Units
35

32. Literatur
Elisabeth Hendrickson Gojko Adzic Lisa Crispin
Explore IT! Specification by Janet Gregory
Example Agile Testing
38

33. Erfolgsrezepte Zusammenfassung
• Crossfunktionale Teams
• Mix aus Rollen: schnelles Feedback und Fehlerbehebung
• Gemeinsames Ziel: Fertig getestetes Produkt am Sprintende
• Exploratives Testen: Testcharta mit priorisierten Zielen
• Testautomatisierung (Struktur, Lesbarkeit, Zeitpunkt)
• Verringerung der Regressionskosten
• Automatisierbarkeit unterstützt manuelles Testen, Entwicklung
und Design der Applikation
• Richtiger Mix aus manuellen und automatisierten Tests
• Spezifikation mit Beispielen
• Spezifikationstechnik für gemeinsames Verständnis der Details
• Fachlich lesbare Tests als Spezifikation
• „Lebende Dokumentation“ des Systems
39

34. Nutzen Sie die Chancen
agiler Testmethodik!
KONTAKT UND FRAGEN
Christian Hassa
christian.hassa@techtalk.ch
@chrishassa
COPYRIGHT, TECHTALK - WWW.TECHTALK.CH