Agiles Testen (z.B. in Scrum, Kanban, XP) ist zu einem unverzichtbaren Bestandteil agiler Softwareentwicklung geworden.
Testen in agilen Entwicklungsprojekten unterscheidet sich vom klassischen Testen in erster Linie dadurch, dass Testen eine präventive Maßnahme ist und dass die Tests viel häufiger ausgeführt werden müssen. Der Fokus liegt dabei in der Einbindung von Testern unter Beachtung des agilen Manifests und der Anwendung agiler Prinzipien auf das Testen, wie beispielsweise schnelles Feedback, hoher Automatisierungsgrad, Auflösung starrer Teststufen, enge Zusammenarbeit in selbstorganisierten Teams.
Inhalt
- Definition
- Agiles Testen im Team
- Testkategorien
- Unit-Tests
- TDD/ATDD/BDD
- 3 Amigo
- Akzeptanztests
- Exploratives Testen
- Continuous Integration, Delivery & Deployment
- Integration in Scrum
- Genereller Umgang mit Bugs
2. Agiles Testen Definition
Agiles Testen (z.B. in Scrum, Kanban, XP) ist zu einem unverzichtbaren Bestandteil agiler
Softwareentwicklung geworden.
Testen in agilen Entwicklungsprojekten unterscheidet sich vom klassischen Testen in erster
Linie dadurch, dass Testen eine präventive Maßnahme ist und dass die Tests viel häufiger
ausgeführt werden müssen.
Der Fokus liegt dabei in der Einbindung von Testern unter Beachtung des agilen Manifests
und der Anwendung agiler Prinzipien auf das Testen, wie schnelles Feedback, hoher
Automatisierungsgrad, Auflösung starrer Teststufen, enge Zusammenarbeit in selbst
organisierten Teams und Vermeidung von Overhead.
3. Agiles Testen im Team
Agiles Testen ist die Integration von Qualität sichernder Maßnahmen in den agilen Entwicklungsprozess
Testsicht bereits in der Vorbereitung beachten und durchgängig beibehalten
Verteilt auf alle Rollen (bis hin zu einem 3-Amigo Prozess):
o Entwickler: Testgetrieben vorgehen, Unit Tests, Komponententests, FIT-Automatisierung
o Fachexperte (PO,BA): Abnahme- und Akzeptanztests erstellen und durchführen
o Tester / UI: Persona, Szenarien, Testfälle und Integrationstests erstellen und durchführen, FIT-
Automatisierung, UI-Testautomatisierung der Regressionstests
Treiber für die interne Prozessverbesserung.
Agiles Testen basiert auf einem ganzheitlichen Team-Ansatz
4. Profil des agilen Testers
Der Tester bringt während des gesamten Projektablaufs die Testsicht in das agile Team ein.
Der Tester schärft die Anforderungen über Persona und Szenarien bzw. Story Maps. Dabei wird
besonders auf die nicht-funktionalen Anforderungen fokussiert.
Der Tester unterstützt
o Entwickler methodisch bei den Unit-Tests und bei der fachlichen Architektur durch entsprechenden
fachlichen Strukturen in den Tests
o Fachexperte (PO, BA) bei der fachlichen Priorisierung und Abnahme der Iterationsergebnisse
Der Tester führt die Integrationstests und die entsprechenden Regressionstests durch und sorgt so
von Anfang an für Produktqualität.
5. Ganzheitliches Agiles Team
Entwickler erstellen testgetriebene Software
Product Owner moderiert, organisiert und definiert
die Prioritäten
Entwickler, Tester und Fachexperten diskutieren
gemeinsam die Anforderungen.
Tester führen aussagekräftige, testmethodische
Prüfungen durch.
Ergebnis:
Tests erfolgen auf allen Ebenen früh und oft
Am Beispiel der Scrum Rollen:
7. Unit-Tests
Unit-Test (auch Komponenten- oder Modultest genannt) überprüfen, ob die von den Entwicklern
geschriebenen Komponenten so arbeiten, wie diese es beabsichtigen.
In der agilen Softwareentwicklung wird im Rahmen der testgetriebenen Entwicklung und des
Refactorings massiver Gebrauch von Komponententests gemacht.
o Zum Zeitpunkt ihrer Erstellung dienen Unit-Tests im Rahmen der testgetriebenen Entwicklung dazu, das Design der
Software zu steuern, als Defekte zu finden.
o Im Rahmen des inkrementellen Entwurfs sind sie unverzichtbar, um auch langfristig änderbaren Code zu behalten.
o Auch wenn ein bestehendes System um neue Features erweitert werden, helfen Unit-Tests: So decken sie
unbeabsichtigte Fernwirkungen der neuen Funktionen auf bereits bestehende Systemteile auf.
o Darüber hinaus helfen sie auch, das System zu dokumentieren, indem sie beabsichtigte Verwendungen und
Reaktionen des Testobjekts deutlich aufzeigen.
8. Unit-Tests
Was zeichnet einen guten Unit Test aus?
… sind isoliert d.h. unabhängig voneinander, so dass die Reihenfolge ihrer Ausführung das
Testergebnis nicht beeinflusst. Schlägt ein Test fehl, so führt dies nicht dazu, das weitere Tests
fehlschlagen
… sichern jeweils genau eine Eigenschaft ab. Ein Problem äußert sich immer in genau einem
fehlgeschlagenen Test.
… sie sind vollständig automatisiert, damit sie immer wieder ausgeführt werden können
… sind leicht verständlich und kurz.
… weisen eine genauso hohe Codequalität auf, wie der Produktivcode selbst
… testen relevanten Code (und beispielsweise keine Getter/Setter)
… sind um eine Test fixture gruppiert, nicht um eine Klasse
… werden vor dem zu testenden Code geschrieben (testgetriebene Entwicklung)
9. Testgetriebene Entwicklung (TDD)
Test First Prinzip
Erfolgt in Verbindung mit Unit-Tests, Systemtests oder Akzeptanztests
Zyklischer Ablauf:
• Ein Test wird geschrieben, der zunächst fehlschlägt
• Es wird immer nur genau soviel Produktivcode implementiert bis der Test erfolgreich durchläuft
• Test- und Produktivcode werden „aufgeräumt“
Einfache Metrik: Tests werden bestanden oder nicht
Einfache Fehlerlokalisierung
Ausführbare Spezifikation: Unit-Tests beschreiben gleichzeitig, was das System leisten soll.
10. Testgetriebene Entwicklung (TDD)
Rot: Entwickler erstellt zuerst den Test
(Greybox-Tests) für das bestimmte
erwünschte Verhalten einer Unit, für
bekannte Fehler oder eine neue
Teilfunktionalität.
Der ausgeführte Test wird zunächst
vom bestehenden Programmcode noch
nicht erfüllt, da es diesen noch gar nicht
gibt.
Grün: Anschließend schreibt/ändert der Entwickler den
Code mit möglichst geringen Aufwand so lange, bis mit den
nächsten Testdurchläufen alle Tests erfolgreich
durchlaufen sind
Blau: Nun erfolgt das Refactoring, d.h. der Code wird
„aufgeräumt“. Überflüssiger Code wird entfernt oder
nach verbindlichen Code-Konventionen ausgerichtet.
11. Testgetriebene Entwicklung (TDD)
Vorteile
Wartbare Qualitätssoftware
• Kein ungetester Code
• Saubere/testbare Architektur durch TDD als Designstrategie
• Wenig bis keine Redundanzen durch gnadenloses rechtzeitiges Refaktorisieren
Effektive und effiziente Erstellung der Software
• Kein unnötiger Code auf Vorrat
• Konzentration auf das Wesentliche
13. Akzeptanztests
Mit Hilfe von Akzeptanztests werden die Systemfunktionalitäten aus Sicht der Benutzer überprüft.
Agile Teams halten in Form von automatisierten Akzeptanztests ihr Verständnis über die
Anwendungsdomäne fest.
Das Team erlangt zusammen mit dem Product Owner ein gemeinsames Verständnis über die
Anwendungsdomäne und hälft diese in Form von Akzeptanzkriterien fest.
Diese werden parallel zur Entwicklung der Funktionalität automatisiert.
Über lange Sicht entsteht so eine ausführbare Dokumentation des Systems.
14. Acceptance-Test-Driven Development (ATDD)
Kommunikationswerkzeug zwischen Anwender bzw. Kunde, Entwickler und Tester.
ATDD soll sicherstellen, das Anforderungen gut beschrieben sind und sollen für Nicht-
Entwickler lesbar und verständlich sein.
Häufig werden testgetriebene Tests von den akzeptanzgetriebenen Tests abgeleitet.
1. Wähle eine User Story aus
2. Schreibe den Akzeptanztest
3. Implementiere die User Story
4. Führe Akzeptanztest aus
5. Refactoring
Ablauf:
15. Behaviour-Driven Development (BDD)
Behavior-Driven Development versucht die Prinzipien von Domain-Driven Design mit denen von Test-
Driven Development zu vereinen.
Domain-Driven-Design (DDD)
o Konzentration auf Fachlogik anstatt Technik
o Komplexe fachliche Zusammenhänge zerteilen
o vereinfachte Problemlösung
o Entwickler sehen nur Teilbereich
Test-Driven-Development (TDD)
o Konzentration auf das Problem
o Frühe Designentscheidungen
o Abstrakte Serviceschichten
16. Behaviour-Driven Development (BDD)
Ergänzt TDD und ATDD durch Synthese und
Verfeinerung, indem eine strukturierte Sprache den
Businessprozess vorgibt
Es steht die ausdrucksstarke Beschreibung von
Anforderungen und deren Akzeptanzkriterien im
Vordergrund.
Akzeptanzkriterien sollten automatisiert überprüft
werden können. (Ausführbare Spezifikation)
Beispiele Tools:
Cucumber, RSpec (Ruby), behat (PHP), Jbehave (Java)
Agile
Projektmanagement
(Scrum, Kanban)
Agile Requirement
Analysis
(User Story, Acceptance
Criteria)
Agile Testing
(bug prevention, exploratory
testing, context-driven)
Agile Engineering
(XP, TDD,Pair Programming)
BDD
17. Behaviour-Driven Development (BDD)
Vorteile
Einheitliche Sprache für Anforderungen (wird von allen verstanden)
Klare Fokussierung auf Nutzen sowie Test First ausgehend vom Akzeptanzkriterium
Erfüllung von Anforderungen wird automatisch auf Basis der Akzeptanzkriterien getestet
Fortschritt ist für alle einsehbar
18. Behaviour-Driven Development (BDD)
Prinzipien
Wende für jede User Story das 5-Why‘s Prinzip an, so dass der Zweck zu einem eindeutigen
Bezug der Geschäftsergebnisse erhält.
Denke von außen nach innen, d.h. Implementiere zunächst die Verhaltensweisen, die direkt
etwas zu den Geschäftsergebnissen beitragen und minimiere Waste.
Beschreibe die Verhaltensweise an zentraler Stelle, damit die unterschiedlichen Domänen
Experten, Tester und Entwickler direkt zugänglich ist und verbessere die Kommunikation
Übernehme diese Techniken den ganzen Weg hinunter bis zu den tiefsten Ebenen der
Abstraktion der Software, wobei ein besonderes Augenmerk auf der Verteilung des Verhaltens
liegen soll.
19. Behaviour-Driven Development (BDD)
Gherkin
Domain-Specific Language (DSL), leicht für jeden zu Lesen
In sogenannten *.feature-Files werden durch verschiedene Szenarios das Feature beschrieben
Es wird das Format von ATDD verwendet
Given (setup): A specified state of a system
When (trigger): An action or event occurs
Then (verification): The state of the system has changed or an output has been produced
21. 3 Amigo
Ziel ist es, ein gemeinsames Verständnis und gemeinsames Vokabular für ein Feature innerhalb den 3
Rollen (BA, Entwickler und QA) zu erhalten.
In der 3 Amigo-Sitzung stellt zuerst der Business Analyst (BA) die Anforderungen und Tests
(geschrieben mit Gherkin) für das neues Feature vor.
Anschließend diskutieren die drei Amigos (BA, Entwickler und QA) zusammen das neue Feature
anhand der Informationen und überprüfen die (ausführbare) Spezifikation.
Der Tester (QA) und der Entwickler beurteilen abschließend, ob das Feature bereits für die
Entwicklung eingeplant werden kann und identifizieren ggf. die fehlende Anforderungen / Randfälle.
Das 3 Amigo Gedanke kann auch sehr gut in das Backlog Grooming integriert werden.
22. Exploratives Testen
Exploratives Testen ist das gleichzeitige Lernen, Entwerfen und Durchführen von Test
Informelle Testtechnik & Simultanes Lernen: Tester kontrolliert das Testdesign während der
Testausführung. Jede neugewonnene Information wird wiederverwendet um einen besseren Test zu
designen.
Merkmale von Testdesign und Testdurchführung beim explorativen Test:
o Time-Boxing: Test-Sessions mit fixer Dauer
o Charter: Schriftliche Mission für den Tester
o Simultanes Testdesign und Testausführung
o Einsatz von Heuristiken
23. Exploratives Testen
Risikoorientiert anstelle spezifikationsorientiert, indem aktiv die Fehlersituationen gesucht werden, die
bisher noch mit keinen Testfall abgedeckt sind, um möglichst das gesamte Spektrum der Software
abzudecken.
Verwendung von Heuristiken bzw. Touring Modelle, um verschiedene Sichtweise und Strukturen beim
Testen zu erhalten.
FCC CUTS VIDS Touring Heuristik steht für
o Features,
o Complexity,
o Claims,
o Configuration,
o User,
o Testability,
o Scenario,
o Variability,
o Interoperability,
o Data und
o Structure
24. Exploratives Testen
Beispiele Touring Modelle
o Back-alley Tour: Alle Features testen, die der Anwender nicht tagtäglich benutzt.
o Landmark Tour: Die einzelnen Feature (Sehenswürdigkeiten) werden in allen möglichen
Kombinationen durchgetestet.
o Money Tour: Alle Features die intensiv beworben werden oder dem Kaufgrund des Kunden
darstellen, werden hier detalliert betrachtet.
o Intellectual Tour/ Saboteur Tour: Hier wird versucht, die Software herauszufordern, um
beispielsweise Grenzen herauszufinden bzw. sie möglichst destruktiv zu testen.
o Guidebook Tour: Anhand der Dokumentation wird überprüft, ob die Software wie beschrieben sich
verhält
25. Continuous Integration, Delivery & Deployment
Continuous
Integration
• Kontinuierliche
Integration durch
täglichen Check-In
inkl. Build-/Unit
Test
• Schnelles Feedback
zur Qualität
• Deployment auf
Test-Umgebung
Continuous
Delivery
• Automatisierte
Test
(Regressionstests)
• Deployment auf
Knopfdruck für eine
beliebige Version
auf internen
Umgebungen
Continuous
Deployment
• Jeder erfolgreiche
Build wird
automatisch auf die
Produktiv-
Umgebung verteilt
27. Integration in Scrum
10 Allgemeine Prinzipien und Good Practise
Agiles Testen am Beispiel von Scrum verfeinert die Konzepte des agilen Vorgehens
Agiles Vorgehen in der Entwicklung erfordert systematisches Vorgehen beim Testen
Abschließender systemübergreifender Releasetest als dedizierter Sprint
Kontinuierliches Testen und Feedback parallel zur Entwicklung
Früher Start der Testaktivitäten und Einsatz von Test-First-Techniken (z. B. TDD)
User Stories bilden die Basis für die Positiv-Testfälle,
Testfälle müssen aber auch unzulässige Szenarien abbilden
Nicht-funktionale Anforderungen ins Produkt-Backlog-Änderungen anpassbar sein
Automatisierung und Wiederholung der Testfälle wichtig
Verwaltung der manuellen und automatisierten Testfälle in einem Artefakt
28. Integration in Scrum
Testaktivitäten
Testplanung während Sprint-Planung und Daily Scrum
Testentwurf, -implementierung und -ausführung während des Sprints
Testauswertung während des Sprint-Reviews
Testabschluss während der Sprint-Retrospective
Rollen
Scrum Master übernimmt die Rolle des Testmanagers
Jeder im Team ist für das Testen verantwortlich
Product Owner wirkt bei der Testplanung und Testauswertung mit
33. Genereller Umgang mit Bugs
Wie soll das Scrum-Team damit umgehen, wenn sich über die Zeit immer mehr Bugs ansammeln?
Generelle Bug Regeln:
• Bugvermeidung
• Produktionsgefährdende Bugs: sofort
• No-Brainer: im aktuellen Sprint
• alle anderen: spätestens im nächsten Sprint
Bug Sprint: Einmalig in einer fokussierten Aktion alle Bugs erledigen.
Bug Stand-Up: Jeden Tag alle neuen Bugs verteilen.
Bug Elimination Day: Dezidierter Tag im Sprint. Alle Bugs, die angefangen werden, müssen am gleichen
Tag beendet werden.
Fit (Framework for Integrated Test) ist besonders für Akzeptanztests geignet, da die Testfälle leicht von der Fachabteilung (bzw. vom Auftraggeber) definiert werden können.
Die Testfälle werden bei Fit in HTML-Tabellen definiert und auch das Testergebnis ist eine HTML-Tabelle. Die Anbindung an das zu testende Programm erfolgt über "Fixtures".
http://www.torsten-horn.de/techdocs/java-fit.htm
