Agilisierung von Testsystemen

Transkript

1 Agilisierung von Testsystemen Von der Eistüte zur Testpyramide ObjektForum Karlsruhe, Lars Alvincz, Daniel Knapp

2 Testen in historisch gewachsenen Systemlandschaften ist mühsam Ausgedehnte QS- und Stabilisierungsphasen Dadurch Verzögerung der Auslieferung Lange time-to-market [7]

3 Warum sind QS-Phasen so lang? Tests werden fast ausschließlich nach Entwicklungsphase durchgeführt Hohe Testaufwände, da Testfälle das Gesamtsystem adressieren, selbst wenn nur Teilaspekte getestet werden sollen Hohe Fehlerbehebungskosten, da Fehler spät gefunden werden Anforderungen Code Test Produktion Relative Kosten zur Beseitigung von Fehlern

4 4 Konsequenz: Hohe Wartungsaufwände time spent on bug-fixing features Mit fortlaufender Lebensdauer entstehen immer höhere Wartungsaufwände, dadurch wenig Zeit für neue Features

5 Ziel: Kurze time-to-market bei hoher Qualität Stabiles und erweiterbares Gesamtsystem Effiziente Entwicklungs- und Testaufwände Permanente Lieferfähigkeit Wie erreichen wir diese Ziele?

6 Agenda Zielbild Agilisierung von Testsystemen Patterns zur Agilisierung Fallbeispiele Fazit

7 Wie können wir eine kurze time-to-market bei hoher Qualität erreichen? Agile Softwareentwicklung: fertige Softwarezum Ende des Entwicklungszyklus ausliefern SPRINT Product Increment hohe Entwicklungsgeschwindigkeit bei effizientem Aufwand 24 hours Product Backlog Sprint Backlog 2-4 weeks Was bedeutetdas fürden Test?

8 Anforderungen an die Testdurchführung Fertige Software am Ende des Sprint-Zyklus erfordert......zeitlich enge Verzahnung von Testen und Entwickeln...hohe Testabdeckung zur Absicherung gegen zukünftige Seiteneffekte (frühes Erkennen von Bugs)...effiziente Verteilung der Testaktivitäten...hohen Testautomatisierungsgrad Ergebnis: Stabiles und erweiterbares System

9 Effiziente Verteilung der Tests Entwicklertests entstehen fortlaufend während des Entwicklungsprozesses und decken die Erweiterungen vollständig ab (automatisiert) Automatisierte Akzeptanztests motivieren bzw. sichern neben den Entwicklertests das bestehende Verhalten verbleibende manuelle Tests werden nach schlankem Verfahren durchgeführt Die automatisierten Tests laufen mindestens nächtlich, besser beim Einchecken

10 10 Effiziente Verteilung der Tests: Die Testpyramide Anzahl Testfälle betrachteter Ausschnitt Aufwand, Dauer Systemtests Integrationstests Unit-Tests

11 Testpyramide: Testziele der Ebenen Pro Testebene Fokus auf das Testziel: Was testen, und was nicht? Unittests: Alle Einzelteile funktionieren korrekt (eher technisch; auch fachlich) Integrationstests: Die Bestandteile funktionieren im Zusammenspiel korrekt (eher fachlich; auch technisch) Systemtest: Das Gesamtsystem funktioniert exemplarisch als Ganzes

12 12 Ergebnis: Hohe Qualität, kurze time-to-market time spent on bug-fixing features time spent on bug-fixing features geringe Testautomatisierung, nachgelagerte Tests agile Entwicklung

14 Agilisierung von Testsystemen 1. Bestandsaufnahme Ist-Zustand von Testabläufen und Testumsetzung erfassen 2. Diagnose und Ableiten von Maßnahmen Ist-Zustand bewerten und Maßnahmenkatalog ableiten 3. Umsetzung der Maßnahmen Testsystem agilisieren

15 Schritt 1: Bestandsaufnahme Ziel: Ist-Zustand von Testabläufen und Testumsetzung erfassen Vorgehen: Interviews mit den Beteiligten und stichprobenartige Code/Test Reviews Typische Fragen: Wie lange dauert ein kompletter Systemtest? Wie hoch sind die manuellen Testaufwände? Gibt es vor der Auslieferung Stabilisierungsphasen? Wie hoch ist die Abdeckung durch Unittests? Wie ist das Verhältnis von Entwicklungsaufwand zu Testaufwand?

