Klassischer Test ganz neu - Agil im V-Modell

Auch wenn Agilität in immer mehr Projekten Einzug hält, werden dennoch die Mehrzahl nach den Klassikern “Wasserfall” und “V-Modell” abgearbeitet. Da agile Vorgehensweisen in dem sehr dynamischen Testumfeld, in dem es im Normalfall ständig zu Änderungen an den Rahmenbedingungen kommt, ihr Potenzial gut entfalten können, ergeben sich in der Kombination von klassischen und agilen Methoden ganz neue Möglichkeiten.

Über das Testen ganz allgemein und den Test im agilen Umfeld hat mein Kollege Jan te Kock bereits in seinem Artikel „Qualität als Erfolgsfaktor für Softwareprojekte“ ausführlich geschrieben. In diesem Beitrag möchte ich aufzeigen, wie agile Vorgehensweisen im klassischen Test des V-Modells integriert werden können und welche Vorteile dies bietet.

Der Bericht basiert auf eigenen, sehr positiven Erfahrungen, die ich mit der im Folgenden beschriebenen Vorgehensweise gemacht habe.

Was passiert klassisch

Im klassischen V-Modell beginnt der Test im Idealfall, sobald die Anforderungen vollständig vorliegen und die erste Version des Fachkonzeptes erstellt wird. Während der Erstellung werden die Testfälle abgeleitet sowie die Testbarkeit sichergestellt. Das fertige Fachkonzept geht dann mit den Entwürfen für die fachlichen Testfälle an die IT. Dort wird ein DV-Konzept erstellt und dazu die Testfälle der IT. Die Umsetzung der Anforderungen und die Fertigstellung der Testfälle können dann zeitgleich erfolgen. Die Durchführung der Testfälle erfolgt dann in den vier Teststufen (Komponenten, Integration, System und Abnahme) des V-Modells. Zum Schluss wird die Freigabe erteilt und Produktivsetzung beauftragt. Für all das gibt es einen genauen Zeitplan, in dem das komplexe Thema möglichst wie vorgesehen abgearbeitet wird.

Abbildung 1: V-Modell

Wo liegen die Probleme und wie werden sie gelöst

Die Herausforderung bei der klassischen Vorgehensweise ist, bereits im Vorfeld alles weitgehend genau zu bedenken und zu planen. Während der langen Konzeptions-, Umsetzungs- und Testphase wird es mit an Sicherheit grenzender Wahrscheinlichkeit zu Änderungen kommen, die Auswirkungen auf die Planung haben. Dies hat dann zur Folge, dass die Planung angepasst werden muss.

Damit am Ende nicht die Zeit durch ständige Neuplanung aufgezehrt wird, eignen sich hervorragend agile Elemente. Es ist weiterhin das Ziel zu einem definierten (Release-) Zeitpunkt ein maximal aussagekräftiges Testergebnis zu haben. Die genaue Planung erfolgt bei der agilisierten Vorgehensweise nur für vergleichsweise kurze Zeiträume. Dabei fließen Erfahrungen aus der Vergangenheit genauso ein, wie Optimierungsansätze des Testteams. Das Vorgehen und die Ergebnisse werden transparent dargestellt. Eine breite fachliche und methodische Aufstellung des Testteams sowie eine direkte Kommunikation sind bei der Vorgehensweise unerlässlich.

Was wird verändert

Der Test ist in einem Projekt für gewöhnlich stark gekapselt, um eine effiziente Qualitätssicherung zu gewährleisten. Daher können viele agile Elemente genutzt werden, ohne dass dies große Auswirkungen auf das übrige Projekt zur Folge hat.

Die Anpassungen orientieren sich stark am Scrum-Framework, sind aber so angepasst, dass sie im V-Modell funktionieren. Im Wesentlichen wird das Testteam durch den Testmanager oder die Testmanagerin agil geführt.

Abbildung 2: Scrum-Framework

Konkret habe ich folgende Punkte verändert:

