Zusammenfassung: Der Blog-Beitrag beschreibt detailliert, wie Remote Integrationstests im Homeoffice-Team mithilfe des Accelerated Testing Package und MS Teams als Kollaborationstool durchgeführt werden können. Es bietet eine praxiserprobte Anleitung zum Aufsetzen des Verfahrens.
Im vergangenen Projekt wurden wir als Team mitten in der Testphase durch den Lockdown in die Notwendigkeit getrieben, die Tests aus den Home-Offices in Remote Zusammenarbeit fortzusetzen. Wir haben dabei aus der Not eine Tugend gemacht und unter Nutzung des Accelerated Testing-Package und MS-Teams (an dessen Stelle man sicher auch andere Collaboration Umgebungen verwenden kann) eine effektive Arbeitsumgebung für das Team aufgesetzt, in der die Tests mit unverminderter Intensität in der Remote Zusammenarbeit fortgesetzt werden konnten. Bei dem Vorgehen war jedem zu jeder zeit bewusst, was er tun muss und als Testmanager hatte ich jederzeit den Überblick über den Stand der Tests an den einzelnen Standorten. Wir haben mit der Vorgehensweise mehrere Testzyklen erfolgreich durchlaufen.
Nachfolgend finden Sie eine Beschreibung, wie das Ganze einfach und pragmatisch aufgesetzt werden kann. Folgende Komponenten spielen dabei eine zentrale Rolle:
- Das Accelerated Testing Package (eine detaillierte Beschreibung, wie dieses aufzusetzen ist, findet sich im BLOG-Beitrag 19 sowie in den entsprechende Video Erklärungen auf Loom und andere)
- Alle relevanten Testskripte werden für einen Testzyklus/Standort in einem zentralen Folder, auf den alle zugreifen können (i.e. Sharepoint) abgelegt
- Zusätzlich wird für jeden Standort einmal das Testing-Status File erzeugt, in dem der Testzyklus an dem jeweiligen Standort gemonitort wird
- Das gesamte Testing Team inklusive der an der Lösung der Defekts Beteiligten (i.e. Migration, Development, Basis etc.) ist als ein Team in MS-Teams definiert
- Für die Durchführung des Tests sind die folgenden Channel in dem MS-Teams Team wichtig:
- Ein Channel pro Test-Zyklus (und ggfs. Standort, falls die Tests standortspezifisch durchgeführt werden
- In diesem Channel gibt es zwei wesentliche Tabs: 1. Das Test-Controlboard (generiert aus der Task-Liste) (eine detaillierte Beschreibung folgt weiter unten) und 2. Eine Beschreibung aller wesentlichen Vorgehensweisen, in den einzelnen Test-Cases zu nutzenden Stammdaten und ähnlichem (eine detaillierte Beschreibung folgt weiter unten)
- Ein Channel pro Defekt-Lösungs-Team (i.e. Migration, Development, Basis etc.). Hier reicht es aus, in dem Channel eine Task-Liste anzulegen, in der der für den Arbeitsbereich Verantwortliche sich die Buckets so anlegen kann, wie es für ihn am besten zu managen ist.
- Ein Channel pro Test-Zyklus (und ggfs. Standort, falls die Tests standortspezifisch durchgeführt werden
Schlussendlich werden so alle Testing und Defekt-Lösungs-Tasks zentral in MS-Teams gemanaged. Und die Tester und die an der Lösung der Defekts Beteiligten können per Mausklick in das jeweils relevante Testskript springen, ihre Testaufgaben erledigen, den Status aktualisieren und durch Verschieben der Testaufgabe, respektive Zuweisung eines neuen Verantwortlichen den Arbeitsfluss am Laufen halten. Das Test- und Projektmanagement hat so jederzeit komplette Transparenz über den Stand der Arbeiten.
Aufsetzen des Test-Control Boards für einen Test-Zyklus:
In dem Testzyklus Channel wird ein Register auf Basis einer Task-List eingerichtet:
Für die operative Abwicklung des Tests gibt es das TEST CONTROLBOARD:
Jeder Testfall hat eine Aufgabe im Bucket des verantwortlichen end-to-end Process workstreams (siehe Beispiele RTO & PLG (anstelle von PTS) & OTC) – zugewiesene Bucket Owner verwalten die Testaufgaben; sie sind dafür verantwortlich:
- Vergabe von Start- und Fälligkeitsterminen und Sicherstellung, dass Fälligkeitstermine von anderen innerhalb ihres Arbeitsablaufs eingehalten werden
- Zuweisung der richtigen Mitglieder ihres Arbeitsablaufs zur Durchführung der Tests für neue Aufgaben in ihrem Bereich
- Sicherung der Qualität der Testdokumentation durch stichprobenartige Überprüfung konkurrierender Testskripte
Die Definition der e2e workstreams sollte klar geregelt sein – es kann z.B. folgende Systematik zugrunde gelegt werden (wie sie sich auch in dem Tab Definitions in der BPML befindet):
In der einzelnen Testaufgabe sind die folgenden Informationen abgelegt:
In den Testaufgaben zu pflegende Felder
Jeder e2e Testfall wird in einer eigenen Testaufgabe verwaltet. Pflichtfelder sind immer vollständig und korrekt auszufüllen:
- Zugewiesen (nächster Tester)
- Bucket (aktueller Test-Arbeitsablauf)
- Fortschritt (nicht begonnen, in Fortschritt,
Abgeschlossen) - Startdatum
- Fälligkeitsdatum
- Anmerkungen (Link zum xlsx-Testskript)
- Label (mit Angabe des aktuellen Status)
Bucket-Owner sind immer verantwortlich
für die Richtigkeit und Vollständigkeit
der in ihrem Bucket befindlichen Testskripte – der Zeitplan
ist unter der Verantwortung des WS, dem die e2e-Testfall (wie im Namen angegeben)
Anleitungen und Regeln für den Testablauf How-To:
Die Berechtigungsprobleme können alternativ natürlich auch analog denen der Migration in einem eigenen Channel in einer Task-List gemanaged werden.
Über ein regelmässiges Update im Teststatus.xlsx des Accelrated Testing Package kann im Detail nachgehalten werden, wie der Testfortschritt in den einzelnen Workstreams ist:
Von hier aus können per Mausklick auf die betroffene Zelle alle darin kumulierten Zeilen der beteiligten Testskripte angezeigt und ausgewertet werden und so z.B. Fehlerkumulierungen einfach erkannt und Priorisierungen in der Lösung von Bottlenecks gesteuert werden.
TAB Test-Preparation und Management
In einem weiteren Tab im Channel des jeweiligen Tests werden auf Basis eines Wiki die grundlegenden Informationen für den Test hinterlegt, wie zum Beispiel:
- Der Link auf ein Excel in dem die in den einzelnen Testcases zu verwendenden Stammdaten definiert sind
- Ein Link zu dem Teststatus Monitoring File (dieses sollte allerdings vom Testmanager per Password geschützt werden)
- Ein Link zu dem Pfad, in dem die Testskripte abgelegt sind (diesen benötigt man allerdings nicht unbedingt, da die Testskripte ja jeweils in den Testaufgaben verlinkt sind)
- Die How-To Anleitungen (s. oben)
Sollten Sie Ihre Testumgebung entsprechend der vorgenannten Beschreibung aufsetzen wollen und dabei Probleme haben, kann ich Sie gern dabei unterstützen (der Aufwand meinerseits dafür ist max. 1 bis 2 Manntage) und auch remote an einem entsprechenden Kickoff-Meeting zum Testing teilnehmen, um allfällige Fragen der Tester direkt zu beantworten – falls Sie dies wünschen, kontaktieren Sie mich gern unter .