Antwort.

Die Organisation des manuellen Testings in der Release-Phase ist ein Maßnahmenpaket zur schnellen und effektiven Auffindung von Defekten in der für den Rollout vorbereiteten Produktversion, mit Fokus auf die kritischsten und am häufigsten verwendeten Funktionen.

Hintergrund: Früher waren Releases oft von "Nachtwachen" begleitet: Tester eilten, um alles zu überprüfen, was die Qualität des Testings beeinträchtigte, Bugs "schlüpften" in die Produktion, Ressourcen wurden ineffizient genutzt. Im Laufe der Zeit wurde erkannt, dass eine klare Systematisierung der Prioritäten größere Ergebnisse in kürzerer Zeit erzielt.

Problem: Die begrenzte Zeit für Tests vor einem Release erlaubt es nicht, alles zu überprüfen, und der menschliche Faktor nimmt zu – Müdigkeit, Eile, Stress. Häufig tauchen kritische Bugs erst nach dem Rollout auf, was den Ruf des Produkts untergräbt und Chaos im Team verursacht.

Lösung:

Gemeinsam mit dem Geschäft, Analysten und der Entwicklung kritische und geschäftlich relevante Szenarien bewerten.
Eine Release-Checkliste mit den sogenannten "kritischen" Szenarien erstellen – jene, die am häufigsten verwendet oder risikobehaftet sind.
Finale Smoke- und Sanity-Tests manuell durchführen: Überprüfen des Systemstarts, des Login-Prozesses, der Bestellabwicklung, der Zahlungsabwicklung usw.
Verantwortungsbereiche klar abgrenzen: Wer ist verantwortlich für Testdaten, wer für Berichte über gefundene Defekte, wer für die Kommunikation mit der Entwicklung.

Wesentliche Merkmale:

Priorisierung von Bugs: Kritische Bugs zuerst finden und eskalieren.
Verwendung kurzer, schnell ausführbarer Testfälle und Checklisten.
Schnelle Kommunikation mit dem Entwicklungsteam für ein zügiges Bugfixing.

Fangfragen.

Kann man sich "absichern" und die gesamte Anwendung manuell vor dem Release testen?

Nein, normalerweise gibt es keine Zeit für vollständiges manuelles Testing – ein ausgewogener Ansatz mit Fokus auf die Schlüssel-Szenarien liefert bessere Ergebnisse.

Sollte man vor dem Release "kleine" Bugs melden, damit das Team im Voraus darüber informiert ist?

Nein, im Release-Modus sollten nur kritische und blockierende Defekte eskaliert werden, während weniger bedeutende als bekannte Probleme dokumentiert und nach dem Rollout bearbeitet werden.

Ist es unbedingt erforderlich, detaillierte Testfälle manuell für die Release-Phase zu schreiben?

Nein, oft ist es einfacher und schneller, mit Checklisten oder Mini-Skripten, die von Testfällen abgeleitet sind, zu arbeiten, was eine schnelle Durchsicht der relevanten Szenarien ermöglicht.

Typische Fehler und Anti-Patterns

Das Testen bis zur letzten Stunde aufschieben – was alles in Eile und mit Qualitätsverlust erledigt wird.
Überprüfung seltener oder unwichtiger Szenarien zum Nachteil der Schlüssel-Szenarien.
Fehlendes finales Smoke/Sanity Testing direkt vor dem Release.

Beispiel aus dem Leben

Negativer Fall

Die Release-Tests werden nachts durchgeführt, während gleichzeitig Tabellen flüchtig geprüft werden, was dazu führt, dass ein kritischer Zahlungsablauf vergessen wird. Am nächsten Tag können die Benutzer massenhaft ihre Bestellungen nicht bezahlen.

Vorteile:

Hohe Geschwindigkeit der Überprüfung.

Nachteile:

Kritischer Bug bleibt unentdeckt.
Risiken durch Stress in der Nacht, verpasste Kommunikation mit der Entwicklung.

Positiver Fall

Vor dem Release liegt der Fokus nur auf kritischen Szenarien (Login, Zahlung, Bestellaufzeichnung, Integration mit Partnern). Die Ergebnisse werden anhand der Checkliste überprüft, Bugs werden sofort eskaliert.