Software-Abnahme: Prüfkriterien und Checkliste für Kunden

Was die Abnahme bestätigen muss, bevor Sie irgendetwas unterschreiben

Der häufigste Fehler bei der Abnahme von Individualsoftware ist, das Ergebnis nur in einer einzigen Dimension zu beurteilen. Die Masken funktionieren, also ist das Projekt fertig. Vier Monate später wird dasselbe Projekt erneut beurteilt, diesmal an den Kosten jeder kleinen Änderung, an der Zeit, die das Support-Team mit dem manuellen Abgleich von Datensätzen verbringt, und an der Tatsache, dass nur eine einzige Person weiß, wie man es ausrollt. Beide Urteile betreffen dieselbe Lieferung. Nur eines davon fiel zu einem Zeitpunkt, an dem Sie noch Verhandlungsmacht hatten.

Eine Lieferung kann eine Dimension bestehen und in einer anderen durchfallen, ohne dass es jemand bemerkt. Dieser Abschnitt legt das Vokabular fest, das der Rest des Artikels verwendet. Behalten Sie es im Kopf, wenn Sie die Checklisten weiter unten lesen, unabhängig davon, ob die Webentwicklung in Deutschland im eigenen Haus oder bei einem Dienstleister lag.

Fachliche Eignung, technische Qualität und Betriebsfähigkeit

Fachliche Eignung bedeutet, dass der Prozess von den Menschen, die ihn täglich ausführen, durchgängig abgeschlossen werden kann, einschließlich der Fälle, die sie ungern bearbeiten. Eine nur teilweise verfügbare Bestandsmenge, ein Kunde, der einen Sonderrabatt benötigt, eine Bestellung, die storniert wird, nachdem das Lager bereits mit der Kommissionierung begonnen hat. Der glatte Ablauf ist der einfachste Teil jedes Systems und der am wenigsten aussagekräftige Teil eines Tests.

Technische Qualität bedeutet, dass die vereinbarten Eigenschaften unter den vereinbarten Bedingungen gelten: Antwortzeit bei den Vorgängen, auf die es ankommt, Zugriffskontrolle, die einen Kunden vom anderen trennt, eine Codebasis, die eine Änderung sicher aufnehmen kann. Produktqualität ist konstruktionsbedingt mehrdimensional. Genau deshalb beschreibt das internationale Produktqualitätsmodell, veröffentlicht als ISO/IEC 25010, Qualität als eine Menge von Merkmalen statt als ein einzelnes Urteil. Wir haben die öffentliche Zusammenfassung dieser Norm gesichtet, nicht den vollständigen kostenpflichtigen Text, und erheben hier keinen Anspruch auf Konformität oder Zertifizierung. Die nützliche Erkenntnis ist struktureller Art: Wenn Ihre Abnahmekriterien nur Funktionen beschreiben, haben Sie ein einziges Merkmal festgehalten und den Rest dem Zufall überlassen.

Betriebsfähigkeit bedeutet, dass Ihre Seite das System ausrollen, überwachen, unterstützen und wiederherstellen kann. Es ist die Dimension, deren Fehlen Auftraggeber am häufigsten erst nachträglich bemerken, denn sie bleibt unsichtbar, solange der Dienstleister noch im Projekt ist und ans Telefon geht.

Was Abnahmetest, technische Bewertung und Übergabe jeweils belegen

Der Abnahmetest durch Anwender, der User Acceptance Test (UAT), beantwortet eine Frage: Funktioniert der Geschäftsprozess für die Menschen, die ihn verantworten. Er wird von Fachanwendern auf realitätsnahen Daten durchgeführt und darf ausdrücklich auch nichtfunktionale Erwartungen enthalten, etwa ob der Montagsbericht fertig ist, bevor die Vertriebsbesprechung beginnt. Der UAT ist keine Oberflächenabnahme, und ihn als solche zu behandeln ist der Weg, auf dem Unternehmen Software abnehmen, die richtig aussieht und falsch arbeitet. Über die Optik sprechen Sie mit Ihrer Webdesign Agentur vor der Umsetzung, nicht anstelle der Prozessprüfung.

Die technische Bewertung beantwortet eine andere Frage: Gelten die vereinbarten Eigenschaften, und was wird der Betrieb dieses Systems kosten. Die Systemübergabe beantwortet eine dritte: Kann unsere Seite das System überhaupt übernehmen.

Wir trennen die drei, damit Verantwortung und Nachweise klar verteilt sind, nicht weil sie im Widerspruch zueinander stünden. Der Lehrplan ISTQB Certified Tester Acceptance Testing macht denselben Punkt aus Sicht der Tester: Abnahmearbeit lebt von früher, kontinuierlicher Zusammenarbeit zwischen Business-Analysten, Product Ownern und Testern, mit Kriterien, die vor der Umsetzung definiert und nicht danach rekonstruiert werden. In der Praxis ist genau diese Zusammenarbeit das, was aus einer fachlichen Erwartung etwas macht, das zwei verschiedene Personen prüfen und übereinstimmend beurteilen können.

Jede der drei Prüfungen erzeugt eine andere Art von Nachweis: Szenarioergebnisse, freigegeben durch die Prozessverantwortlichen, Messwerte und Logs aus den technischen Prüfungen sowie ein funktionierendes Deployment, durchgeführt von einem Ihrer eigenen Techniker. Eine Lücke in einer davon ist eine Lücke in der Abnahmeentscheidung, selbst wenn die anderen beiden hervorragend aussehen.

Geschäftliche Erwartungen in Kriterien überführen, die sich wirklich prüfen lassen

Die meisten strittigen Lieferungen lassen sich auf eine Anforderung zurückführen, die als Absicht formuliert war. „Bestellungen werden über das Portal erfasst" ist eine Absicht. Zwei ehrliche Menschen können das lesen, dasselbe System ansehen und zu gegenteiligen Schlüssen darüber kommen, ob sie erfüllt ist. Der Dienstleister sieht eine Bestellung, die das ERP erreicht. Der Vertriebsmitarbeiter sieht eine Bestellung, für die immer noch ein Telefonat zur Bestätigung des Liefertermins nötig ist.

