Klassischer Test ganz neu - Agil im V-Modell

Christian Mercier 11.06.2019

Erfahrungsbericht aus der Praxis

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.

Titelbild
√ú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.
Bild von 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 Anpassungen 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 agil gef√ľhrt.
Scrum-Framework (t2m)

Konkret habe ich folgende Punkte verändert:

  • Testmanager 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), 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.

Christian Mercier

Senior Consultant bei der frobese GmbH