Release-Auswirkungen und Regressionsplanung
Beispielhafter Anwendungsfall, keine Fallstudie.
Release-Änderungen werden den betroffenen Konfigurationen, Integrationen und Tests zugeordnet; die Delivery-Leitung entscheidet über den Umfang und gibt den Go-live frei.
Das Problem
Hersteller-Releases und unsere eigenen Änderungen kommen nach einem Zeitplan, den wir nicht kontrollieren. Wir lesen die Release Notes, raten, was brechen könnte, und testen entweder alles oder das, woran wir uns erinnern. Fehler erreichen trotzdem die Nutzer.
So läuft es heute
Wenn ein Release angekündigt wird, liest ein Analyst die Notes und schreibt dem Team eine E-Mail zu allem, was relevant aussieht. Tester wählen Skripte aus einem gemeinsamen Ordner nach Erfahrung aus. Integrationspartner werden spät informiert. Nach dem Go-live werden Probleme auf Änderungen zurückgeführt, die niemand markiert hatte.
Das Szenario ansehen
Beispielhafter Arbeitsablauf. Mit Untertiteln.
Transkript
- Release Notes kommen, doch das Team rät, was zu testen ist. Übersehene Änderungen werden nach dem Go-live zu Incidents.
- Der Planer bildet Release-Änderungen auf betroffene Anwendungen und Tests ab, hebt Abdeckungslücken hervor und schlägt vor, was zu testen und wie einzuführen ist.
- Der Delivery Lead entscheidet, was getestet und was zurückgestellt wird. Der Plan wird geprüft, und die Testergebnisse entscheiden über den Go-live.
- Gemessen an Testabdeckung und durchgerutschten Fehlern. Beispielhafter Anwendungsfall. Sprechen wir über Ihren.
Vorgeschlagener Arbeitsablauf
- Release Notes und Änderungsaufzeichnungen für die Anwendungen im Umfang einlesen
- Jede Änderung auf die Konfigurationen, Anpassungen und Integrationen abbilden, die sie berühren könnte
- Betroffene Bereiche mit dem bestehenden Testbestand abgleichen und Lücken hervorheben
- Einen vorgeschlagenen Regressionsumfang und eine Einführungsreihenfolge entwerfen
- Den Plan dem Delivery Lead zur Freigabe vorlegen, bevor Tests und Einführung weitergehen
Wo ein Mensch die Kontrolle behält
- Der Delivery Lead gibt den Regressionsumfang und die Einführung frei
- Änderungen, die sich nicht zuordnen lassen, werden zur manuellen Bewertung markiert statt ignoriert
- Durchgerutschte Fehler fließen zurück in die Zuordnung und den Testbestand
Die Plattformzuordnung nennt die Umgebungen, in denen diese Idee geprüft werden kann. Die tatsächliche Umsetzung hängt von Konfiguration, Lizenzen, APIs, Daten und Berechtigungen ab. Der Nutzen wird qualitativ beschrieben; Zahlenangaben erfordern eine dokumentierte Ausgangsbasis.