Die Abnahme einer Anwendung sollte nicht aus zufälligem Klicken und einer losen Sammlung von Anmerkungen bestehen. Ausgangspunkt ist der vereinbarte Umfang. Danach werden die wichtigsten Szenarien festgehalten: Wer führt eine Aktion aus, welche Daten werden verwendet, welches Ergebnis wird erwartet und was soll in einer Ausnahmesituation geschehen?
Jedes Ergebnis sollte an einer Stelle dokumentiert werden. Anmerkungen müssen als Abweichung vom Umfang, Testblockade, unklare Vereinbarung oder neuer Wunsch eingeordnet werden. Erst danach lässt sich bewusst entscheiden, ob die Etappe abgenommen, unter Bedingungen abgenommen oder zur Korrektur zurückgegeben wird.
Abnahmekriterien sollten möglichst vor Beginn der Entwicklung vereinbart werden. Wurde das versäumt, können beide Seiten das erwartete Verhalten noch vor den Tests beschreiben. Dabei darf der ursprüngliche Umfang jedoch nicht stillschweigend erweitert werden.
Zuerst klären, was genau abgenommen wird
Maßgeblich ist das vereinbarte Ergebnis und nicht alles, was die Anwendung irgendwann einmal leisten könnte. Sammeln Sie Angebot, Etappenbeschreibung, bestätigte Änderungen und ausdrücklich ausgeschlossene Punkte. Wenn Vereinbarungen über mehrere Nachrichten und Dokumente verteilt sind, erstellen Sie vor der Abnahme eine gemeinsame Zusammenfassung des verbindlichen Stands.
Diese Zusammenfassung sollte enthalten:
- das Problem, das die Etappe lösen sollte;
- die enthaltenen Funktionen und Prozesse;
- Benutzer und ihre Rollen;
- notwendige Daten, Dateien und Integrationen;
- ausdrücklich ausgeschlossene Elemente;
- die Person, die über die Abnahme entscheiden darf;
- Beispiele oder Kriterien, an denen die Fertigstellung erkennbar ist.
Wird nur der erste Teil eines größeren Systems abgenommen, darf er nicht nach Funktionen bewertet werden, die erst später geplant sind. Geprüft werden muss jedoch, ob diese Etappe das im Angebot beschriebene Ergebnis liefert. Der Artikel Wie wählt man einen Entwickler für eine Webanwendung aus? zeigt, warum solche Regeln schon vor Beginn der Zusammenarbeit wichtig sind.
Abnahmeszenarien vorbereiten
Ein Abnahmeszenario beschreibt eine echte Aufgabe eines Benutzers. Es muss keine technische Dokumentation sein, sollte aber fünf Fragen beantworten:
- Wer führt die Aktion aus?
- Wie sieht der Ausgangszustand aus?
- Welche Daten werden verwendet?
- Welche Schritte werden ausgeführt?
- Welches Ergebnis soll in der Anwendung und in verbundenen Systemen erscheinen?
Notieren Sie zuerst den normalen Ablauf. Ergänzen Sie danach die wichtigsten Ausnahmen, die tatsächlich auftreten können. Je nach Lösung können das ein fehlendes Pflichtfeld, die Wiederholung einer Aktion, doppelte Daten, fehlende Berechtigungen oder ein nicht erreichbares Fremdsystem sein.
Es gibt keine allgemein richtige Zahl von Szenarien. Ein einfaches Formular braucht einen anderen Prüfumfang als ein System mit mehreren Rollen, Zahlungen und Integrationen. Die Zahl der Tests ergibt sich aus dem vereinbarten Umfang, der Bedeutung des Prozesses und den Folgen eines Fehlers.
Sichere Daten und Testumgebung vereinbaren
Vor dem Test muss geklärt werden, wo er stattfindet und welche Daten verwendet werden dürfen. Ein guter Ausgangspunkt ist eine Testumgebung mit Demonstrationsdaten oder einer passend vorbereiteten Stichprobe.
Passwörter, API-Schlüssel oder vollständige Kundendaten gehören nicht in eine gewöhnliche Tabelle mit Anmerkungen. Kann eine Aktion eine Nachricht versenden, einen Buchungsbeleg erzeugen, den Lagerbestand ändern oder eine Zahlung auslösen, muss vorher geprüft werden, ob der Test reale Folgen hat.
Dokumentieren Sie:
- Adresse oder Name der Umgebung;
- die zur Abnahme übergebene Anwendungsversion;
- Datum und ungefähre Uhrzeit des Tests;
- Rolle des verwendeten Kontos;
- Kennzeichnung des Testdatensatzes;
- aktive Integrationen und bewusst deaktivierte Funktionen.
So kann der Entwickler ein Problem nachvollziehen. Ohne diese Angaben kann dasselbe Szenario wegen einer anderen Version, Konfiguration oder Datenlage zu einem anderen Ergebnis führen.
Ergebnisse in einer Tabelle erfassen
Einzelne Screenshots in mehreren Kommunikationskanälen verlieren schnell ihren Zusammenhang. Besser ist eine gemeinsame Tabelle, in der jede wichtige Anmerkung eine verantwortliche Person und eine Entscheidung erhält.
| Feld | Was eingetragen wird |
|---|---|
| Szenario | kurze Bezeichnung des geprüften Prozesses |
| Rolle und Daten | Benutzerrolle und verwendeter Testdatensatz |
| erwartetes Ergebnis | Ergebnis aus dem vereinbarten Umfang |
| tatsächliches Ergebnis | was während des Tests wirklich geschehen ist |
| Status | bestanden, nicht bestanden, blockiert oder zu klären |
| Nachweis | Screenshot, Meldung, Vorgangs-ID oder kurze Beschreibung |
| Entscheidung | Korrektur, fehlende Daten, Konfigurationsänderung oder separater neuer Wunsch |
Die Tabelle ordnet die Kommunikation, ersetzt aber keine technischen Tests des Entwicklers. Sie ist auch kein vollständiges Sicherheits- oder Performance-Audit. Wenn diese Bereiche für die Abnahme wichtig sind, brauchen sie einen eigenen Umfang und eigene Kriterien.
Fehler, Blockade und neuen Wunsch trennen
Viele Missverständnisse entstehen, wenn alle Anmerkungen als „Fehler“ auf einer Liste landen. Vier Arten von Anmerkungen führen zu unterschiedlichen Entscheidungen.
| Art der Anmerkung | Bedeutung | Typischer nächster Schritt |
|---|---|---|
| Abweichung vom Umfang | ein vereinbartes Szenario liefert nicht das festgelegte Ergebnis | der Entwickler analysiert und korrigiert den Punkt gemäß Vereinbarung |
| Testblockade | Zugriff, Daten, Konfiguration oder ein abhängiger Dienst fehlen | die verantwortliche Person beseitigt die Blockade und der Test wird wiederholt |
| unklare Vereinbarung | die Parteien verstehen das erwartete Ergebnis unterschiedlich | Entscheidungen, Beispiele und dokumentierte Annahmen werden erneut geprüft |
| neuer Wunsch | das erwartete Verhalten gehörte nicht zur vereinbarten Etappe | Umfang, Termin und Preis werden separat entschieden |
Nicht jede Anmerkung eines Benutzers ist ein Fehler. Sie darf deshalb trotzdem nicht ignoriert werden. Jede wichtige Anmerkung sollte eine Einordnung, eine Antwort und einen nächsten Schritt erhalten.
Rollen, Berechtigungen und Ausnahmen prüfen
Der normale Ablauf reicht nicht aus, wenn eine Anwendung mehrere Benutzergruppen oder Aktionen mit wichtigen Folgen hat. Prüfen Sie bei der Abnahme zumindest die wichtigsten Grenzen:
- sehen Benutzer nur die Daten, die für ihre Rolle bestimmt sind;
- wird eine unberechtigte Aktion durch das System blockiert und nicht nur im Menü versteckt;
- führen fehlerhafte oder unvollständige Daten zu einer verständlichen Meldung;
- bleibt das System nach einem Fehler in einem sicheren und nachvollziehbaren Zustand;
- erzeugt die Wiederholung einer Aktion kein unkontrolliertes Duplikat;
- ist festgelegt, was bei einer fehlenden Antwort einer externen Integration geschieht.
Diese Prüfung ersetzt kein Sicherheitsaudit einer Webanwendung. Sie zeigt nur, ob der wichtigste Prozess dem vereinbarten Umfang folgt und offensichtliche Aktionen nicht der falschen Rolle zugänglich sind. Der technische Prüfumfang muss zur Art der Daten und zu den Folgen eines Fehlers passen.
Beispiel für ein Abnahmeszenario
Angenommen, eine Etappe soll aus einem bestätigten Kundenauftrag einen Arbeitsauftrag erzeugen. Das ist ein erfundenes Beispiel und keine Beschreibung eines fertigen Produkts oder Kundenprojekts.
| Element | Beispielhafte Vereinbarung |
|---|---|
| Rolle | berechtigter Mitarbeiter der Auftragsbearbeitung |
| Ausgangszustand | bestätigter Auftrag mit vollständigen Daten |
| Aktion | Arbeitsauftrag aus dem Kundenauftrag erstellen |
| erwartetes Ergebnis | der Arbeitsauftrag erhält Nummer, richtige Daten und vereinbarten Status |
| Wiederholung | dieselbe Aktion erzeugt kein unkontrolliertes Duplikat |
| Ausnahme | ein fehlendes Pflichtfeld führt zu einer verständlichen Meldung und keinem unvollständigen Datensatz |
Damit lässt sich das Ergebnis prüfen, ohne über die technische Umsetzung zu sprechen. Schlägt der Test fehl, ist erkennbar, ob das Hauptziel, die Wiederholung oder die Behandlung fehlender Daten betroffen ist.
Größere Projekte etappenweise abnehmen
Wer alle Tests bis zum Projektende aufschiebt, muss viele offene Fragen gleichzeitig lösen. Bei einem größeren Umfang sollten einzelne Bereiche abgenommen werden, sobald sie stabil und zuverlässig prüfbar sind.
Vor der nächsten Runde:
- frühere Anmerkungen schließen oder ihren Status dokumentieren;
- eine Anwendungsversion für die Tests festlegen;
- das korrigierte Szenario wiederholen;
- wichtige benachbarte Abläufe erneut prüfen, die von der Änderung betroffen sein könnten;
- neue Ideen auf eine getrennte Liste für spätere Entwicklung verschieben.
Wir geben nicht jedem Projekt dieselbe Methode vor. Die Abnahme muss zu Umfang, Risiko und Arbeitsweise des Kunden passen. In unserer Arbeit trennen wir das vereinbarte Ergebnis einer Etappe von späteren Ideen, damit beide Seiten anhand derselben Liste entscheiden.
Nach der Prüfung eine klare Entscheidung treffen
Eine Liste von Anmerkungen ist noch keine Entscheidung. Nach einer Abnahmerunde sollte eines von drei Ergebnissen eindeutig festgehalten werden.
Abgenommen
Die vereinbarten Kriterien sind erfüllt. Weitere Ideen oder für diese Etappe ausgeschlossene Funktionen werden für die spätere Entwicklung notiert.
Unter Bedingungen abgenommen
Es bleiben klar beschriebene Punkte, die die vereinbarte Nutzung nicht verhindern. Jeder Punkt hat einen Verantwortlichen, einen Termin oder einen festgelegten nächsten Schritt. Diese Möglichkeit sollte aus der Vereinbarung der Parteien folgen und nicht automatisch entstehen.
Der übergebene Umfang wird nicht abgenommen
Ein wichtiges vereinbartes Szenario funktioniert nicht oder kann nicht zuverlässig geprüft werden. Statt nur festzustellen, die Anwendung sei „nicht fertig“, sollten das konkrete Ergebnis, die Daten und die Bedingung für einen erneuten Test genannt werden.
Welche Wirkung die Abnahme auf Vergütung und Vertrag hat, hängt von der konkreten Vereinbarung ab. Dieser Artikel ist keine Rechtsberatung und kein Muster für ein Abnahmeprotokoll.
Vor dem Start die Betriebsbereitschaft prüfen
Ein abgenommener Umfang ist nicht automatisch bereit für eine sichere Inbetriebnahme. Klären Sie vorher:
- wer die Inbetriebnahme wann ausführt;
- ob eine aktuelle Sicherung und eine realistische Rückkehrmöglichkeit vorhanden sind;
- wer fehlende Konfigurationen, Konten und Zugänge liefert;
- welche wichtigen Vorgänge nach dem Start beobachtet werden;
- wer auf Kunden- und Entwicklerseite bei Problemen entscheidet;
- wo und zu welchen Zeiten dringende Probleme gemeldet werden.
Reaktionszeiten, Betreuungszeiten und zusätzliche Bereitschaft werden erst dann zu einer Verpflichtung, wenn sie im Angebot oder Vertrag festgehalten sind. Mehr zur Aufteilung dieser Aufgaben steht auf der Seite Wartung von Anwendungen und Online-Shops.
Ergebnis der Etappe geordnet übergeben
Vor dem Abschluss sollte bestätigt werden, was das Unternehmen neben dem Zugriff auf die funktionierende Anwendung erhält. Je nach Projekt können das sein:
- Zugang zur Anwendung, zum Repository und zu den richtigen Konten;
- Anleitungen für Benutzer oder Administratoren;
- Informationen über Abhängigkeiten, Lizenzen und externe Dienste;
- bekannte Einschränkungen und aufgeschobene Entscheidungen;
- vereinbarte Angaben zu Sicherung, Inbetriebnahme und Betreuung;
- Abnahmeergebnisse und eine Liste späterer Ideen.
Wenn die Abnahme mit einem Entwicklerwechsel oder der Übernahme eines vollständigen Systems verbunden ist, nutzen Sie die Checkliste zur Anwendungsübergabe. Sie hilft, Code, Daten, Konten, Infrastruktur und Dokumentation zu prüfen. Die eingetragenen Informationen werden nicht automatisch versendet.
Häufige Fragen
Wer sollte die Anwendung auf Unternehmensseite abnehmen?
Eine Person, die den geprüften Prozess kennt und das erwartete Ergebnis bestätigen kann. Bei wichtigeren Lösungen sollten das Wissen eines Prozessbenutzers und die Entscheidung der für den Umfang verantwortlichen Person zusammenkommen. Der Entwickler sollte nicht allein die eigene Arbeit bestätigen.
Ist eine Abnahme ohne technisches Wissen möglich?
Ja, wenn die Szenarien Benutzeraufgaben, Daten und erwartete Ergebnisse beschreiben. Eine nichttechnische Person kann den Geschäftsprozess prüfen. Tests von Code, Sicherheit, Performance und Infrastruktur brauchen jedoch einen passenden technischen Umfang.
Was tun, wenn vorher keine Abnahmekriterien festgelegt wurden?
Sammeln Sie vor den Tests bestätigte Vereinbarungen, Beispiele und Ausschlüsse. Beschreiben Sie danach gemeinsam Szenarien, die aus dem vereinbarten Umfang folgen. Ein Streitpunkt darf nicht hinter einem neuen Kriterium versteckt werden, sondern muss als zu klärender Punkt markiert werden.
Worin unterscheiden sich Fehler und neue Funktion?
Ein Fehler oder eine Abweichung liegt vor, wenn vereinbartes Verhalten nicht gemäß Umfang funktioniert. Eine neue Funktion erweitert oder verändert diesen Umfang. Zur Klärung können Angebot, bestätigte Änderungen und Beispiele aus der Planung nötig sein.
Blockiert jede Anmerkung die Abnahme?
Nein. Ihre Bedeutung hängt vom vereinbarten Ergebnis und den Folgen für die Nutzung ab. Eine wichtige Abweichung im Hauptprozess kann die Abnahme verhindern. Ein kleiner Punkt kann nach einem vereinbarten Verfahren für eine bedingte Abnahme behandelt werden.
Ersetzen Benutzertests die Tests des Entwicklers?
Nein. Die Benutzerabnahme bestätigt vor allem den Prozess aus Sicht des Unternehmens. Der Entwickler bleibt für die vereinbarten technischen Tests verantwortlich. Bei höheren Sicherheits- oder Performance-Risiken können getrennte Audits erforderlich sein.
Muss eine Anwendung mit echten Daten getestet werden?
Nicht immer. Beginnen Sie mit Demonstrationsdaten oder einer passend vorbereiteten Stichprobe. Echte Daten können bei einer kontrollierten Migration oder für besondere Fälle nötig sein. Umfang, Zugriff und Schutz müssen dann vorher vereinbart werden.
Was sollte nach der Abnahme übergeben werden?
Das hängt vom Umfang ab. Bestätigen Sie den Zugriff auf Anwendung und vereinbarte Materialien, Abnahmeergebnisse, bekannte Einschränkungen, externe Dienste sowie Informationen für Inbetriebnahme und weitere Betreuung.
Abnahme vor Beginn der nächsten Etappe festlegen
Wenn Sie eine neue Anwendung planen oder ein vorhandenes System weiterentwickeln möchten, sehen Sie sich die PHP- und Laravel-Entwicklung von Domin Software an. Im ersten Umfang legen wir Problem, Ergebnis, benötigte Daten und die Art der Prüfung fest. Ein größeres oder noch unklares Vorhaben kann zuerst mit einer Business-Analyse und MVP-Planung geordnet werden.
Bereiten Sie für das erste Gespräch eine Beschreibung des heutigen Prozesses, der Benutzer, wichtiger Daten und des Ergebnisses vor, das nach der ersten Etappe funktionieren soll. Senden Sie keine Passwörter, Schlüssel oder Kundendatenbank. Nach der Prüfung nennen wir die noch fehlenden Informationen für Umfang und Schätzung.
Quellen
- OWASP Application Security Verification Standard, OWASP, stabile Version 5.0.0 vom 30.05.2025, Zugriff geprüft am 30.10.2026.
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, veröffentlicht im Februar 2022, Zugriff geprüft am 30.10.2026.