Ein Kriterium ist prüfbar, wenn jemand anderes als sein Verfasser die Prüfung durchführen und dasselbe Ergebnis erhalten kann. Das ist die ganze Messlatte. Sie erfordert keine formale Notation, kein Testwerkzeug und keine QA-Abteilung. Sie erfordert eine konkrete Bedingung, eine konkrete Handlung und ein konkretes erwartetes Ergebnis, das sich irgendwo beobachten lässt, außer im Kopf desjenigen, der es aufgeschrieben hat.

Anforderung, Prüfung und Nachweis in einer Abnahmematrix verbinden

Das mit Abstand nützlichste Artefakt der Abnahme ist eine Matrix, die jede Geschäftsanforderung mit der Art ihrer Überprüfung und mit der Person verknüpft, die über das Ergebnis entscheidet. Das ist Anforderungsverfolgbarkeit in ihrer einfachsten Form: Jede Anforderung lässt sich vorwärts zu einer Prüfung und einem Nachweis verfolgen, und jeder Nachweis lässt sich rückwärts zu einer Anforderung verfolgen. Ein Testnachweis ist ein beobachtbarer Beleg dafür, dass die Prüfung stattgefunden hat und was sie ergeben hat.

Die folgenden Zeilen stammen aus dem illustrativen Großhandelsszenario. Sie sind als Beispiel gedacht, dessen Form Sie übernehmen können, und nicht als Beschreibung eines konkreten Webdelo-Kundenprojekts.

Achten Sie darauf, was in dieser Tabelle als Nachweis zählt. Ein Screenshot einer grünen Bestätigungsseite ist die schwächste Form, denn er zeigt, was das System über sich selbst sagt. Ein Datensatz im empfangenden System und ein Eintrag im Austauschprotokoll sind stärker, denn sie zeigen, was nachgelagert tatsächlich passiert ist. Wann immer Sie die Wahl haben, bevorzugen Sie Nachweise, die vom geprüften System erzeugt werden und für jemanden lesbar sind, der die Prüfung nicht selbst durchgeführt hat.

Diese Matrix vor dem Teststart auszufüllen, verändert den Ton der gesamten Zusammenarbeit. Meinungsverschiedenheiten wandern vom Projektende, wo sie teuer und persönlich sind, an den Anfang, wo sie günstig und sachlich sind.

Kriterien rekonstruieren, die niemand festgehalten hat

Die realistische Situation ist weniger aufgeräumt: Das Projekt ist fast fertig, und niemand hat jemals Kriterien vereinbart. Das kommt häufig vor, und es lässt sich beheben. Es ist kein Grund, alles anzunehmen, was geliefert wird.

Arbeiten Sie sich in drei Schritten hindurch. Erstens: Sammeln Sie, was tatsächlich vereinbart wurde, das ursprüngliche Lastenheft, die freigegebenen Änderungsanträge, Besprechungsentscheidungen, nach denen beide Seiten gehandelt haben. Zweitens: Ordnen Sie die geschäftskritischen Vorgänge nach dem Schaden, den ihr Ausfall verursachen würde, und schreiben Sie zuerst für diese Kriterien. Im illustrativen Szenario ist diese Liste kurz: Bestellabsendung, Preisfindung und Freigabe, Übergabe ans Lager, Trennung der Kundendaten. Drittens: Nehmen Sie alles Übrige und teilen Sie es in zwei Listen, die niemals vermischt werden dürfen.

• Neue Anforderungen. Dinge, die niemand beauftragt hat. Sie mögen wertvoll und dringend sein, und sie gehören trotzdem in eine nächste Phase mit eigenem Budget.
• Strittige Erwartungen. Dinge, von denen eine Seite annahm, sie seien enthalten, und die andere nicht. Diese brauchen eine Entscheidung, kein Fehlerticket.

Die Trennung ist kaufmännisch relevant. Eine neue Anforderung als Fehler zu melden, signalisiert dem Dienstleister, dass Ihrer Fehlerliste nicht zu trauen ist, und von diesem Moment an wird über jeden echten Fehler, den Sie melden, verhandelt statt ihn zu beheben. Wenn zu Beginn nie Kriterien vereinbart wurden, ist eine strukturierte Analysephase vor der nächsten Stufe in der Regel günstiger als eine weitere Runde nachträglicher Rekonstruktion.

„Ich empfehle, Abnahmekriterien mit der Person zu besprechen, die den Prozess täglich verantwortet. In einer Anforderung wie ‚Bestellung wird erfasst' bleiben wichtige Regeln oft unsichtbar: Wer genehmigt einen Sonderrabatt, was passiert bei Teilverfügbarkeit, ab wann gilt eine Bestellung als an das Lager übergeben. Wenn diese Regeln nicht festgehalten sind, können Sie eine Funktion erfolgreich testen und trotzdem einen Prozess erhalten, den die Mitarbeitenden manuell zu Ende führen müssen."

Dmitrij Tschertschel

Architekt

Die praktische Anweisung in diesem Zitat betrifft die Frage, wen Sie befragen. Auftraggeber auf Führungsebene beschreiben den Prozess so, wie er funktionieren soll. Die Person, die ihn täglich ausführt, beschreibt die Ausnahmen, und in den Ausnahmen wohnen die ungeschriebenen Regeln. Planen Sie zwei bis drei Stunden mit dieser Person ein, bevor die Kriterien eingefroren werden, und fragen Sie sie, was sie tut, wenn etwas schiefgeht, statt was sie im Normalfall tut.

Festlegen, wer was prüft und welchen Stand er prüft

Zwei Fehlschläge sehen von außen völlig unterschiedlich aus und sind im Kern derselbe Fehlschlag. Im ersten haben alle gewissenhaft getestet, und niemand verantwortet das Urteil, also produziert das Abnahmemeeting eine Diskussion statt einer Entscheidung. Im zweiten hat jeder einen leicht anderen Stand getestet, also lässt sich ein Fehler, den gestern jemand reproduziert hat, heute nicht mehr nachstellen, und die Diskussion verlagert sich auf die Frage, ob es ihn je gab.

