--- title: "Softwareabnahme mit zwei Anbietern: Was prüfen?" canonical: https://wavect.io/de/blog/multi-vendor-software-acceptance-testing/ language: de description: "Zahlung erfolgreich, Bestellung fehlt. So prüfst du bei zwei Softwareanbietern den gemeinsamen Nutzerfluss und hältst die Belege im Abnahmeprotokoll fest." image: "https://wavect.io/img/blog/headers/header_multi-vendor-software-acceptance-testing.png" author: ["Kevin Riedl"] published: "2026-11-11" updated: "2026-11-11" reviewed: "2026-11-11" --- # Software von zwei Anbietern abnehmen: Welcher Nachweis reicht? [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 Min Lesezeit · 11. November 2026 Zuletzt geprüft 11. November 2026 [**Weiter**](/de/blog/external-qa-benchmark-first-30-days/) TL;DR Bitte beide Anbieter, das vereinbarte Geschäftsergebnis an einem gemeinsamen Vorgang zu zeigen. Bei einer Zahlung reicht der Nachweis bis zur auslieferbaren Bestellung. Halte fest, wer Abweichungen erkennt und behebt. Wie viel zusätzliche Kontrolle sinnvoll ist, hängt vom möglichen Schaden, der erwarteten Last und der bisherigen Verlässlichkeit der Beteiligten ab. 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](https://docs.stripe.com/checkout/fulfillment). 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](https://docs.stripe.com/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](/de/videos/stripe-payment-succeeded-order-pending-webhook/). ## 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](/de/case-studies/polity/). 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](https://sre.google/sre-book/monitoring-distributed-systems/): 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](/de/software-development-guide/software-qa-checklist-before-launch/) hilft bei der Vorbereitung. Was eine externe Prüfung danach beitragen kann, zeigt unser [Bericht über die ersten 30 Tage externer QA](/de/blog/external-qa-benchmark-first-30-days/). Steht bei dir eine Übergabe an, kannst du den kritischen Ablauf in eine [unabhängige Softwareprüfung](/de/services/software-quality-assurance/) mitbringen. [Beschreib uns den Vorgang](/de/contact/?intent=qa), bei dem eine offene Frage die Freigabe verzögert. Welcher Nachweis reicht, hängt vom Risiko, vom Team und von der bisherigen Zusammenarbeit ab. ## Häufige Fragen zur Softwareabnahme mit mehreren Anbietern ### Reichen Screenshots der beiden Anbieter als Nachweis? Sie können den Testlauf belegen, wenn sie dieselbe Transaktion auf den vorgesehenen Versionen in derselben Umgebung zeigen. Bitte um eine gemeinsame Referenz und den Beleg aus der Bestellansicht des Händlers, dass die Bestellung zur Auslieferung bereitsteht. ### Braucht die Abnahme eine echte Kundenzahlung? Beginne mit einer Testzahlung in der gemeinsamen Testumgebung und dokumentiere deren Konfiguration. Für Unterschiede zur Produktion vereinbart ihr mit dem Betreiber einen kontrollierten Startcheck. Legt vorher fest, wer das Ergebnis mit den Zahlungsdaten abgleicht. ### Welche Tests wiederholen wir, wenn ein Anbieter seine Komponente ändert? Bewahre den bisherigen Nachweis auf und markiere, welche vereinbarten Geschäftsergebnisse von der Änderung abhängen. Wiederhole den betroffenen Ablauf mit den beiden jetzt vorgesehenen Versionen und halte den beobachteten Endzustand fest. ### Reicht eine zugesagte Nachbesserung für die Freigabe? Die Vereinbarung klärt, wer unter welchen Bedingungen einen Fehler behebt. Ein Käufer mit bezahlter, fehlender Bestellung braucht trotzdem Hilfe. Prüfe die Zusage zusammen mit dem Ergebnis des durchgängigen Tests. ### Worauf kann ein kleines Team bei der Abnahme verzichten? Bei einer leicht rückgängig zu machenden Änderung mit geringen Folgen genügt oft die übliche Prüfung durch das Team. Plane zusätzliche Testzeit dort ein, wo Geld bewegt wird, viele Kunden gleichzeitig betroffen wären oder dem Support die Sicht auf Fehler fehlt. QA und Produktionsreife ## Weiterlesen Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware. [Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/) - [README ZIP Schadsoftware: Was deckt deine Freigabe ab?](/de/blog/readme-zip-malware-install-review/) - [KI-generierte Odoo-Module: Geschäftsregeln im Audit prüfen](/de/blog/ai-generated-odoo-module-audit/) - [Odoo-Migration abnehmen: Datensätze und Salden abgleichen](/de/blog/odoo-migration-acceptance-reconciliation/) - [Odoo-KI-Agenten testen: gespeicherte Aktivitäten prüfen](/de/blog/odoo-ai-agent-business-state-tests/) - [Odoo-20-Rechtemigration: Gesellschaftstrennung prüfen](/de/blog/odoo-20-company-access-migration-tests/) [Nächster Artikel**README ZIP Schadsoftware: Was deckt deine Freigabe ab?**](/de/blog/readme-zip-malware-install-review/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 Min Lesezeit · 11. November 2026 Zuletzt geprüft 11. November 2026 [**Weiter**](/de/blog/external-qa-benchmark-first-30-days/)