16 Schritt 2: Diagnose und Ableiten von Maßnahmen Ziel: Ist-Zustand bewerten und Maßnahmenkatalog ableiten Vorgehen: Identifizieren der Verbesserungspotentiale Priorisierung (auch gemäß Erfordernissen aus dem Projekt) Maßnahmen definieren mit überprüfbaren Metriken Ebenen: Organisation, Prozess, Engineering Wichtig: Kosten/Nutzen-Verhältnis berücksichtigen

17 Typische Diagnose-Ergebnisse und Ansatzpunkte QA nachgelagert QA nicht bei Team Umgedrehte Testpyramide Hoher Anteil an manuellen Tests Keine Unittests Geringe Testabdeckung Unwartbare Testsuiten Lange Testlaufzeiten Kein klarer Fokus der Testfälle Keine reproduzierbaren Testergebnisse Hohe Bug-Lebensdauer Testeffizienz Testorganisation Testabdeckung Testautomatisierung Organisation/Prozess Engineering

18 Schritt 3: Umsetzung der Maßnahmen Ziel: Testsystem agilisieren Vorgehen: Testeffizienz Testorganisation (Bestehende) Testverteilung und -zuständigkeiten hinterfragen und definieren Agile Software-Entwicklungspraktiken im Team etablieren Testabdeckung Testautomatisierung Refactoringder Tests und der Testlandschaft Wichtig: Regelmäßige Bewertung der Maßnahmen und bei Bedarf nachjustieren

19 Grundvoraussetzung (1/2): Agile Softwareentwicklung Agile Entwicklungstechniken (XP, Clean Code) innerhalb Entwicklungsteam automatisierte Tests auf verschiedenen Ebenen konsequente Refactorings zur Vermeidung technischer Schulden Testisolationstechniken und -werkzeugeeinsetzen, um wiederholbare Tests zu produzieren und Testlaufzeiten zu verkürzen Wichtig: an Test-Code gelten mindestens die gleichen Anforderungen wie an Produktiv-Code!

20 Grundvoraussetzung (2/2): Entwicklungsprozess Testabdeckungsgrad einer Software sollte ermittelt werden können, um Testlücken gezielt schließen zu können Refactorings gefahrlos durchführen zu können Ergebnisder automatisierten Tests muss für Entwickler sichtbar sein Stichwort: Continuous Integration Stichwort: Early Feedback Rasches Gegensteuern im Fehlerfall

21 Wie schnell drehen wir die Testpyramide um? Systemtests Integrationstests Unit-Tests Verschiedene Szenarien denkbar: 1. Dedizierte Sanierungsphase: Fokus auf Agilisierung Sinnvoll bei Entwicklungsstillstand durch langsame Tests Hoher Invest, kurzfristige Agilisierung 2. Inkrementell: Sanierung im laufenden Betrieb Sinnvoll, falls noch Kapazität für Weiterentwicklung vorhanden Anteil Agilisierung Anteil Agilisierung Geringer Invest, Umstellung erfolgt nebenbei; mittelfristige Agilisierung

23 Patterns zur Agilisierung der Testsysteme Die Patterns zielen jeweils auf bestimmte Ebenen der Testpyramide und auf bestimmte Ansatzpunkte Strategie- und Engineering-Patterns Pattern: Ausgangssituation Ziel Vorgehen Testorganisation Systemtests Integrationstests Unit-Tests Testeffizienz Testabdeckung Testautomatisierung

24 24 Pattern: Testverlagerung auf niedrigere Ebenen Strategie #1/7 Ausgangssituation Es existiert eine Vielzahl komplexer Systemtests mit vielen Varianten, die verschiedene Aspekte unterliegender Komponenten testen Bestehende Tests haben eine hohe Laufzeit Ziel Testeffizienz und -wartbarkeit erhöhen Reduktion der Testdurchführungsdauer Vorgehen Komplexe Systemtests nach fachlichen und technischen Aspekten auf untere Ebenen der Pyramide verlagern Fokus auf wenige aussagekräftige Systemtests Testorganisation Systemtests Integrationstests Testeffizienz Unit-Tests