Beides wird durch Entscheidungen verhindert, die vor dem Teststart fallen, und beides lässt sich im Nachhinein kaum noch reparieren.

Wer validiert, wer verifiziert und wer das Restrisiko trägt

Drei unterschiedliche Verantwortlichkeiten, jede bei einer namentlich benannten Person und nicht bei einer Abteilung.

• Der Geschäftsprozessverantwortliche bestätigt, dass die Szenarien abbilden, wie tatsächlich gearbeitet wird, und dass das Ergebnis für sein Team nutzbar ist. Im illustrativen Szenario ist das die Leitung des Vertriebsinnendienstes, nicht die IT-Leitung.
• QA und das technische Team entwerfen die Prüfungen und erzeugen die Nachweise, auch die nichtfunktionalen: Messungen, Zugriffstests, Deployment-Ergebnisse.
• Ein berechtigter Manager übernimmt das Restrisiko. Restrisiko ist die bekannte, beschriebene Verwundbarkeit, die Sie bewusst zu tragen bereit sind: die Integration, die nicht gegen das echte Drittsystem geprüft werden konnte, das Lastniveau, das niemand gemessen hat, das Modul ohne automatisierte Prüfungen. Es erreicht nie null, und so zu tun als ob, schiebt es lediglich aus dem Blickfeld.

Schreiben Sie die drei Namen in den Abnahmeplan. „Die IT bestätigt das" ist kein Verantwortlicher, und in der Praxis bedeutet es, dass das Urteil von demjenigen gefällt wird, der sich am wenigsten dagegen wehren kann.

Build, Umgebung, Daten und bekannte Grenzen festschreiben

Ein Release-Kandidat ist ein bestimmter Build, der zur Abnahme vorgeschlagen wird, so eindeutig bezeichnet, dass jeder erkennen kann, ob er ihn gerade vor sich hat. Halten Sie vier Dinge fest, bevor jemand mit dem Testen beginnt.

• Der Build. Exakte Version oder Build-Kennung, die angewendete Konfiguration und der Zustand aller Feature-Flags. Wenn mitten in der Abnahme ein neuer Build auftaucht, ist das eine offen zu treffende Entscheidung und kein Ereignis im Hintergrund.
• Die Umgebung. Welche externen Systeme sind echt, welche simuliert, welche schlicht nicht verfügbar. Das bestimmt, worüber Ihr Ergebnis überhaupt eine Aussage treffen kann.
• Die Daten. Realitätsnahe anonymisierte oder synthetische Daten mit dem Volumen und den sperrigen Formen der Produktion: lange Kundennamen, Bestellungen mit vielen Positionen, abgelaufene Preislisten. Drei Zeilen mit dem Namen „Test" beweisen nichts.
• Die Grenzen. Was diese Abnahmerunde nicht abdeckt und warum. Grenzen im Voraus zu benennen verhindert, dass sie später als Vorwürfe entdeckt werden.

Das Ergebnis ist ein einseitiger Abnahmeplan: Beteiligte und ihre Rollen, der Release-Kandidat, die Umgebung, die Daten, die Eintrittsbedingungen, unter denen das Testen beginnen darf, und die bekannten Grenzen. Ohne einen fixierten Build ist ein behobener Fehler nicht überprüfbar und ein bestandener Test nicht wiederholbar, was bedeutet, dass die gesammelten Nachweise keine Entscheidung tragen können.

Vollständige Geschäftsabläufe testen, auch die unangenehmen

Ein Funktionstest fragt, ob ein Button funktioniert. Ein Szenariotest fragt, ob das Unternehmen das geschäftliche Ergebnis erhalten hat. In der Lücke zwischen diesen beiden Fragen wohnen die meisten Systeme, die abgenommen und später bereut wurden, denn jede einzelne Komponente kann Erfolg melden, während das geschäftliche Ergebnis falsch ist.

Das folgende Szenario ist illustrativ: ein Großhandelsunternehmen mit einem B2B-Portal für seine Kunden, einem ERP für Bestellungen und Bestände und einem separaten Lagersystem für Kommissionierung und Versand. Die Muster lassen sich auf andere Konstellationen übertragen, auch wenn die Systeme andere sind.

Eine Bestellung vom B2B-Portal über das ERP bis ins Lager verfolgen

Verfolgen Sie eine einzelne Bestellung über ihren gesamten Weg und prüfen Sie an jeder Station das fachliche Ergebnis. Der Kunde erfasst die Bestellung im Portal. Preisregeln greifen, einschließlich der Vertragspreise des Kunden und der Mengenstaffeln. Freigaberegeln greifen dort, wo der Rabatt die Schwelle übersteigt. Die Bestellung erreicht das ERP und wird zu einem echten Beleg mit einer echten Nummer. Das Lagersystem erhält einen Kommissionierauftrag. Status werden zurückgemeldet, sodass Kunde und Vertriebsteam denselben Zustand derselben Bestellung sehen.

Prüfen Sie an jeder Station das Ergebnis, nicht die Nachricht. Korrekte Preise im ERP, nicht bloß eine erfolgreich zugestellte Nachricht. Der Kommissionierauftrag mit den richtigen Positionen in den richtigen Mengen. Der für den Kunden sichtbare Status, der dem für den Vertriebsmitarbeiter sichtbaren Status entspricht. Nehmen Sie den Freigabezweig bewusst mit auf, denn bei Freigaben endet üblicherweise das „in der Demo hat es funktioniert": Demos werden auf dem Pfad aufgezeichnet, in dem keine Freigabe vorkommt.

Stornierungen, Wiederholungen und nicht verfügbare Integrationen

Das ist der Teil der Abnahme, der sich selbst bezahlt macht, und die einzige Stelle in dieser Checkliste, an der Integrationsausfälle behandelt werden. Arbeiten Sie ihn hier vollständig durch.

