Wie bereits im Übersichtsblog zu HERMES 2022 erläutert, gibt es eine neue Version der Projektmanagementmethode HERMES. Diese steht aktuell als Beta-Version zur Verfügung, wird aber ab 2023 final sein.
Was bedeuten die Änderungen und Erweiterungen explizit für das Testing und für die Arbeit des Testverantwortlichen und der Tester? Wir möchten dem für HERMES 2022 neuen Ansatz in diesem Blog nachgehen. Dabei werden wir den Blick auf den Einsatz im klassischen Vorgehensmodell, aber vor allem auch in der Einbettung von agiler Entwicklungsmethodik richten.
1. Änderungen am Phasenmodell
Die grundsätzlichste Änderung erfolgt auf dem Level des Phasenmodells. Diese Änderung ist möglich, da agile Entwicklungsmethodiken nun als «Blackbox» in der neuen Umsetzungsphase integriert werden können.
Schauen wir uns die einzelnen Phasen an.
1.1 Initialisierungsphase
Diese Phase existiert bereits in HERMES 5.1. In ihr wird das Projekt und vor allem dessen Ziele in den Grundzügen definiert. Neu wird auch entschieden, mit welchem Vorgehensmodell die Lösung umgesetzt werden soll: klassisch (blauer Pfad in Abbildung 1) oder agil mit der Phase Umsetzung (rötlicher Pfad).
Gemäss HERMES sind in dieser Phase noch keine Testverantwortlichen eingebunden, weder im alten noch im neuen Modell. Das bedeutet in der Praxis aber, dass das Testing weder einen «offiziellen» Einfluss auf die Wahl des Modells zur Lösungsumsetzung, noch auf das grundsätzliche Projekt Set-up hat!
1.2 Umsetzungsphase (Konzept, Realisierung, Einführung)
Falls in der Initialisierungsphase entschieden wird die Umsetzung nach dem klassischen Modell (blauer Pfad in Abbildung 1) vorzunehmen, dann gibt es für die Umsetzung gegenüber HERMES 5.1 nur wenige und eher kleine Änderungen aus der Sicht des Testing. Die Umsetzungsphase wird in dem Fall in die bereits vorhandenen Phasen Konzept, Realisierung und Einführung unterteilt. Es wird im zweiten Kapitel genauer darauf eingegangen.
Wird jedoch in der Projektinitialisierung entschieden, die Lösungsentstehung mittels einer agilen Entwicklungsmethodik in einer einzigen Phase namens Umsetzung vorzunehmen (rötlicher Pfad in Abbildung 1), dann ergeben sich komplett neue Möglichkeiten, auch aus der Sicht des Testing. Diese agile Umsetzungsphase wird detailliert im dritten Kapitel betrachtet.
1.3 Abschluss-Phase
Bei beiden Methodiken folgt nach Ende der Umsetzungsphase die Phase Abschluss. Diese Phase existierte in früheren HERMES-Versionen nicht und ist unabhängig von der Methodik. In ihr werden Abschlussarbeiten durchgeführt, die bis anhin in der letzten Phase der Einführung im klassischen Modell erfolgten. Durch die Separierung lassen sich Arbeiten in Programmen mit mehreren Projekten besser abstimmen, insbesondere wenn sowohl agile als auch klassische Projekte miteinander kombiniert werden. In der Abschlussphase erfolgt der geregelte Übergang vom Projekt- zur Anwenderorganisation, das Projekt wird abgeschlossen und die Projektorganisation aufgelöst.
Bezüglich Testing ist relevant, dass die Aufgabe Testinfrastruktur überführen neu hierhin verschoben wurde. Inhaltlich gibt es dabei nur kleine Anpassungen zu HERMES 5.1, welche im nächsten Kapitel behandelt werden.
2 Änderungen im Detail aus Sicht Testing
2.1 Szenarien
Die beiden HERMES 5.1 Standardszenarien IT-Individualanwendung agil sowie Dienstleistung/ Produkt agil werden indirekt durch die neue Phase Umsetzung ersetzt, indem die agile Entwicklungsmethodik, wie oben beschrieben, in diese neue Phase integriert wird. Da in diesen beiden früheren Szenarien jedoch nur auf die Methodik SCRUM verwiesen wurde, gab es keinerlei Vorgaben oder Hinweise, die sich auf das Testing beziehen.
2.2 Modul
Das Modul Tests ist eine Bündelung derjenigen Aufgaben und Ergebnisse, die für das Testing relevant sind. Inhaltlich gibt es hier keine Änderungen, aber in der Tabelle in Abbildung 2 ist nun die Zuordnung der einzelnen Elemente entweder zur klassischen Umsetzungsphase (blau, K: Konzept, R: Realisierung, E: Einführung) oder zur roten agilen Umsetzungsphase U sichtbar. Die Aufgabe Testinfrastruktur überführen erfolgt unabhängig von der gewählten Methodik in der Abschluss-Phase A.
Das Modul Entwicklung Agil wurde in HERMES 2022 ersatzlos gestrichen und damit auch die darin «eingebetteten» agilen Testaktivitäten nach SCRUM.
2.3 Aufgaben
Bei der Aufgabe Testkonzept erarbeiten sind neu die Grundlagen/Voraussetzungen aufgelistet. Ebenfalls sind die Aktivitäten (Testinfrastruktur mit Testsystem, Testdaten und Testhilfsmittel) beschrieben.
Neu werden in HERMES 2022 bei der Aufgabe Testinfrastruktur realisieren auch die Testdaten konkret als Bestandteil der Testinfrastruktur genannt.
Für die Aufgabe Test durchführen werden das Testen auf dem integrierten Testsystem des realisierten Produkts, die Migration, sowie das Qualitätstesten separat aufgelistet.
Die Aufgabe Testkonzept und -infrastruktur überführen der früheren HERMES-Version wurde umbenannt in Testinfrastruktur überführen.
2.4 Ergebnisse
Das im 5.1 vorhandene Ergebnis Testdaten gibt es in HERMES 2022 nicht mehr. Inhaltlich wird es in Testinfrastruktur realisiert integriert.
Das Ergebnis Testinfrastruktur realisiert wurde in HERMES 5.1 Testsystem genannt und beinhaltet neu auch die Testdaten, was auch im Beschrieb ergänzt wurde.
2.5 Rollen
Testmanager: bei der Verantwortung wird neu von Organisations- und Lösungsanforderungen gesprochen statt von Geschäfts- und Systemanforderungen.
Tester: bei der Verantwortung wird neu von Organisations- und Lösungsanforderungen gesprochen statt von Systemanforderungen.
3 Umsetzungsphase mit agiler Methodik
Die neue Umsetzungs-Phase mit agiler Methodik ist die grösste Änderung in HERMES 2022. Die Erarbeitung der Lösung kann alternativ zur oben beschriebenen klassischen Vorgehensweise neu auch auf agile Art und Weise abgewickelt werden.
Dazu gibt es in der agilen Variante von HERMES 2022 neu die Phase Umsetzung, in der das gesamte agile Entwicklungsvorhaben als «Blackbox» eingebettet wird, siehe Abbildung 1. Das heisst, die vollständige Lösungsumsetzung kann in einem komplett von HERMES unabhängigen Vorgehensmodell iterativ-inkrementell vorgenommen werden, da diese gekapselt wird. Da es abgesehen von optionalen aber empfehlenswerten Release-Freigaben (siehe unten) keine Berührungspunkte der Vorgehensmodelle HERMES und Agil gibt, kann so jegliches Modell, z.B. Scrum, SAFe, etc. als Blackbox integriert werden. HERMES gibt hierzu bewusst keinerlei Vorgaben oder Detailinformationen.
Das heisst, es gibt bei agilem Vorgehen in HERMES eigentlich zwei Layer des Projekts: auf dem oberen Layer gibt es das Projektmanagement mit den Phasen Initialisierung, Umsetzung, Abschluss sowie den Rollen Auftraggeber, Projektleiter und Anwendervertreter (die als Schnittstelle zum Entwicklungsteam dient).
Innerhalb des agilen Entwicklungsvorhabens, d.h. einen Layer «tiefer», gibt es dann die Inkremente und Rollen gemäss agilem Modell, z.B. Product Owner und Scrum Master bei Scrum oder Release Train Engineer, Produkt Manager und System Architekt bei SAFe.
3.1 Was bedeutet dies im Vergleich zum klassischen Vorgehen in der Vergangenheit?
Alle Tätigkeiten des Moduls Tests, die bisher in den Phasen Konzept, Realisierung oder Einführung vorgesehen waren (Abbildung 1), werden nun innerhalb des agilen Umsetzungsvorhabens abgewickelt.
Die Aufgaben Testkonzept erarbeiten, Testinfrastruktur realisieren sowie Tests durchführen wie auch ihre Ergebnisse Testinfrastruktur realisiert, Testkonzept sowie Testprotokoll werden nun vollständig und autonom innerhalb des agilen Umsetzungsvorhabens erledigt. Aus dem Grund gibt es dazu in HERMES keinerlei Vorgaben oder Hinweise. Lediglich die Aufgabe Testinfrastruktur überführt wird nicht innerhalb des agilen Vorhabens, sondern in der Abschlussphase des HERMES-Projekts erledigt.
Innerhalb der Umsetzungsphase gibt es optionale Releasefreigaben. Diese dienen als Meilensteine bzw. Quality Gates, um die Einhaltung der Projektvorgaben sowie die Übereinstimmung des Projekts mit den strategischen Zielen der Stammorganisation zu überprüfen.
Zu beachten ist, dass jede der durch solche Releasefreigaben getrennten Teilphasen (bzw. Releases) sämtliche Aufgaben und Ergebnisse der gesamten Umsetzungs-Phase enthalten muss (Abbildung 5). Bezogen auf das Testing bedeutet das, dass hier jeweils die Testinfrastruktur realisiert, das Testkonzept (inklusive der Testfall-Erstellung) definiert und die Testfälle durchgeführt werden müssen.
Der Aufbau der Testinfrastruktur wird üblicherweise im Release 1 im Fokus stehen. In den nachfolgenden Releases wird der Aufbau vermutlich nur noch kleinere Anpassungen erfahren.
Das Testkonzept inklusive Vorgehen wird üblicherweise auch primär im ersten Release erarbeitet. Es sollte aber im Sinne der agilen Verbesserung fortlaufend optimiert und ergänzt werden. Die Testfallerstellung, die Bestandteil der Aufgabe Testkonzept ist, ist eine fortlaufende Aufgabe. In jedem Release muss sie wieder für die neu erstellte Funktionalität definiert werden, mitsamt Ergänzungen oder Anpassungen der Regressionstests.
Vor- und nachgelagerte (d.h. releaseübergreifende) Aufgaben, wie z.B. die Vorbereitung des Backlogs sind hier nicht abgedeckt. Diese müssen durch das agile Vorhaben selbstständig berücksichtigt werden.
Für die jeweilige (optionale) Releasefreigabe am Ende jedes Release-Inkrements sind die Ergebnisse des Testing folglich zentrale Kriterien für den Entscheid der Freigabe. Das ist vergleichbar mit dem Entscheid der Phasenfreigabe beim Übergang zur Phase Realisierung bzw. Einführung der früheren HERMES Version.
4 Fazit
Aus der Sicht des Testing ist die Situation in HERMES 2022 etwas paradox: Einerseits gibt es kaum Änderungen an dem Modul Tests mit den testbezogenen Aufgaben und Ergebnissen, vor allem wenn weiterhin nach dem klassischen Vorgehen entwickelt wird. Andererseits ändert sich – bei der Wahl einer agilen Umsetzungsphase – praktisch die gesamte Vorgehensweise. Dies, weil fast alle Testing-Aufgaben komplett innerhalb des gekapselten agilen Vorgehens umgesetzt werden und nur bei den optionalen Meilensteinen Ergebnisse aus dem Testing in das Gesamtprojekt «zurückfliessen».
Das bedeutet, dass die «Verantwortlichkeit» für das Testing sich grundsätzlich vom HERMES-Projekt in das agile Umsetzungsvorhaben verschiebt. Damit steht und fällt das erfolgreiche Testing komplett mit der Umsetzung im agilen Vorgehen. Es dürfte vor allem in Projektteams, die wenig Erfahrung mit agilen Vorgehensweisen besitzen, zu Schwierigkeiten führen, zumal die beiden am häufigsten verwendeten agilen Vorgehensweisen SCRUM und SAFe berüchtigt sind für sehr «vage», d.h. wenig konkrete «Vorgaben» bezüglich des Testings.
- Den Test-Managern, Testern oder Team-Mitgliedern empfehlen wir bei der Anwendung von HERMES 2022 mit agilem Umsetzungsvorgehen dringend die Themen, die im SwissQ Agile Testing Framework behandelt werden zu beachten. Zudem ist es wichtig, dass die konkrete Anwendung der Testing-Aktivitäten dem vorhandenen Umfeld und den Bedürfnissen angepasst wird.
- Die Verwendung des Agilen Testing Canvas könnte zudem helfen, den Fokus im Testing richtig zu setzen und vor allem im gesamten Team ein gemeinsames Verständnis für die verschiedenen Testing-Aktivitäten und Verantwortlichkeiten zu entwickeln.
- Bei den SwissQ-Blogs zum Testing findest du viele relevante Beiträge, die erläutern, wie in agilen Projekten besser getestet werden kann.
Weitere Blogs, in welchen wir die Änderungen in HERMES 2022 bezüglich der agilen Vorgehensweise in der IT-Entwicklung oder IT-Adoption aus Sicht der «ART of SwissQ» – Agile, Requirements und Testing – näher betrachtet werden, findest du hier.