25 25 Pattern: Refactoring für Testbarkeit Strategie #2/7 Ausgangssituation Das System ist historisch gewachsen Keine klar getrennten Komponenten, Klassen sind nicht isoliert testbar Ziel Refactoring des Systems hinsichtlich Test- und Erweiterbarkeit Testeffizienz ermöglichen Testabdeckung sukzessive erhöhen Vorgehen Bestehendes Verhalten grob durch Integrationstests sichern Refactoring und Neuaufbau nach Testpyramide Testabdeckung Testautomatisierung Testeffizienz Systemtests Integrationstests Unit-Tests

26 26 Pattern: Test-Isolation Strategie #3/7 Ausgangssituation Das System hat viele Abhängigkeiten zu externen Systemen/Infrastruktur Hohe Testlaufzeiten, schlechte Reproduzierbarkeit von Ergebnissen Ziel Stabile Testergebnisse Kurze Durchführungsdauer Vorgehen Externe Systeme/Infrastruktur durch Testdoubles ersetzen Datenbank durch In-Memory-DB ersetzen Services durch Attrappen ersetzen Achtung: Nicht vergessen, auch ohne Testdoubles zu testen! Testabdeckung Testautomatisierung Testeffizienz Systemtests Integrationstests Unit-Tests

27 27 Pattern: Manuelle Tests automatisieren Ausgangssituation Bestehende manuelle Regressionstests sind nur mit großem Aufwand und langer Laufzeit ausführbar Ziel Testlaufzeit reduzieren, Testaussagekraft erhöhen Vorgehen Sinnhaftigkeit der Tests überprüfen, Strukturierung Automatisierte Akzeptanztests schreiben, Vorbedingungen automatisiert herstellen Achtung: Ggf. weiterhin manuelle Tests nötig und sinnvoll Kosten/Nutzen-Betrachtung wichtig! Testautomatisierung Systemtests Integrationstests Unit-Tests Strategie #4/

28 28 Pattern: Testfälle fokussieren Strategie #5/7 Ausgangssituation Existenz diverser Varianten komplexer Systemtests, die redundant sämtliche Aspekte mehrerer Komponenten testen; der Testfokus ist unklar Beim Vorliegen von Fehlern schlagen alle Tests an denselben Stellen fehl Ziel Aussagekräftige Systemtests erstellen Testorganisation verbessern Vorgehen Testfälle auf einzelne Fach-Aspekte fokussieren Irrelevante Werte aus dem Test ausblenden Tests möglichst orthogonal aufbauen Testorganisation Systemtests Integrationstests Unit-Tests Testeffizienz

29 29 Pattern: GUI-Tests automatisieren/strukturieren Ausgangssituationen Bestehende manuelle GUI-Tests sind nur mit großem Aufwand und langer Laufzeit ausführbar Die Testskripte sind nicht wartbar und anfällig gegen strukturelle Änderungen Ziel Testlaufzeit und -aussagekraft verbessern Wartbarkeit und Wiederverwendbarkeit der Tests Vorgehen Masken durch Page Objects modellieren. Vorteile: Wartbarkeit: GUI-Struktur in Page Objects gekapselt Abstraktion: Tests greifen funktional auf GUI zu Achtung: Kosten/Nutzen-Betrachtung wichtig! Testabdeckung Testautomatisierung Testeffizienz Systemtests Integrationstests Unit-Tests Strategie #6/

30 30 Pattern: Exploratives Testen Ausgangssituation Neben den automatisierten Tests sind auch manuelle Tests nötig Ziel Verbleibende manuelle Tests effizient und planbar durchführen Vorgehen Exploratives Testen Zutaten: Scope, Timebox, Testprotokoll Beispiele: Testtouren: Anti-Social Tour, Fed Ex Tour, Supermodel Tour Testabdeckung Testeffizienz Systemtests Strategie #7/7 Integrationstests Unit-Tests