• Spät stornieren. Stornieren Sie eine Bestellung, nachdem sie das ERP erreicht hat, und dann eine weitere, nachdem die Kommissionierung bereits begonnen hat. Prüfen Sie, was danach jedes System für wahr hält: das Portal, das ERP, das Lager und die Bestandsreservierung. Eine Stornierung, die Bestand in einem System reserviert und im anderen frei lässt, erzeugt eine Woche später eine Fehlmenge, die niemand erklären kann.
• Wiederholen. Senden Sie dieselbe Bestellung zweimal ab, über einen Doppelklick, eine Seitenaktualisierung und ein Netzwerk-Timeout mit anschließendem Client-Retry. Dubletten sind der klassische Schaden im Mittelstand: Aus einem zweiten ERP-Beleg wird ein zweiter Kommissionierauftrag, daraus eine zweite physische Lieferung, und die Kosten treffen die Kundenbeziehung mindestens so hart wie das Logistikbudget.
• Die Verbindung mitten im Ablauf kappen. Nehmen Sie das ERP offline, während eine Bestellung unterwegs ist. Wird der Vorgang in eine Warteschlange gestellt und wiederholt, schlägt er laut fehl, mit sichtbarer Meldung und Verantwortlichem, oder verschwindet er still? Stiller Verlust ist das schlechteste Ergebnis und das häufigste. Bringen Sie das ERP danach zurück und prüfen Sie, dass der Austausch sich erholt und abgleicht, statt alles erneut abzuspielen und doppelt zu buchen.
• Den Teilfall prüfen. Der Bestand deckt die Hälfte der bestellten Menge. Teilt das System die Bestellung, hält es sie zurück, oder liefert es, was da ist? Wie die Antwort auch lautet, sie muss die Antwort sein, die das Unternehmen tatsächlich will, und sie muss vorher festgehalten sein.

Formulieren Sie die Folge jedes Ausfalls in Begriffen, die Ihre Geschäftsführung versteht: Bestellungen, die zwischen Systemen verloren gehen, Doppellieferungen, die auf Ihre Kosten zurückkommen, und Stunden manuellen Abgleichs pro Woche, die still und leise zur Dauerbeschäftigung von jemandem werden.

Die migrierten Daten abgleichen

Übereinstimmende Zeilenzahlen sind kein Abgleich. Eine Migration kann jede Zeile übertragen und trotzdem die Beziehungen zerstören, die den Zeilen erst Bedeutung geben. Prüfen Sie gezielt vier Dinge: die Verknüpfungen von Kunden zu Verträgen, Preislisten und Kundenrabatte, offene Bestellungen, die zum Umstellungszeitpunkt in Bearbeitung waren, und die historischen Summen, auf denen Ihr Berichtswesen aufbaut. Nehmen Sie anschließend eine Stichprobe echter Datensätze und verfolgen Sie jeden einzelnen durchgängig, vom Altsystem über das neue System bis in den Bericht, der ihn verwendet.

Halten Sie jedes Szenario auf einer Karte mit denselben fünf Feldern fest: Vorbedingungen, Handlung, erwartetes Ergebnis, tatsächliches Ergebnis, Nachweis. Zwanzig solcher Karten sind mehr wert als ein hundertseitiger Testbericht, denn jede einzelne kann von einer anderen Person auf einem späteren Build erneut ausgeführt werden.

Ein Ablauf ist abgenommen, wenn das Ergebnis in jedem beteiligten System korrekt ist, nicht wenn jedes System für sich Erfolg meldet. Dieser Unterschied ist der Unterschied zwischen einer funktionierenden Integration und einer Menge von Komponenten, die sich darauf einigen, uneinig zu sein.

Technische Eigenschaften, die darüber entscheiden, was das System Sie später kostet

Die funktionale Korrektheit entscheidet, ob Sie starten können. Die Eigenschaften in diesem Abschnitt entscheiden, was Sie in den nächsten drei Jahren zahlen, an Infrastrukturkosten, am Preis jedes Änderungsauftrags und an der Zeit, die Ihre Leute damit verbringen, das System zu umgehen. Es sind genau die Merkmale, die das Produktqualitätsmodell ISO/IEC 25010 als eigenständige Dimensionen führt: Performance-Effizienz, Sicherheit, Wartbarkeit. Sie sind schwerer zu prüfen als Funktionen, und genau deshalb werden sie meistens übersprungen.

Performance unter einer vereinbarten Last

Definieren Sie die Messung, bevor Sie irgendetwas messen: welche Vorgänge, auf welchem Datenvolumen, mit wie vielen gleichzeitigen Anwendern, zu welchem Zeitpunkt des Geschäftstages. Ein Performance-Ergebnis ohne diese vier Parameter ist eine Zahl ohne Bedeutung.

Lehnen Sie pauschale Antwortzeitvorgaben ab. „Jede Seite unter zwei Sekunden" klingt streng und entscheidet nichts, denn der richtige Zielwert ergibt sich aus dem Vorgang und dem Prozess um ihn herum. Im illustrativen Szenario zählen zwei Messungen weit mehr als alle anderen: die Bestellabsendung während des Saisonpeaks, wenn das Portal ein Vielfaches seines normalen Verkehrs trägt, und der Bericht, den das Vertriebsteam jeden Montagmorgen über zwölf Monate Historie ausführt. Wenn diese beiden auf produktionsnahen Daten halten, ist das System nutzbar. Wenn sie auf einer leeren Datenbank gemessen wurden, bedeutet die Messung nichts. Wo das Portal auch öffentliche Seiten ausliefert, wirken dieselben Antwortzeiten auf Google SEO in Deutschland, messen Sie deshalb auch den öffentlichen Teil.

Zugriffskontrolle und relevante Anforderungen an die Anwendungssicherheit

Prüfen Sie die vereinbarten Sicherheitsanforderungen, mit Vorrang für kunden- und mandantenübergreifende Zugriffe. In einem B2B-Portal ist das der Fehler mit den höchsten geschäftlichen Kosten: Ein Kunde, der die Vertragspreise eines anderen Kunden sieht, beendet Geschäftsbeziehungen. Führen Sie die Prüfung über die Oberfläche und über die API durch, denn die API ist die Stelle, an der es üblicherweise ausgelassen wird. Eine Oberfläche, die einen Button verbirgt, stoppt keine Anfrage, die die Daten direkt abruft.

