Vom Anforderungsstapel zur datenbasierten Release-Entscheidung.
Ein SaaS-Team steht vor Release 2.4: neues Rollenmodell, Stripe-Zahlungen, Reporting. Fünf Werktage später liegt statt Meinungen ein quantifiziertes Risikobild auf dem Tisch. So sieht ein Qelivia Audit von innen aus.
Fiktives Beispielprojekt: Arbeitsweise, Artefakte und Lieferumfang entsprechen 1:1 einem echten Auftrag. Gezeigt wird ein Software-Release; derselbe Ablauf trägt auch systemübergreifende Vorhaben wie Service Transitions und Multi-Provider-Umgebungen.
Die Ausgangslage
Das Team von „TaskFlow“ liefert alle zwei Wochen ein Release, schneller, als die eigene Teststruktur mithält. Vor Release 2.4 stehen drei risikoreiche Funktionsblöcke an: ein neues Rollen- und Rechtemodell, die Zahlungsintegration über Stripe und ein Reporting-Modul. Getestet wurde bislang nach Erfahrung der Entwickler; welche Risiken tatsächlich abgedeckt sind, kann niemand belegen. Gleichzeitig kündigt der größte Kunde ein Lieferantenaudit an.
Eine Vollzeitstelle für Testmanagement ist weder budgetiert noch rechtzeitig zu besetzen. Die Frage an Qelivia: Lässt sich in einer Woche eine belastbare Entscheidungsgrundlage für den Go-live schaffen?
Das Vorgehen: fünf Tage, vier Schritte
Analyse der vorhandenen Unterlagen: 12 Anforderungen extrahiert, strukturiert und auf Lücken geprüft, ohne einen einzigen Workshop-Termin im Kundenkalender.
Risikobewertung je Anforderung (Eintrittswahrscheinlichkeit × Auswirkung). Ergebnis: vier Hoch-Risiken (Zahlungsstrecke, Mahnwesen, Rollenmodell, SSO) bestimmen die Testtiefe.
Testkonzept-Kurzfassung in ISTQB-Terminologie, Risiko-Heatmap und priorisierter Test-Backlog: Wo muss getestet werden, in welcher Reihenfolge und wer ist dafür zuständig.
Übergabe: 1-Seiten-Management-Report mit Empfehlung, Restrisiken und klaren Auflagen. Damit endet das Audit, die Entscheidungsgrundlage steht.
Das Team beauftragte anschließend den Sprint. Dort entstanden das vollständige Testkonzept, die Requirements-Traceability-Matrix und der Test-Case-Katalog mit 22 Cases, co-produziert nach dem Qelivia-Autoren-Standard; die Durchführung übernahm das Team selbst im Qelivia Test-Runner. Die Artefakte weiter unten stammen aus beiden Phasen.
„Am fünften Tag lag keine Meinung mehr auf dem Tisch, sondern ein Risikobild, eine Empfehlung und eine Liste, was vor dem Go-live zu tun ist.“
Das Ergebnis in Zahlen
Die Artefakte zum Ansehen
Alle Lieferergebnisse dieses Beispielprojekts stehen offen zum Download, genau so, wie ein echter Kunde sie erhält.
So kann ein Qelivia-Ergebnis aussehen.
Der TaskFlow-Fall zeigt anhand eines fiktiven Beispielprojekts, wie aus Anforderungen, Risiken und Testergebnissen eine belastbare Entscheidungsgrundlage entsteht.
Testmanagement as a Service →