31 31 Pattern: Neuentwicklung separieren Ausgangssituation Ein neues (kleines) Feature ist zu entwickeln; bestehende Klassen sind sehr groß und schlecht testbar Ziel Neuentwicklung gemäß Testpyramide Vorgehen Neuen Code neben bestehendem Code entwickeln TDD, kleine Klassen (Single Responsibility) Auch Tests schreiben, die den Aufruf des neuen Codes sicherstellen Testabdeckung Systemtests Integrationstests Engineering #1/5 Unit-Tests

32 32 Pattern: Test Driven Bug Fixing Ausgangssituation Es ist ein Bug aufgetreten Ziel Testabdeckung erhöhen Ähnliche Bugs finden Verhaltenssicherung (Regressionstest) Vorgehen Bug zunächst durch einen (Unit-)Test nachstellen; dieser sollte rot sein Bug beheben, Test sollte grün werden Je nach Kritikalität/Aufwand weitere Tests schreiben (Bugs sind sozial) Integrationstests Unit-Tests Engineering #2/5 Systemtests Testabdeckung

33 33 Pattern: Vorbereitendes Refactoring Engineering #3/5 Ausgangssituation Für ein neues Feature könnte bestehender Code wiederverwendet werden; allerdings muss er dazu noch verallgemeinert werden Ziel Absicherung für Strukturverbesserung Vorgehen Bestehenden Code durch Tests abdecken Refactoring durchführen Die Unit-Tests müssen am Ende nach wie vor grün sein! Systemtests Testabdeckung Integrationstests Unit-Tests

34 34 Pattern: DSL für Aufbau von Testobjekten Engineering #4/5 Ausgangssituation Oft müssen für Tests komplexe Objektstrukturen aufgebaut werden Ziel Komplexität im Test-Setup reduzieren (Clean Test) Wartbarkeit und Wiederverwendbarkeit der Tests Vorgehen Hilfsklassen zum Aufbau der Strukturen entwickeln (inkrementell) z.b. FluentAPI: einzelperson("hans","müller").mitadresse(strasse("testweg",5),ort(10678,"ulm")).mitgeburtsdatum(" ") Testeffizienz Systemtests Integrationstests Wichtig: Explizite Formulierung relevanter Testdaten Unit-Tests

35 35 Pattern: Akzeptanztests für neues Feature Engineering #5/5 Ausgangssituation Ein neues Feature hat eine hohe fachliche Komplexität und/oder Kritikalität Ziel Verhaltenssicherung, Testabdeckung erhöhen Vorgehen Automatisierte Akzeptanztests schreiben (idealerweise sogar vor Umsetzung) Kann durch Fachler/Tester geschehen, Entwickler unterstützt Herausforderung: passende Sprache für Testfälle entwickeln Achtung: Testfokus berücksichtigen; wenig Überschneidung Kosten/Nutzen-Betrachtung wichtig! Testabdeckung Testautomatisierung Integrationstests Unit-Tests Systemtests

37 37 Lars Alvincz, Daniel Knapp Agilisierung von Testsystemen ObjektForum 2014, Stuttgart/Frankfurt [1]

38 38 Lars Alvincz, Daniel Knapp Agilisierung von Testsystemen ObjektForum 2014, Stuttgart/Frankfurt [2]

39 Erfahrungsbericht 1: Sanierung im laufenden Betrieb Ausgangspunkt Übernahme eines Softwareprojekts zur Weiterentwicklung Schlechte Wartbarkeit des Codes, wenig Unittests Vorgehen Sanierung im laufenden Betrieb Keine eigenen Refactoring-Tasks Ergebnisse Schrittweise Erhöhung der Softwarequalität Weiterentwicklungen konnten schneller durchgeführt werden Reduzierung der Bugs, kürzere time-to-market

40

41 41 Lars Alvincz, Daniel Knapp Agilisierung von Testsystemen ObjektForum 2014, Stuttgart/Frankfurt [2] [3]