Für eine strukturierte Liste von Anforderungen, aus der Sie auswählen können, ist der OWASP Application Security Verification Standard eine praxistaugliche öffentliche Referenz, mit 5.0.0 als der auf der Projektseite genannten stabilen Version. Nutzen Sie ihn, um Anforderungen passend zu Ihrem Produkt und dessen Risiko auszuwählen, und nennen Sie die Version immer dann, wenn Sie eine einzelne Anforderung in Ihren Abnahmedokumenten zitieren.

Benennen Sie die Grenze des Ergebnisses ehrlich im Abnahmeprotokoll: Eine stichprobenartige Prüfung ist ein Nachweis über das, was geprüft wurde. Sie ist niemals ein Beweis dafür, dass keine Schwachstellen existieren, und jedes Dokument, das etwas anderes suggeriert, erzeugt ein falsches Gefühl von Abgeschlossenheit.

Wartbarkeit, unterstützte Abhängigkeiten und Betriebskosten

Vier Dinge sind zu betrachten, jedes mit einer geschäftlichen Folge, die sich in einem Satz benennen lässt.

• Abhängigkeiten. Erhalten die Frameworks und Bibliotheken noch Updates, und ist eine davon bereits aus dem Support gelaufen? Eine nicht mehr unterstützte Abhängigkeit wird zu einer erzwungenen Migration nach dem Zeitplan eines anderen.
• Technische Einschränkungen. Welche absehbaren Änderungen macht der aktuelle Entwurf teuer? Ein zweites Lager, eine zweite Währung, eine zweite juristische Einheit. Stellen Sie die Frage, solange der Dienstleister noch da ist, um sie zu beantworten.
• Automatisierte Prüfungen. Ist die geschäftskritische Logik durch automatisierte Tests abgedeckt, konkret die Preisregeln, die Freigabesteuerung und der Austausch mit dem ERP? Die Abdeckung trivialen Codes ist nicht der Punkt.
• Kostenannahmen. Von welchem Datenvolumen, welchem Verkehr und welcher Aufbewahrungsdauer geht die Infrastrukturschätzung aus, und was passiert mit der Rechnung, wenn die realen Zahlen doppelt so hoch ausfallen?

Wir widersprechen der verbreiteten Praxis, Wartbarkeit an Codekommentaren und Formatierung zu bemessen. Einheitliche Formatierung ist leicht herzustellen und sagt fast nichts über die Kosten einer Änderung aus. Beurteilen Sie Wartbarkeit danach, ob eine Änderung an kritischer Logik sicher vorgenommen und überprüft werden kann, und zwar von jemandem, der den ursprünglichen Code nicht geschrieben hat.

Halten Sie das Ergebnis als technische Risikotabelle fest, eine Zeile pro Risiko, damit die Entscheidung direkt neben dem Nachweis sichtbar ist.

Jede Zeile dieser Tabelle ist eine Entscheidung, die jemand bewusst getroffen hat. Darin liegt der gesamte Wert der Dokumentation: Ein halbes Jahr später muss niemand rekonstruieren, ob ein bekanntes Problem übersehen oder bewusst akzeptiert wurde.

Prüfen, ob das System überhaupt übergeben werden kann

Systemübergabe und Startbereitschaft sind unterschiedliche Prüfungen mit unterschiedlichen Nachweisen, und sie zu vermengen ist der Weg, auf dem Unternehmen zu einem System kommen, das ihnen auf dem Papier gehört und das sie in der Praxis nicht anfassen können. Die Übergabe belegt, dass Ihre Seite die Mittel und das Wissen erhalten hat, um mit dem System zu arbeiten. Die Startbereitschaft, Thema des nächsten Abschnitts, belegt, dass Ihr Unternehmen es betreiben und seine Störungen überstehen kann.

Repositories, Servicekonten und technische Unterlagen

Überprüfen Sie den tatsächlichen Zugriff, nicht eine Liste zugesagter Zugriffe. Der Unterschied ist eine Person von Ihrer Seite, die sich anmeldet, während jemand auf den Bildschirm schaut.

• Code und Pipelines. Repository mit vollständiger Commit-Historie, nicht ein einzelner zusammengefasster Import. CI/CD-Konfiguration, Build-Pipelines, Artefakt-Registries.
• Infrastruktur und Konten. Cloud- und Hosting-Konten, Domains, TLS-Zertifikate, API-Schlüssel von Drittanbietern, Servicekonten und deren Zugangsdaten.
• Eigentum. Konten, die auf die Adressen und die Rechnungsstellung Ihres Unternehmens registriert sind, nicht auf die private E-Mail-Adresse eines Entwicklers. Das ist der Punkt, der am häufigsten Monate später entdeckt wird, im denkbar ungünstigsten Moment.
• Unterlagen. Ein Abhängigkeitsinventar, Build- und Release-Anleitungen, eine Konfigurationsreferenz, die erklärt, was jede Einstellung bewirkt, und eine Architekturübersicht, die detailliert genug ist, um eine Änderung zu planen.

Eine Software Übergabe Checkliste, die Dokumente auflistet, ohne den Zugriff zu überprüfen, beschreibt eine Absicht. Melden Sie sich bei jedem Punkt an, von Ihrem eigenen Konto aus, bevor das Engagement des Dienstleisters endet.

Lässt sich das System ohne undokumentiertes Entwicklerwissen ausrollen

Es gibt eine Prüfung, die diese Frage klärt, und sie dauert einen Nachmittag. Ein Techniker der übernehmenden Seite rollt den vereinbarten Build in einer separaten Umgebung aus, ausschließlich anhand der gelieferten Anleitungen. Keine Anrufe, kein Screensharing, kein „frag schnell Andrei, wo die Konfiguration liegt".

Halten Sie jeden Punkt fest, an dem er den Autor fragen musste. Jeder einzelne ist eine dokumentierte Lücke mit Verantwortlichem und Frist, und jeder einzelne wäre sonst bei Ihrem ersten Produktionsvorfall aufgetaucht. Die Übergabe ist abgeschlossen, wenn das Wissen übergegangen ist, nicht wenn die Anzahl der Dokumente zufriedenstellend aussieht.

