Autoren: Sunil Maliyakkal, Masoud Ahmady
Agile Ansätze erfreuen sich in IT-Projekten zunehmender Beliebtheit. Sie stellen aber eine besondere Herausforderung für die Qualitätssicherung dar. In vielen Projekten wurden bereits verschiedene Arbeitsweisen getestet und miteinander verglichen, um eine möglichst effektive und effiziente und zufriedenstellende Vorgehensweise herauszuarbeiten. So auch in einem Logistikunternehmen:
Projekt A: Teilweise Einsatz von SCRUM
In Projekt A wurde ein Abrechnungssystem konzipiert und entwickelt. Das Projekt wurde von vornherein als agiles Projekt initiiert, allerdings beschloss das Management, das
SCRUM-Modell nicht vollständig bzw. idealtypisch umzusetzen.
So bestand das SCRUM-Team ausschließlich aus Entwicklern, die neben der eigentlichen Implementierung von fachlichen User Stories auch die entsprechenden Entwicklertests durchführten. Das Testen und die Abnahme der User Stories wurden somit zwar innerhalb des SCRUM-Teams mit Hilfe von Mocks und synthetischen Testdaten durchgeführt.
Ein integrativer Test, noch dazu durch erfahrene und entsprechend ausgebildete Softwaretester, wurde allerdings erst nach Beendigung des Sprints im Rahmen einer nachgelagerten Testphase bei der Systemintegration geplant.
Damit waren die Testexperten nicht Teil des SCRUM-Teams, sondern eine ausgelagerte Einheit, die sich inhaltlich und planerisch dem Sprintverlauf unterordnen musste. In diesem Modell traten verschiedene Komplikationen auf:
- Die fehlende Kompetenz in den Testmethoden zur Ableitung von Testfällen (Pfadüberdeckung, Grenzwertanalyse, Äquivalenzklassentest usw.) im SCRUM-Team führte dazu, dass zum Ende jeden Sprints zwar eine funktional vollständige Software geliefert wurde, die aber nicht vollständig hinsichtlich Robustheit, Fehleingaben und Falschverwendung geprüft war.
Es ist ein bekanntes Muster, dass Entwickler den Fokus auf funktionierende Software legen, die Suche nach Fehlern aber nicht in den Vordergrund stellen. Im Ergebnis führte dies zu Anhäufungen von Fehlerwirkungen im Integrationstest. Das Einkreisen dieser Fehler war sehr mühsam und zeitaufwendig, da sich Fehler zum Teil maskierten und die Fehlerbehebung stark sequentiell durchgeführt werden musste.
Als weitere Folge wurden Fehleranalyse und Debugging-Aktivitäten in zukünftige Entwicklungs-Sprints verschleppt und beanspruchten die (methodenimmanent begrenzten) Kapazitäten des SCRUM-Teams. Durch Aufstocken der Anzahl an Entwicklern und Priorisierung von Fehlern versuchte die Projektleitung vergeblich, die Lage in den Griff zu bekommen. Die beschriebenen Maßnahmen zeigten zwar kleine Erfolge, konnten langfristig aber nicht alle Versäumnisse kompensieren. Verständlicherweise, denn die angesetzten Maßnahmen zielten auf Symptombehandlung.
Die Ursache – fehlende Testkompetenz innerhalb des SCRUM-Teams – wurde dadurch nicht behoben. Im Gegenteil: Das zusätzliche Staffing der Entwicklungsressourcen führte zu Mehraufwand durch Einarbeitung neuer Mitarbeiter und vermehrten Koordinationsbedarf zwischen den Entwicklern – Kapazitäten, die zur Abarbeitung der User Stories letztlich wieder fehlten. Das schlimmste jedoch:
Die am Ende jedes Sprints im Rahmen des Sprint Review-Meetings demonstrierte Abnahmereife des Softwareproduktes entsprach schlicht nicht der Realität – ein fundamentaler Bruch mit den Grundprinzipien des agilen Manifests. Die Abbildung 1 verdeutlicht die Summe der Auswirkungen.
Projekt B: Einsatz von agilen Prinzipien wie SCRUM und SAFe
In Projekt B ging es um die Konzeption und Entwicklung eines Systems zur Kapazitätssteigerung von Schienennetzen.
In diesem Projekt wurde von Anfang an viel Wert auf die Einhaltung der agilen Prinzipien nach SCRUM und SAFe (Scaled Agile Framework) gelegt. Tester waren vollwertige Mitglieder des SCRUM-Teams und wurden nicht vom übrigen Team abgegrenzt. Somit haben sie das Team um spezifische Kompetenzen bereichert.
Zwar hat sich – wie bei Anwendung der SCRUM-Methodik üblich – das gesamte Team zur Lieferung definierter Arbeitsergebnisse auf Basis von User Stories “commited”, der Testexperte setzte jedoch den Rahmen für die Abnahme der Software. Sei es durch Abstimmung verbindlicher Abnahmekriterien zu jeder User Story, methodische Standards für die Herleitung von Testfällen und Mindestanforderungen für die Testabdeckung oder die Umsetzung einer durchgängigen Testautomatisierungsstrategie zur Erhaltung eines gleichmäßig hohen Qualitätsniveaus des Software-Produktes über alle Sprints hinweg.
Die User Stories wurden in Gänze erst dann abgenommen, wenn der Tester die ausgeführten Tests als bestanden deklariert hatte. Darüber hinaus agierte der Testexperte als „Sparringspartner“ für die Entwicklerkollegen: Während letztere beim Entwickeln der Applikation primär die technische Umsetzung von Fachanforderungen im Blick hatten, rückte der Tester anhand statischer Testmethoden (z.B. Interface Walk-throughs) und strukturierter Auswertung von Fehlern aus der Vergangenheit potentiellen
Integrationsproblemen zu Leibe.
Aufgabe des Testers war es also, in dem dynamischem Umfeld eines SCRUMProjektes durch übergreifende Testprozesse in Verbindung mit einer effektiven Testautomatisierung langfristig konstante Qualitätsstandards zu sichern. Nicht zuletzt führte das beschriebene Vorgehen auch zu einem ausgeglichenen Teamgefüge und einer ausgeprägten Feedback-Kultur. Die Teams waren durchgängig bereit, ihre Arbeitsweise so zu verändern, dass ein möglichst hochqualitatives Produkt entwickelt wird. Beispielsweise einigten sich Entwickler und Tester nach entsprechenden „Lessons Learned“-Runden darauf, Teilfunktionalitäten so früh wie möglich bereitzustellen, damit diese früh im Verlauf des Sprints getestet werden konnten.
Überhaupt existierte das in Projekten häufig zu beobachtende Spannungsverhältnis zwischen Entwicklern und Testern nicht, die Parteien betrachteten sich nicht als Gegenspieler (nach dem Motto: findet der Tester Fehler, hat der Entwickler unsauber gearbeitet; findet der Tester keine Fehler, taugt er nichts). Alle Mitglieder des SCRUM-Teams arbeiteten stattdessen Hand in Hand, um am Ende eines Sprints ein hoch- und mehrwertiges Resultat abzuliefern. Die Qualität der Softwarekomponenten stieg auch tatsächlich stetig und die Stimmung und Zusammenarbeit im Projekt verlief zusehends entspannter und angenehmer. Das Resultat war ein insgesamt besseres Ergebnis für alle Beteiligten.
Fazit: Agiles Vorgehen ist keine Rosinenpickerei
Als Ergebnis des Vergleichs der oben beschriebenen Projekte lässt sich folgendes festhalten: Agiles Vorgehen ist keine Rosinenpickerei – im Wesentlichen heißt es ganz oder gar nicht. Entweder man setzt alle (wichtigen) Konzepte von Agilität um – oder man
lässt es ganz bleiben.
Tester sind ein Teil des Projektteams. Qualität kann in einem agilen Umfeld, das von kontinuierlichen Lieferungen lebt, nicht nachträglich hineingetestet werden. Die investigative Sichtweise eines Testers zur Fehlersuche und Qualitätsanalyse sind notwendige Projektbestandteile – eine Erkenntnis aus den ersten 50 Jahren Software-Entwicklung. Test und Testautomatisierung sind wichtige Bestandteile des agilen Vorgehens. Letztendlich ist eine zuvorkommende Zusammenarbeit und enge Abstimmung mit allen Teammitgliedern unabdingbar.