• der Testmanager oder die Testmanagerin wird Product Owner

• Einführung von Sprints, Dailys, Reviews und Retros

• alle Aufgaben als Epic priorisiert im Backlog

• Vorgaben von außen als definiton of done

• kleine, eigenverantwortliche Gruppen

• fokussiertes Arbeiten / neue Anforderungen über den Product Owner

• fester, eigener Raum

• Kanban-Board mit drei Spalten

• Beschränkung des formalen Reporting auf absolutes Minimum

So kann ohne aufwändige Neuplanung iterativ das jeweils relevanteste Thema im Test bearbeitet werden. Das Testteam fokussiert sich auf die anfallenden Tätigkeiten und liefert das in der Zeit beste erreichbare Ergebnis.

Risiken und Chancen

Im Wesentlichen gibt es zwei Risiken, die sich aus dieser Vorgehensweise ergeben.

• Durch die Kapselung der agilen Vorgehensweise im Umfeld des V-Modells, kann es zu Akzeptanzproblemen im übrigen Projekt kommen. Hier ist eine gute Kommunikation notwendig, die die Vorteile der Vorgehensweise herausstellt und ein Product Owner (Testmanager oder die Testmanagerin), der dem Testteam den Rücken freihält, damit sie sich auf ihre Aufgabe fokussieren können.

• Durch die Verwässerung des Scrum-Frameworks können Probleme auftauchen, die es bei der reinen Vorgehensweise nach dem Scrum-Framework nicht geben würde. Hier ist insbesondere das Testteam gefragt, was durch regelmäßige Verbesserung des eigenen Vorgehens möglichst nah am Scrum-Framework arbeiten muss. Unterstützung kann es hier durch einen Scrum Master erhalten.

Die Chancen der Vorgehensweise überwiegen dagegen deutlich.

• Durch die Anwendung agiler Werte wie Transparenz, Fokussierung, direkte Kommunikation und kontinuierliche Verbesserung kann auf Dauer die Leistung des Teams und die Qualität des Ergebnisses deutlich verbessert werden.

• Durch die Anwendung der Grundregeln des Scrum-Frameworks werden Resultate schnell sichtbar. Anpassungen an Ziel, Vorgehen und Planung sind jederzeit möglich und willkommen.

• Die Dokumentation beschränkt sich auf das Wesentliche, zwingend Erforderliche. Trotzdem sind für alle Interessierten die Informationen jederzeit verfügbar und transparent.

• Der regelmäßige, direkte Kontakt aller Beteiligten sorgt für eine breite Akzeptanz der Ergebnisse und verhindert Fehlentwicklungen über einen langen Zeitraum.

• Die Vorgehensweise hat nur wenige Regeln und ist schnell erlernbar. Ergänzungen kann das Team eigenverantwortlich festlegen (und auch wieder abschaffen), um sich zu verbessern.

Fazit

Die Vorteile des Vorgehens überwiegen deutlich und die Nachteile können durch Kommunikation und Eigenverantwortung gut aufgewogen werden. Erfahrungsgemäß ist die größte Herausforderung, dass eine Vielzahl von Berichten und Reportings durch eine transparente Darstellung des Vorgehens und der Ergebnisse ersetzt wird. Aus eigener Erfahrung kann ich sagen, dass bei guter Kommunikation das Verfahren schnell akzeptiert wird und nur noch Pflichtberichte erstellt werden.

Am Ende ist das beschriebene Vorgehen ein sehr guter agiler Anfang mit vielen Vorteilen. Meine Erfahrungen mit der Kombination von agilen Praktiken im V-Modell waren durchweg positiv und haben sich bewährt. Es spricht also nichts dagegen mit kleinen Schritten anzufangen und Agilität einfach im Kleinen zu beginnen ohne gleich das ganz große Rad zu drehen.

Vielleicht ist die Umsetzung auch der Startschuss für eine weitere Agilisierung der Entwicklung, des Projektes und vielleicht auch des Unternehmens.