„Ich würde jede Übergabe mit einer Deployment-Probe abschließen: Ein Mitglied des übernehmenden Teams rollt die vereinbarte Version in einer separaten Umgebung anhand der bereitgestellten Anleitungen aus. Wenn es den Autor fragen muss, wo eine Konfiguration zu finden ist oder welcher Schritt manuell auszuführen ist, muss diese Lücke geschlossen werden, bevor die Übergabe abgeschlossen ist. Diese Prüfung zeigt, wie gut das Betriebswissen übertragen wurde, sie belegt jedoch nicht die Qualität der Gesamtarchitektur."

Dmitrij Tschertschel

Architekt

Die ehrliche Einschränkung am Ende dieses Zitats ist es wert, festgehalten zu werden. Eine erfolgreiche Probe sagt Ihnen, dass das Betriebswissen übergegangen ist. Sie sagt nichts darüber, ob die Architektur einer Änderung standhält, die Sie noch nicht beauftragt haben. Das sind getrennte Fragen mit getrennten Nachweisen, und diese eine lässt sich zufällig günstig beantworten.

Das Unternehmen auf den Go-live und auf Störungen vorbereiten

Eine Startprüfung betrachtet Abhängigkeiten, Kapazität und Ausfallarten, bevor ein System echtes Geschäft trägt. Die Praxis wird ausführlich im Google-SRE-Kapitel über zuverlässige Produkteinführungen im großen Maßstab beschrieben, und das Prinzip lässt sich sauber herunterskalieren, auch wenn die Infrastruktur das nicht tut. Ein mittelständisches Großhandelsunternehmen importiert nicht Googles Betriebsmodell. Es übernimmt eine einzige Frage: Wovon hängt dieses System ab, was passiert, wenn jede dieser Abhängigkeiten ausfällt, und wer erfährt davon.

Supportverantwortung, Monitoring und Vorbereitung der Anwender

Drei Zusagen müssen vor dem Go-live existieren, jede mit einem Namen daran.

• Supportverantwortung. Ein benannter Verantwortlicher für eingehende Meldungen, ein funktionierender Eingangskanal, zu dem die Anwender tatsächlich Zugang haben, und eine vereinbarte Reaktionserwartung innerhalb der Geschäftszeiten. „Schreiben Sie dem Dienstleister eine E-Mail" ist kein Eingangskanal, sobald das Projekt abgeschlossen ist.
• Monitoring, das einen Menschen erreicht. Entscheiden Sie, welche Störungen wen benachrichtigen. Der konkrete Fall, für den zu entwerfen ist: Der Austausch mit dem ERP hört um 09:00 Uhr auf zu funktionieren, und jemand weiß es, bevor um 11:00 Uhr der erste Kunde anruft. Eine Warnmeldung, die in einem Postfach landet, das niemand liest, ist gleichbedeutend mit keiner Warnmeldung.
• Vorbereitung der Anwender. Anleitungen in der Sprache, in der die Menschen arbeiten, eine kurze Schulung für das Team des Prozessverantwortlichen zu den Szenarien, die es täglich durchläuft, und eine bekannte Ansprechperson für die erste Woche. Betriebsbereitschaft schließt die Menschen mit ein, und das ist der günstigste Teil davon.

Wiederherstellung proben und festhalten, was ein Rollback nicht rückgängig macht

Ein Backup, das nie zurückgespielt wurde, ist eine Annahme und keine Kontrolle. Proben Sie die Wiederherstellung in einer separaten Umgebung, stoppen Sie die Dauer, und prüfen Sie, dass die wiederhergestellten Daten tatsächlich nutzbar sind. Die Zahl, die Sie erhalten, ist die tatsächliche Grundlage Ihres Notfallplans.

Halten Sie danach fest, was die meisten Auftraggeber übersehen: Die Rückkehr zur vorherigen Codeversion setzt die Daten nicht zurück. Bestellungen, die nach dem Go-live aufgenommen wurden, geänderte Status, migrierte und bearbeitete Datensätze bleiben geändert. Ein Rollback holt die Software zurück, nicht die Woche. Definieren Sie das Rollback-Fenster ausdrücklich, benennen Sie, was nach seinem Ablauf gilt, und akzeptieren Sie, dass ab diesem Punkt der einzige Weg die Korrektur nach vorn ist.

Das Ergebnis sind zwei kurze Dokumente: ein Startplan und ein Störungsplan. Jeder benennt Verantwortliche, einen Entscheidungspunkt und eine Uhrzeit, bis zu der die Entscheidung gefallen sein muss. Ein Störungsplan, der während der Störung geschrieben wird, wird schlecht geschrieben.

Aus Prüfergebnissen eine Entscheidung über Abnahme oder Nachbesserung machen

Die Entscheidung ist kein Prozentsatz bestandener Tests. Diese Zahl ist die meistzitierte Kennzahl der Abnahme und eine der am wenigsten aussagekräftigen, denn sie gewichtet eine verrutschte Beschriftung auf einer Einstellungsmaske genauso wie eine Bestellung, die zwischen zwei Systemen verschwindet. Vierundneunzig Prozent bestanden kann eine gesunde Lieferung beschreiben oder eine unbrauchbare.

Fehler nach Geschäftswirkung einstufen, nicht nach Ticketanzahl

Fehlerschwere bedeutet hier geschäftlicher Schaden, multipliziert mit der Häufigkeit, mit der die Situation auftritt, angepasst danach, ob es eine Umgehungslösung gibt. Das ist eine geschäftliche Beurteilung und kein QA-internes Etikett. Drei Stufen, mit Beispielen aus dem illustrativen Szenario.