43 Erfahrungsbericht 2: QA in Team integrieren, automatisieren Ausgangssituation: QA nachgelagert, größtenteils manuell, keine Unittests Kommunikation mit vielen externen Systemen Maßnahmen (Zeitraum: 1 Jahr) Tester ins Team verlagern Konsequent Unittests bei Änderungen, Attrappen für externe Systeme Manuelle Tests automatisieren Ergebnisse: Unittestabdeckung 30%, manuelle Tests größtenteils automatisiert Nachgelagerte QA-Aktivitäten deutlich reduziert Monatliche Releases möglich

45 45 Lars Alvincz, Daniel Knapp Agilisierung von Testsystemen ObjektForum 2014, Stuttgart/Frankfurt [2] [5] [6]

46 Erfahrungsbericht 3: Fokus auf Agilisierung Ausgangssituation: Unwartbares System, keine Weiterentwicklung möglich Ausschließlich manuelle Systemtests Maßnahmen (Zeitraum: 1/2 Jahr) Stichprobenartig automatisierte Integrationstests zur Sicherung des Verhaltens Refactoring/Neuentwicklung von Komponenten Konsequenter Einsatz agiler Entwicklungspraktiken Tester ins Sprint-Team verlagert Ergebnis: System wartbar und erweiterbar, QA-Phasen drastisch reduziert

47

48 Agenda Zielbild Agilisierung von Testsystemen Fallbeispiele Patterns zur Agilisierung Fazit

49 Fazit Die Agilisierung von Testsystemen überführt historisch gewachsene Systemlandschaften in stabile und erweiterbare Systeme Kernpunkte: Effiziente Verteilung der Testaktivitäten gemäß der Testpyramide Einsatz von agilen Entwicklungspraktiken im Projekt Gezielter Einsatz der Patterns zur Agilisierung Ergebnis: Team erreicht wieder hohe Entwicklungsgeschwindigkeit Kurze time-to-market

50 Literatur Bob Martin: Clean Code. A Handbook of Agile Software Craftsmanship, 2008 Michael Feathers: Working Effectively with Legacy Code, 2004 James Whittaker: Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design, 2009 Page Objects:

51 Referenzen [1] [2] [3] [4] [5] [6] [7] fotolia.com #

52 52 Anhang

53 53 Agile Testquadranten automatisiert / manuell Für das Team Funktionstests Beispiele Prototypen Story Tests Simulationen Entwicklertests Unittests Komponententests fachlich Q2 Q3 Alle Tests Q1 Q4 Manuelle explorative Tests Benutzer-Akzeptanztests Usability Tests Performance-Tests Lasttests manuell Für das Produkt automatisiert technisch Werkzeuge Aus: Lisa Crispin, Janet Gregory (2009): Agile Testing: A Practical Guide for Testers and Agile Teams

54 Manuelles Testen Hauptziel agile Softwareentwicklung: Das Ausliefern und Bereitstellen neuer Funktionalitäten nach jedem Entwicklungssprint Anwenden des manuellen Testens um nicht-triviale Fehler aufzufinden Definierter Soll-Zustand vs. Was wäre wenn? zu erforschen, wie eine Anforderung getestet werden kann Tests auszuführen, deren Automatisierung zu aufwändig bzw. teuer ist Sonderkonstellationen abzudecken

55 Exploratives Testen (1/2) Exploratives Testen als leichtgewichtiger Ansatz für manuelle Tests Paralleles Testdesign und -ausführung Im Gegensatz zu fixen Testvorgaben nach Plänen (die meist allerdings gewisse Interpretationsspielräume offen lassen) Vorgehen nach einem strukturiertem Ansatz Beinhaltet Protokolle, auch als Inspiration für künftige Testsitzungen Letzter Test beeinflusst den nächsten Test Kein Widerspruch zu klassischen Testplänen, sondern ergänzend

56 Exploratives Testen (2/2) Analogie: Software-Tester vergleichbar einem Tourist Man sieht nicht alles, bzw. nur bestimmte Teile der Software Es gibt viele Wege, um das Ziel zu erkunden Man möchte sicherstellen, dass man die wichtigsten Punkte gesehen hat Zutaten: Feste Zeitvorgabe (Timebox) Dokumentation (Testprotokoll) Umfang und Art der Test-Tour (Scope) Vorgehen: Spezifische Touren (FedEx, Supermodel...)