Auf einem Abendvortrag der ASQF-Fachgruppe Software-Test an dem ich kürzlich teilnahm, stand diese Frage unter dem Motto „Quality Assurance goes Agile“ zur Debatte. Sabine Hermann, Testmanagerin bei Logica, stellte das Thema anhand eines Projektes vor, bei dem es um den Wechsel vom V-Modell XT als Vorgehensmodell in der Softwareentwicklung hin zu Scrum bei der British Telecom ging.
In den letzten Jahren haben sich unter dem Oberbegriff der agilen Softwareentwicklung zahlreiche neue Vorgehensmodelle, Methoden und Strategien etabliert, welche durch Veränderungen der Arbeitsorganisation die Softwareentwicklung schneller, besser, für die Beteiligten erfüllender und nicht zuletzt auch effizienter machen sollen – agil eben.
Das hat natürlich auch Auswirkungen auf die Arbeit von (entwicklernahen) Softwaretestern und QA-Spezialisten. Und darum ging es auch bei dem vorgestellten Projekt.
Bereits die klassischen Vorgehensmodelle der Softwareentwicklung wie z.B. das V-Modell XT sehen iterative Vorgehensweisen sowie in den Entwicklungsprozess integrierte Phasen der Qualitätssicherung vor. Diese im „agilen Manifest“ 2001 erstmals ausformulierten Denkansätze werden in den meisten agilen Vorgehensmodellen weiter ausgebaut. So ist z.B. das Kernelement der Entwicklungsplanung nach Scrum der sogenannte Sprint: ein überschaubarer Zeitabschnitt (einige Tage bis max. Wochen) innerhalb dessen inkrementell an vorab festgelegten Aufgaben gearbeitet wird; der mit einem auslieferungsfähigen Zwischenergebnis endet und innerhalb dessen zu implementierende Anforderungen nicht geändert oder umpriorisiert werden.
In Scrum gibt es drei grundlegende Rollen: den Scrum Master (Projektleiter und Methodenspezialist), den Product Owner (Kunde, Produktmanager bzw. Facharchitekt) sowie das Scrum Team (Entwickler). Eine gesonderte Teamleitung ist oftmals gar nicht mehr vorgesehen, da das Team viele Aufgaben der operativen Planung und Steuerung selbst mit Hilfe bestimmter Instrumente wie Daily Scrums (tägliche Kurzbesprechungen), Planning Game (ein Verfahren zur Aufwandsabschätzung in Gruppen) oder Vorschlägen für zu implementierende Anforderungen für die nächsten Sprints übernimmt. Oftmals übernehmen aber auch Projektleiter oder der Scrum Master die Aufgabe der Teamleitung. Die wichtigste Aufgabe eines Scrum-Teamleiters, so vorhanden, besteht darin, Störungen von seinen Entwicklern fernzuhalten, damit diese pünktlich und zuverlässig das geplante Teilergebnis abliefern.
Die schrittweise und an verwendbaren Zwischenergebnissen orientierte Vorgehensweise bringt es mit sich, dass auch das Testen der Zwischenergebnisse agil organisiert werden muss, um so eine wirksame Zusammenarbeit aller Projektbeteiligten zu erreichen.
Agiles Arbeiten soll ja gerade nicht zu Arbeitsverdichtung, mangelhafter Dokumentation, unzureichender Qualitätssicherung und allgemeiner Schlamperei bei der Softwareentwicklung führen. Die Veränderungen der Arbeitsorganisation sollen dem gerade entgegenwirken, in dem sie Freiräume schaffen, den Beschäftigten mehr Handlungs- und Entscheidungsspielräume geben, Mikromanagement ohne Ergebnisbeitrag abbauen und Kunden direkter beteiligen. Außerdem fördert das agile Arbeiten ein partizipatives Denken nach dem Pareto-Prinzip: Das Wichtigste und Ergebniswirksamste zuerst, den Rest später, Schnickschnack ohne konkreten Nutzen gar nicht.
Im Rahmen des bereits erwähnten Organisationsentwicklungsprojektes bei der British Telecom wollte man vom V-Modell XT hin zu Scrum wechseln. Ursächlich dafür waren ständige Termin- und Qualitätsprobleme sowie Schwierigkeiten mit unflexiblen Abläufen, die man nicht in den Griff bekam. Und bei denen man sich mit dem Wechsel hin zur agilen Methodenwelt substanzielle Verbesserungen versprach.
Anforderungen (z.B. in Form von User Stories), Entwicklungszwischenstände und Dokumente werden in Scrum nicht zu fixen Phasen sondern kontinuierlich prozessbegleitend getestet und abgenommen. Daher spielen abschließende Akzeptanz- und Abnahmetests eine eher geringe Rolle.
Trotzdem gilt es in vielen Organisationen flexibel zu bleiben und keine Methodenorthodoxie der reinen Lehre zu betreiben. So wurde z.B. im Verlauf des BT-Projektes ein externes Testing-Team eingerichtet, dass die Systemtests, Regressionstests, die Testautomation sowie andere qualitätssichernde Maßnahmen wie z.B. Defect Tracking und Stabilitätstests übernahm. Auch wenn „reines Scrum“ so etwas an sich nicht vorsieht. So wurde unter Beibehaltung des Mehraugenprinzips eine kontinuierlich zunehmende Produktqualität erreicht. Allerdings galt es organisatorische Probleme zu lösen. So konnten Tester z.B. zunächst nur das testen, was Entwickler im vorangegangenen Sprint entwickelt hatten. Gaben die Tester dann den Entwicklern Rückmeldung über gefundene Probleme, waren diese schon wieder im nächsten Sprint gebunden und konnten sich erst in folgenden Sprints um die gefundenen Probleme kümmern. Der Gleichlauf zwischen beiden Teams (das „mitsprinten“ der Tester) musste erst entsprechend geplant und organisiert werden.
Zudem erfordert eine solche Zusammenarbeit mehrerer Teams auch, dass alle mit gleichen Tools auf eine gleiche Datenbasis zugreifen. Wenn Entwickler Testfälle in Excel-Listen verwalten, während Tester hierfür eine Testmanagementumgebung verwenden, wird es früher oder später zu Inkonsistenzen im Testfallbestand kommen. Zumal rasche Rückmeldungen über Teiltestergebnisse an die Entwickler oft wichtiger sind als ausgefeilte Testkonzepte.
Auch muss eine gemeinsame „Definition of Done“, also eine prüfbare Festlegung der zu erbringenden Aktivitäten, Ergebnisse und Qualitäten gefunden werden, aus denen hervorgeht, wann genau etwas fertig ist. Ohne feste Abnahmekriterien ist sonst ein „Overengineering“ oder umgekehrt das Abliefern von unausgereifter „Bananensoftware“ auch auf agilem Weg genauso gut möglich wie mit traditionellen Softwareentwicklungsmethoden.
Im Bereich des agilen Testens spielen bestimmte Methoden eine größere Rolle als bisher. Dazu zählen Unit Tests, frühzeitiges Testen und testgetriebene Entwicklung, bei der erst die Testfälle und dann der zu testende Code implementiert werden. Ebenso Komponententests, Testautomation, das Refactoring umfangreicher Testfälle sowie bereits das Testen auf Anforderungsebene.
Eine weitere Methode ist das Pair Testing (analog zum Pair Programming) bei dem ein Tester mit einem Entwickler, einem Anwender, dem Product Owner oder einem weiteren Tester zusammen testet.
Scrum hat sich in den letzten Jahren zum „Toyota Production System“ der Softwareentwicklung gemausert, das gerade von kleinen und mittleren Softwarehäusern, zunehmend aber auch von Konzernen wie z.B. Microsoft eingesetzt wird. Dabei stellen sich häufig Fragen nach der Kombination mit bzw. der Ablösung von anderen Ansätzen der Arbeitsorganisation im Entwicklungsbereich. Somit werden sich auch für Softwaretester und QA-Spezialisten die Tätigkeitsschwerpunkte und Arbeitsmethoden inhaltlich verschieben, wenn ihre Arbeitgeber oder Kunden Methoden und Vorgehensmodelle aus dem agilen Spektrum einführen.