• Blockierend. Eine im Portal angenommene Bestellung erreicht das ERP nie, und niemand wird benachrichtigt. Das Unternehmen verliert Umsatz und Vertrauen und erfährt davon vom Kunden. Es gibt keine Umgehungslösung, die skaliert.
• Schwerwiegend. Ein Kunde kann über die API die Vertragspreise eines anderen Kunden sehen. Selten im Normalbetrieb, gravierend in der Folge, und nicht dadurch beherrschbar, dass man Anwender um Vorsicht bittet.
• Gering. Eine verrutschte Beschriftung auf einer internen Einstellungsmaske, die zweimal im Monat genutzt wird. Real, behebenswert und kein Grund, irgendetwas zu verzögern.

Eine Regel verdient es, nüchtern ausgesprochen zu werden, weil sie ständig verletzt wird: Ein ungeprüfter Bereich ist kein bestandener Bereich. Wenn niemand den Retourenprozess geprüft hat, steht im Abnahmeprotokoll, dass der Retourenprozess nicht geprüft wurde, dazu ein Verantwortlicher und ein Termin. Dort steht nicht, dass das System bestanden hat.

Korrekturen bestätigen und die Abläufe prüfen, die die Korrektur berührt hat

Das „behoben" eines Entwicklers ist eine Behauptung. Die Bestätigungsprüfung macht daraus einen Nachweis: Führen Sie die ursprünglich fehlgeschlagene Prüfung auf dem neuen Build unter den ursprünglichen Bedingungen erneut aus und halten Sie das Ergebnis fest. Idealerweise bestätigt dieselbe Person, die den Fehler gefunden hat, mit derselben Szenariokarte.

Die Regressionsprüfung deckt ab, was die Korrektur an anderer Stelle gestört haben könnte. Im illustrativen Szenario verlangt eine Korrektur an der Bestellstornierung eine erneute Prüfung von Bestandsreservierung und Statusrückmeldung ans Portal, denn alle drei berühren denselben Bestellzustand. Zu entscheiden, welche Abläufe erneut zu prüfen sind, ist eine technische Beurteilung, und sie sollte von jemandem getroffen werden, der weiß, was die Änderung berührt hat, statt von einem festen Ritual.

Halten Sie immer fest, auf welchem Build die Bestätigung lief. Ein Nachweis ohne Build-Kennung hängt in der Luft und lässt sich zwei Wochen später nicht für eine Entscheidung verwenden.

Den Abnahmestatus getrennt von der Go-live-Freigabe dokumentieren

Verwenden Sie drei technische Status und nichts Weicheres: bereit, bereit mit benannten Einschränkungen, nicht bereit. Der mittlere trägt den eigentlichen Inhalt, halten Sie deshalb zu jedem offenen Punkt fünf Felder fest: Auswirkung, Verantwortlicher, Frist, Umgehungslösung und die Bedingung, unter der erneut geprüft wird.

Die Go-live-Freigabe ist ein eigenes Dokument und eine eigene Entscheidung. Sie ergänzt, was die Abnahme nicht misst: Betriebsbereitschaft, Vorbereitung der Anwender, das Übergangsfenster und die Frage, ob das Geschäft in der gewählten Woche eine Störung verkraften kann. Eine Lieferung kann im März technisch bereit sein und erst im Mai für die Inbetriebnahme freigegeben werden, weil der März der Saisonpeak ist. Das ist eine Empfehlung zur Reihenfolge von Managemententscheidungen und keine Aussage über die rechtliche Wirkung einer Abnahmeerklärung.

Ein geprüfter Build darf legitim warten. Die beiden Dokumente getrennt zu halten, macht aus diesem Warten eine Entscheidung mit einem Verantwortlichen statt einer Verzögerung, die niemand erklären möchte.

Was nach dem ersten vollständigen Geschäftszyklus zu prüfen ist

Die Probleme, die im vierten Monat auftauchen, sind selten die, die eine Demo hätte zeigen können. Sie entstehen aus dem Volumen, aus dem Kalender und aus der konkreten Kombination von Ausnahmen, die nur echte Kunden erzeugen. Deshalb hat die Abnahme einen weiteren Kontrollpunkt nach dem Go-live.

Definieren Sie den Zyklus über das Geschäft und nicht über den Kalender. Ein vollständiger Durchlauf von der Bestellung bis zur Rechnung einschließlich Retouren, ein Monatsabschluss, ein Saisonpeak: je nachdem, welches Muster die reale Last des Unternehmens abbildet. Im illustrativen Szenario ist es der erste Monat, der sowohl einen Monatsabschluss als auch eine Aktionswoche aus dem Online Marketing Kalender des Unternehmens enthält.

Den realen Betrieb mit den Annahmen vergleichen, unter denen Sie abgenommen haben

Gehen Sie zurück zu den Annahmen, die im Abnahmeplan und in der technischen Risikotabelle festgehalten sind, und vergleichen Sie jede einzelne mit der Beobachtung.

• Welche Störungen sind tatsächlich aufgetreten, wie oft, und wie wurden sie entdeckt? Eine Entdeckung durch Kundenbeschwerde deutet auf eine Monitoring-Lücke hin, nicht nur auf einen Fehler.
• Welche Last hat das System wirklich getragen, gemessen an der Last, die getestet wurde?
• Was hat die Infrastruktur tatsächlich gekostet, gemessen an der Schätzung, und welche Annahme war falsch?
• Wo umgehen Anwender das System von Hand?

Der letzte Punkt ist das wertvollste Signal der gesamten Überprüfung. Eine Tabellenkalkulation, die jemand parallel pflegt, ein Status, der telefonisch aktualisiert wird, ein Bestellformular, das ins ERP abgetippt wird: Jedes davon lässt sich meist auf eine ungeschriebene Prozessregel genau der Art zurückführen, die die erste Experteneinschätzung beschrieben hat. Finden Sie die Regel, halten Sie sie fest, und entscheiden Sie, ob sie zur Stabilisierung oder in eine nächste Phase gehört.

Restfehler schließen und wirklich neue Bedarfe abtrennen

Erstellen Sie zwei Listen und halten Sie sie aus demselben Grund wie zuvor getrennt. Stabilisierungspunkte gehören zum gelieferten Umfang und zum laufenden Auftrag. Neue geschäftliche Bedarfe gehören in eine nächste Phase mit eigener Schätzung und eigener Entscheidung. Sie zu vermischen macht den Dienstleister bei echten Fehlern defensiv und Ihr Backlog unplanbar.

