Das Projekt
kreuzwerker hat die Room49 GmbH bei diesem Projekt mit DevOps und Test Management Dienstleistungen unterstützt. Die Fallstudie befasst sich mit der Anlaufphase des Test Managements. Das Projekt wurde auf zwei Teams verteilt. Ein Team war für die Software-Entwicklung, das andere für Content und Leitartikel zuständig.
Das Problem
Tendenziell problematische Entwicklungen zeichneten sich bereits früh im Projektverlauf ab. So gab es zum Beispiel keine dedizierte Product Owner Rolle, kein gemeinsames Verständnis über Aufbau und Inhalt von User Stories und keine klare Vorstellung davon, was ein Minimial Viable Product (MVP) konstituieren könnte. Die Teams waren damit ausgelastet, einerseits ihren Technologie-Stack aufzubauen und andererseits ihre redaktionelle Strategie zu definieren. Das Software-Entwicklungsteam hatte zwar bereits einen Test-Engineer eingestellt, ohne dass jedoch eine geeignete Test Strategie angewandt werden konnte, da die Voraussetzung dafür - in Form von wohldefinierten Anforderungen - nicht gegeben war.
Die Lösung
Die Projekt Teams führten einen Product Owner ein. Diese Person war dafür zuständig, die Anforderungen der Stakeholder in User Stories umzuwandeln und in einem Backlog abzubilden. Der Backlog wurde überarbeitet, priorisiert und bildete somit den Funktionsumfang des MVP ab… Ein Scrum Prozess mit Zwei-Wochen Abständen wurde eingeführt. Der Software-Testingenieur arbeitete in enger Kooperation mit den Entwicklern und unserem Test-Manager. Die Test-Strategie wurde als Mix aus automatisierten User Acceptance Tests mit Cucumber und manuellem Test-Management definiert. Sie unterstützte den Product Owner, indem sie User Stories in Form von Nutzungs-Szenarien und Testfällen auf Basis von Gherkin zusammenfasst.
Unser Beitrag
Unser Test-Manager unterstützte den Product Owner in seiner täglich Arbeit, durch Überprüfen und Umschreiben von User Stories. In einem zweiten Schritt haben wir die User Stories um wichtige Elemente erweitert, wie die Möglichkeit, Akzeptanzkriterien und User Stories in Gherkin zu schreiben. Diese User Szenarios dienten dem Software-Testingenieur als Grundlage für automatisierte User-Zulassung im Cucumber Framework.
Wir haben ein User Story Grooming eingeführt und diese so für die jeweils folgende Iteration vorbereitet. Das schaffte Zeit, die User Stories später mit dem gesamten Entwicklungs-Team einem Backlog Grooming zu unterziehen. Der Product Owner und Test-Manager bzw. Software-Ingenieur nahmen gemeinsam den Business Check und ein Iterations-Review vor. Randfälle sowie schwer zu automatisierende Testfälle wurden im Test Management Tool TestRail dokumentiert und organisiert. TestRail selbst bietet eine Jira Integration an, was jegliche Fehler mit Hilfe der Testfälle leicht reproduzierbar machte.
Vorteile
Der erzielte Hauptvorteil war die Reduktion der Arbeitslast des Product Owners, was wiederum dem ganzen Team eine verstärkte Konzentration auf seine wesentlichen Aufgabe ermöglichte - möglichst schnell, im gegebenen Kosten- und Zeitrahmen und in guter Qualität das definierte MVP zu liefern. Unser Test Manager arbeitete eng mit Product Owner und Stakeholder zusammen, um Wissenslücken zu vermeiden. Ein Nebeneffekt des Projekts war eine Test-getriebener Prozess zur Generierung von User Stories, der dabei half, insgesamt die Qualität des Backlogs und somit das Ergebnis mit jeder Iteration weiter zu verbessern. Das Team konnte die gesamte Betriebsumgebung wiederholt im Rahmen eines kontinuierlichen Release-Prozesses testen. Die in Gherkin definierten Nutzungszenarien ermöglichten die schnelle Entwicklung von Test-Automationsmechanismen. Testläufe waren mit ihren jeweiligen Ergebnissen auf einem Team-Monitor sichtbar und auch für technisch nicht so versierte Stakeholder verständlich.
Das gesamte Team einschließlich Product Owner und Stakeholder entwickelte ein hohes Qualitätsbewußtsein, wovon das Produkt insgesamt profitiert. Sowohl was Content, als auch was die Software angeht.