In diesem Beitrag
Software von zwei Anbietern abnehmen: Welcher Nachweis reicht?
Die Käufer hatten bezahlt. Geliefert wurde nichts. Beim Betreiber häuften sich die Supportanfragen, und ausgerechnet die eigene Software erklärte ihm, die Zahlung sei noch offen. Was soll der Support in dem Moment antworten? Den Kunden ein zweites Mal zur Kasse zu schicken, wäre die denkbar schlechteste Idee.
In diesem Fall fehlte die Konfiguration für die Zahlungsbenachrichtigung am Server. Der Vorfall zeigt, wo ich bei einer Abnahme mit mehreren Anbietern ansetzen würde. Beide können mir vorführen, dass ihr Teil läuft. Als Auftraggeber will ich wissen, was bei meinem Kunden ankommt, wenn die Teile zusammenspielen.
Welches Ergebnis kaufst du mit der Software ein?
Schreib in einem Satz auf, was ein Nutzer nach dem Release erledigen können muss. Für einen Shop wäre mein Satz: „Nach erfolgreicher Zahlung kann der Betreiber genau eine bezahlte Bestellung finden und ausliefern.“ Jetzt wissen beide Anbieter, wo die gemeinsame Vorführung endet. Der Kaufbutton, die Anzeige des Zahlungsdienstes und der Auftrag im Backend sind Stationen auf dem Weg dorthin.
Geh von diesem Ergebnis zu den vereinbarten Anforderungen zurück. Welche Versionen sollen zusammenspielen? Welche Last erwartet das Geschäft beim Start? Zehntausend Besucher über einen Monat verteilt sind ein anderes Lastprofil als zehntausend Menschen, die beim Verkaufsstart gleichzeitig bezahlen. Vor zusätzlichen Testläufen würde ich den Betreiber nach seiner tatsächlichen Prognose fragen.
Wie prüfst du eine Zahlung bis zur auslieferbaren Bestellung?
Im geschilderten Fall erreichte die Nachricht über die erfolgreiche Zahlung das Bestellsystem nicht. Das Monitoring machte die Abweichung für den Betreiber nicht sichtbar. Ein Beispiel für diese technische Abhängigkeit bietet Stripes Dokumentation zur Bestellabwicklung. Beim gehosteten Checkout kann ein Käufer den Browser schließen, bevor die Rückleitung zum Shop abgeschlossen ist. Die Verarbeitung im Backend muss diesen Fall abdecken.
Für die Abnahme würde ich eine vereinbarte Testzahlung mit den vorgesehenen Release-Versionen ausführen. Dann soll mir jemand dieselbe Transaktion beim Zahlungsdienst und die zugehörige Bestellung im Backend zeigen. Anschließend frage ich den Betrieb: Woran merkt ihr, wenn morgen wieder eine Zahlung ohne Bestellung auftaucht? Für die Fehlersuche unterscheiden etwa die Zustellinformationen zu Stripe-Webhooks erfolgreiche und fehlgeschlagene Zustellversuche. Ob danach die richtige Bestellung entstanden ist, prüfst du in deinem System. Die technischen Einzelheiten erklärt unser Video zur bezahlten, aber offenen Bestellung.
Was gehört ins gemeinsame Abnahmeprotokoll?
Eine gemeinsame Referenz reicht oft weiter als zwei lange Testberichte. Die folgenden Felder würde ich für den Checkout festhalten. Wie eine gemeinsame Prüfung bei parallel liefernden Teams organisiert sein kann, zeigt unsere separate Fallstudie zur QA über sieben Dienste. Die Tabelleneinträge beschreiben eine mögliche Prüfung. In einem echten Protokoll ergänzt das Team die beobachteten Ergebnisse und verlinkt die Belege des konkreten Laufs.
| Prüfpunkt | Was beide Anbieter zeigen | Was ins Protokoll gehört |
|---|---|---|
| Anforderung und Umfang | Eine bestätigte Zahlung führt zu genau einer auslieferbaren Bestellung. | Anforderungsnummer, beide Release-Versionen und Testumgebung. |
| Erfolgreicher Kauf | Dieselbe Transaktion vom Zahlungsdienst bis zur Bestellansicht des Betreibers verfolgen. | Testreferenz, beobachteter Bestellstatus und Link zum Nachweis. |
| Unterbrochener Ablauf | Eine Nachricht kontrolliert verzögern. Zeigen, wer den Fehler bemerkt und wie die Bestellung nachgeholt wird. | Alarm, zuständige Person, Ergebnis der Wiederholung und Prüfung auf Duplikate. |
| Entscheidung und Nachprüfung | Benennen, welches Risiko noch offen ist und wer darüber entscheidet. | Entscheidung, Verantwortlicher, offene Punkte und Termin für den nächsten Test. |
Wie viel Kontrolle verträgt eine gute Zusammenarbeit?
Ich hätte wenig davon, einem verlässlichen Entwickler die fünfte Rückfrage zu einer leicht rückgängig zu machenden Textänderung zu schicken. Das kostet Zeit und sagt ihm vor allem, dass ich seinem Urteil wenig zutraue. Bei diesem Checkout würde ich denselben Entwickler um einen wiederholbaren Ende-zu-Ende-Test bitten. Wenn er fehlschlägt, geht es um Geld, eine ausstehende Lieferung und zusätzliche Arbeit im Support.
Je nach Schaden ergänze ich den deterministischen Test um einen manuellen Durchlauf und eine Durchsicht durch einen zweiten Menschen. Bei einem kritischen Übergang würde ich auch ein KI-Modell gezielt nach Lücken in den Testannahmen suchen lassen. Ein Hinweis wie „Was passiert bei einer verspäteten Meldung?“ wird erst dann zum Nachweis, wenn jemand den Fall tatsächlich geprüft hat. Teamgröße, Unternehmensphase, bisherige Verlässlichkeit und die Kosten eines Fehlers bestimmen, wie weit ich gehe.
Für die Überwachung im Betrieb hilft die Unterscheidung in Googles Handbuch zur Systemüberwachung: Was meldet die Software intern und woran erkennt der Nutzer von außen, dass seine Bestellung funktioniert?
Wer entscheidet über Abnahme, Produktivstart und spätere Fehler?
Vor der Unterschrift würde ich drei Namen oder Rollen festhalten. Die fachliche Abnahme der Lieferung, die Entscheidung zum Produktivstart und die Betreuung des ersten Störfalls können bei verschiedenen Personen liegen. Wen ruft der Support an, wenn die nächste bezahlte Bestellung fehlt? Wenn sich beide Anbieter für ihren Teil zuständig fühlen, braucht der Betreiber trotzdem einen erreichbaren Ansprechpartner für den ganzen Vorgang.
Prüfe auch, welche Nachbesserung vereinbart ist. Gibt es beispielsweise für 30 Tage eine kostenfreie Fehlerbehebung, welche Fehler umfasst sie und wer kümmert sich anschließend um Wartung? Die Antwort steht in eurer Vereinbarung. Eine QA-Checkliste für den Produktivstart hilft bei der Vorbereitung. Was eine externe Prüfung danach beitragen kann, zeigt unser Bericht über die ersten 30 Tage externer QA.
Steht bei dir eine Übergabe an, kannst du den kritischen Ablauf in eine unabhängige Softwareprüfung mitbringen. Beschreib uns den Vorgang, bei dem eine offene Frage die Freigabe verzögert. Welcher Nachweis reicht, hängt vom Risiko, vom Team und von der bisherigen Zusammenarbeit ab.