Eine gründliche Abnahme garantiert nicht, dass nichts nachgearbeitet werden muss. Systeme ändern sich, weil Unternehmen sich ändern. Was die Abnahme leistet, ist, die Zahl der Überraschungen zu senken, für die Sie zweimal zahlen, und die verbleibenden in eine Liste zu überführen, für die jemand verantwortlich ist.

Wann ein unabhängiger technischer Gutachter hinzugezogen werden sollte

Die meisten mittelständischen Unternehmen haben keine interne Fachkraft, die eine Lieferung bewerten kann, die sie nicht selbst gebaut hat. Das ist eine normale Situation und kein Führungsversagen, und einen Dritten hinzuzuziehen ist eine vernünftige Reaktion darauf.

Vier Gründe rechtfertigen eine unabhängige Begutachtung deutlich genug, um die Kosten zu vertreten.

• Sie haben keine interne technische Kompetenz in diesem Technologiestack, also kann niemand auf Ihrer Seite die Nachweise lesen.
• Das Produkt trägt ein kritisches Geschäftsrisiko oder hält Kundendaten, deren Offenlegung kaufmännisch schwerwiegend wäre.
• Die Übergabe ist komplex oder strittig, und die beiden Seiten sind sich uneinig darüber, was geliefert wurde.
• Die angebotenen Nachweise für die Bereitschaft sind dünn, nicht überprüfbar oder bestehen überwiegend aus Zusicherungen.

Eine brauchbare Begutachtung liefert fünf Dinge: den tatsächlich untersuchten Umfang, reproduzierbare Befunde mit den Schritten zu ihrer Reproduktion, die geschäftliche Folge jedes Befundes, eine Prioritätenreihenfolge, nach der Sie handeln können, und eine klare Aussage darüber, was das Ergebnis nicht abdeckt. Der letzte Punkt ist das Kennzeichen eines ehrlichen Gutachters, und dieselbe Erwartung gilt für jede angrenzende Prüfung, die Sie beauftragen, vom Penetrationstest bis zum SEO Website Audit.

Achten Sie auf die typische Fehlentwicklung. Eine Begutachtung, die sich wie eine Liste von Stilbeschwerden über den Code liest, sagt nichts über die Bereitschaft aus und belastet Ihre Beziehung zum Dienstleister ohne jeden Nutzen. Fragen Sie jeden potenziellen Gutachter, wie er jeden Befund mit einer geschäftlichen Folge verknüpfen wird, bevor Sie ihn beauftragen.

Webdelo arbeitet mit mittelständischen B2B-Unternehmen in den USA und in Deutschland an Anforderungsabstimmung, QA und technischer Bewertung gelieferter Systeme. Wenn bei Ihnen eine Abnahme in einem konkreten Projekt ansteht, sprechen wir gern über die Kriterien, die für Ihre geschäftskritischen Prozesse zählen, und über den realistischen Prüfumfang, ausgehend von den Unterlagen, die Sie bereits haben.

Häufig gestellte Fragen

Wie sollte die Abnahme bei phasenweiser Lieferung ablaufen?

Jede Phase braucht ihre eigene Abgrenzung: die Liste der Geschäftsvorgänge, die sie abdeckt, die Kriterien für diese Vorgänge und den Nachweis, der sie abschließt. Nehmen Sie jede Phase zu ihren eigenen Bedingungen ab und dokumentieren Sie die Status getrennt, damit eine Einschränkung in Phase zwei nicht still Phase eins wieder öffnet. Ergänzen Sie einen Punkt, den man leicht vergisst: Prüfen Sie die Schnittstellen zwischen den neuen Komponenten und allem zuvor Abgenommenen erneut, denn eine spätere Phase verändert häufig gemeinsam genutzte Datenstrukturen. Führen Sie vor dem Go-live mindestens eine durchgängige Prüfung über alle gelieferten Phasen hinweg durch, denn bis zu diesem Moment hat niemand das zusammengesetzte Ganze getestet.

Wie wirken sich nicht verfügbare Drittsysteme auf den Umfang des Ergebnisses aus?

Eine simulierte Integration kann belegen, dass Ihre Seite die richtige Anfrage erzeugt, die dokumentierten Antworten verarbeitet und sich bei den Fehlern korrekt verhält, mit denen sie zu rechnen hatte. Sie kann nicht belegen, dass der reale Austausch funktioniert, denn das Verhalten des echten Systems unter Last, seine tatsächlichen Fehlerformate und seine undokumentierten Eigenheiten sind genau das, was ein Simulator nicht nachbildet. Halten Sie das ausdrücklich als benannte Einschränkung im Abnahmestatus fest, nicht als bestandene Prüfung. Legen Sie anschließend eine Prüfaufgabe für den realen Austausch an, mit benanntem Verantwortlichen, Frist und definierter Prüfung, und behandeln Sie die Lücke als Restrisiko, das jemand bewusst übernommen hat, bis sie geschlossen ist.

Wovon hängt die Dauer der Abnahmetests ab?

Vier Faktoren bestimmen den Zeitrahmen: die Anzahl der geschäftskritischen Prozesse im Umfang, die Verfügbarkeit der Personen und Umgebungen, die zu ihrer Prüfung nötig sind, die Qualität der ursprünglichen Anforderungen und die Anzahl der Korrektur- und Nachprüfzyklen, die die Lieferung tatsächlich benötigt. Der letzte Faktor ist am wenigsten vorhersehbar und dominiert in der Regel, denn jeder Zyklus bringt eine Korrektur, eine Bestätigung und eine Regressionsprüfung mit sich. Es gibt keine allgemeingültige Dauer, und jede Zahl, die ohne Kenntnis Ihres Umfangs und Ihrer Anforderungen genannt wird, ist eine Vermutung im Gewand eines Terminplans. Schätzen Sie die Dauer so, wie Sie jede andere Arbeit schätzen würden: indem Sie die Prüfungen, die Beteiligten und die Zyklen auflisten, mit denen Sie realistisch rechnen.