
Testen in agilen Projekten
Inhaltsverzeichnis
Agile Softwareprojekte folgen besonderen Methoden, um Software anwenderzentrisch und iterativ zu entwickeln (ein paar Ansichten zu Sinn und Unsinn agiler Methoden finden sie hier). Agiles Arbeiten führt zu schnelle Feedbackzyklen zwischen Entwicklungsteam und Product Owner und damit auch zu häufigen Lieferungen neuer Software Artefakte.
Potentiell produktionsreife Software mit jedem Sprint
In Scrum ist das Ziel jedes Sprints die Umsetzung der User Stories, auf die sich das Team zu Beginn des Sprints committed hat. Somit wird zum Ende jedes Sprints ein Stück Software geliefert, das diese neu umgesetzten Funktionalitäten beinhaltet.
Das bedeutet auch, dass dieses Sprint Artefakt einen Qualitätsanspruch haben sollte, der einem produktionsreifen Zustand entspricht (“potentially shippable”). Um dies zu erreichen, muss das Testen der Software fest in der Entwicklung verankert werden und in der Verantwortlichkeit der Entwicklungsteams liegen.
“Shift left” pattern
Je später im Entwicklungsprozess ein Bug gefunden wird, umso mehr Schaden (Kosten, Projektrisiko, Zeitverzögerungen, Verlust an Reputation) entsteht für das Unternehmen. Organisationen sollten also bestrebt sein, Fehler möglichst früh im Entwicklungsprozess zu finden und beheben. Das klingt zunächst logisch.
Dennoch organisieren viele, auch agile, Projekte ausgerechnet ihre Testphasen nach dem Wasserfallprinzip: Erst wenn alle zu testenden Lösungsbausteine verfügbar sind finden zwei- bis dreimal jährlich groß angelegte Testvorhaben und komplexe Staging-Orgien statt.
Leider macht man auf diese Weise beim Thema Testen einen Teil der gewonnenen Agilität des Entwicklungsprozesses wieder zunichte. Funktionale Anforderungen werden im jeweiligen Sprint entwickelt und im Sprint Review abgenommen. Das umfangreiche Testen von funktionalen und – insbesondere auch – nichtfunktionalen Anforderungen wird jedoch oft asynchron zum Sprint oder einfach “irgendwann später” gemacht.
Man verschenkt zudem die Möglichkeit, die man durch das häufige Testen kleiner Inkremente hat: Frühzeitiges Erkennen und Beheben von Bugs und Verhinderung von Fehlerkaskaden, also unerkannte Fehler, die Folgefehler mit sich bringen (und deren Analyse meistens aufwendig und zeitraubend ist).
Daher streben agile Teams das “Shift left” Pattern an, also das Heranrücken der Testaktivitäten an den Entwicklungsprozess, der ganz links, also am Anfang einer Iteration steht, daher “Shift left”.
Regressives Testen
Regressives Testen ist ein fester Bestandteil in agilen Projekten. Es bedeutet, dass man bei der Neuimplentierung einer Funktionalität stets überprüft, ob diese Änderung/Erweiterung am Quellcode nicht zu einem anderen Problem führt. Dies gilt auch für Bugfixes, bei denen manchmal ein Fehler behoben wird und gleichzeitig zwei neue Fehler unbeabsichtigt eingebaut werden.
Die Häufigkeit der Durchführung macht eine Automatisierung dieser Tests zwingend notwendig, um die Schlagzahl der Testdurchläufe realisieren zu können.
Hoher Automatisierungsgrad
Die Anforderungen an eine entwicklungsbegleitende Qualitätssicherung lassen sich am besten mit einem hohen Grad an automatisierten Test- und Deploymentverfahren bedienen.
Dabei gilt keinesfalls “Viel hilft viel”, man sollte sich stattdessen vorher Gedanken machen, für welche Softwarekomponenten und Akzeptanzkriterien bestimmte Testarten am sinnvollsten sind. Ausserdem sollte die Wiederholbarkeit im Vordergrund stehen, also Tests die voraussichtlich bei jedem neuen Artefakt neu ablaufen werden.
Für die verschiedenen Testarten, z.B.
- Unit Tests
- statische und dynamische Codeanalyse
- Oberflächentests
- Schnittstellentests
- Last- & Performancetests
- Kapazitätstests
gibt es eine Vielzahl von Tools am Markt, sowohl im kommerziellen Bereich, aber auch als Open Source oder Community Projekt. Wir helfen Ihnen gerne bei der herstellerneutralen Auswahl des geeigneten Tools für Ihr Testvorhaben.
Continuous Integration
Meistens werden diese Tools mit Continuous Integration (CI) Werkzeugen wie Jenkins, Octopus oder Bamboo zu sogenannten Pipelines zusammengestöpselt, um automatisiert und regelmässig die Qualität der Software zu überprüfen. In den Pipelines werden der Ablauf der einzelnen Tools und ihre Parametrisierung festgelegt.
Das Starten der Pipeline kann entweder zeitlich gesteuert (z.B. nächtlich) oder ereignisgesteuert (z.B. bei Einchecken von Quellcode im Repository) erfolgen.
In einer erweiterten Variante einer CI-Pipeline kann auch die Auswertung der Testergebnisse anhand von vorher festgelegten Key Performance Indikatoren (KPIs) automatisch erfolgen, sodass ein manueller Eingriff nur bei Abweichung der Ergebnisse von den KPIs erforderlich ist.
Fazit
Der Vorteil agiler Softwareentwicklung lässt sich nur dann vollständig heben, wenn man auch das Testen der Software agilisiert.
Testautomatisierung ist einer der Schlüssel zum Erfolg, jedoch für sich genommen keine Garantie für eine erfolgreiche agile Qualitätssicherung. Die konzeptionelle Vorarbeit ist nicht zu unterschätzen, zudem muss das Mindset aller am Projekt beteiligten stimmen.
Sollten Sie Rückfragen oder konkrete Anforderungen in den Bereichen “Agiles Testen” oder “Continuous Integration” haben, helfen wir Ihnen gerne mit unserer umfangreichen Projektpraxis in diesem Umfeld. Nehmen Sie gerne einfach Kontakt mit uns auf.

Stephan Rossbach
Verwandte Artikel

Scrum Poker – eine beliebte Schätzmethode agiler Teams
Im agilen Kontext, sind die sogenannten Scrum Poker Karten nicht (nur) zum Spielen gedacht, sondern erlauben dem Scrum Team gemeinsam den Aufwand einzelner Aufgaben einzuschätzen.

Kanban makes recruiting easy
Kanban ist eine agile Methode, die gut in bereits bestehende Strukturen integriert werden kann. Dabei werden Aufgaben zunächst in kleine Arbeitsschritte aufgeteilt und nacheinander abgearbeitet. Allerdings liegt der Fokus nicht darauf, an möglichst vielen Tasks gleichzeitig zu arbeiten, sondern darauf, einzelne Aufgaben möglichst schnell abzuschließen.

Die Stacey-Matrix und das Cynefin-Framework
Die Stacey-Matrix wird in Verbindung mit dem Cynefin-Framework genutzt, um über den richtigen Einsatz agiler Methoden entscheiden zu können. Denn oftmals ist Agilität nicht automatisch der Schlüssel zum Erfolg.