Für einen Kunden des öffentlichen Dienstes bekamen wir den Auftrag die Teilprojektleitung der Qualitätssicherung in einem Entwicklungsprojekt zu übernehmen. Das Besondere daran war, dass die Entwicklungsarbeiten agil (Kanban) stattfanden, während wir im Test angehalten waren (Kundenvorgabe), weiterhin klassisch vorzugehen. Als Testmanagement-Tool standen uns Jira (inkl. Zephyr Plugin) zur Fehler- und Testfallerstellung sowie Testfalldurchführung zur Verfügung. Des Weiteren wurde Confluence genutzt, um alle Anforderungen zu verwalten. Da das Teilprojekt Entwicklung agil operierte, wurde Jira entsprechen aufgesetzt – d.h. es gab Entwicklungsstorys und zugehörige Unteraufgaben, die innerhalb von dreiwöchigen Sprints entwickelt wurden. Sämtliche Storys wurden durch einen Product Owner aus einem Backlog ausgewählt.

Das Teilprojekt QS hatte es also mit einem rein agilen Entwicklungsumfeld und ihren Werkzeugen zu tun, sollte aber selbst klassisch arbeiten. Schnell war klar, dass wir hier eine Vorgehensweise finden mussten, die die Vorteile der Agilität nutzte, die klassischen Ansätze dabei jedoch nicht vernachlässigen durfte. Hinderlich war dabei die anfangs ausgesprochen dünne Personalstärke des QS Teams, die kaum teststrategische Überlegungen zuließ. Mit wachsender Teamstärke entspannte sich jedoch die Situation. Dreh- und Angelpunkt unsere QS Aktivitäten waren die dreiwöchigen Sprints. An diesen Zeitraum mussten wir uns adaptieren und eine sinnvolle Vorgehensweise finden. Zugute kam uns dabei, dass das Entwicklungsteam abweichend zum klassischen Scrum-Vorgehen einen Freeze eingeführt hat. Ein Folgesprint startet nicht unmittelbar nach Ablauf des vorangegangenen Sprints. Stattdessen wird eine Woche Freeze entwicklungsseitig zur Präsentation, Konsolidierung und Vorbereitung genutzt. Daher entwickelten wir folgende Vorgehensweise, die wir dann auch umsetzten und die sich bewährte:

1. Agil: Innerhalb der Spritphase wurde jede entwicklungsseitig fertiggestellte Story sofort in einen Testfall umgesetzt und ausgeführt. Mit der Konsequenz, dass ggf. sofort ein Fehlerticket erstellt wurde. Vorteil: Die Entwicklung erhielt unmittelbar Feedback über die Qualität der Umsetzung und konnte noch im selben Sprint darauf reagieren.
2. Klassisch: In der Freeze-Woche, nach Beendung eines Sprints, wurden, in einem separaten Testzyklus, noch einmal sämtliche bisher erstellten Testfälle ausgeführt. Vorteil: So wurde sichergestellt, dass „alte" Bestandsfunktionalität auch weiterhin funktionierte oder ggf. angepasst im Folgesprint werden musste. Dieser klassische Ansatz entspricht einem typischen Regressionstest.

Es liegt in der Natur der Sache, das Regressionstests mit der Zeit quantitativ zunehmen und somit in Summe immer mehr Zeit benötigen. Da wir aber grundsätzlich nur eine Woche Zeit dafür hatten, mussten wir einen Weg finden, um diese Problematik zu lösen. Die Entlastung lautete „Testautomatisierung". Das heißt, Testfälle, die bereits mehrfach stabil, also fehlerfrei, durchgelaufen sind, wurden automatisiert und verschafften somit wieder zeitliche Luft.

Da das Projekt noch nicht beendet ist, wird unsere aktuelle Teststrategie permanent hinsichtlich potenzieller Optimierungen hinterfragt (Lesson Learned). Das heißt, der Weg von heute, muss nicht zwangsläufiger Weise auch der Weg von morgen sein – ganz so, wie es in den Standardwerken für Testmanagement nahegelegt wird.