Was der Abnahmetest prüft, und wer ihn durchführt
Der Abnahmetest (englisch acceptance testing) ist die letzte Teststufe vor der Inbetriebnahme einer Software. Er klärt, ob das System für den beabsichtigten Einsatz geeignet ist. Technisch orientierte Teststufen wie der Systemtest prüfen aus Herstellersicht gegen Spezifikationen. Maßgeblich ist hier die Sicht derjenigen, die das System später bezahlen, betreiben oder täglich bedienen.
Im Abnahmetest entscheidet sich, ob ein System abgenommen wird. Gegenüber den vorgelagerten Teststufen wechselt der Blickwinkel. Der Hersteller hat beurteilt, ob das System korrekt gebaut wurde. Jetzt beurteilt der Auftraggeber, ob das Richtige gebaut wurde.
In der Theorie ist der Ablauf schnell erzählt: Der Kunde testet, nickt zufrieden, der Vertrag gilt als erfüllt, alle sind glücklich. Die Praxis sieht oft anders aus. Abstürze, unklare Bedienung, Funktionen, die fehlen oder anders umgesetzt wurden als gedacht. Statt Zufriedenheit stehen dann Diskussionen im Raum, was ursprünglich wie gemeint war. Der Abnahmetest ist der Moment, in dem sich zeigt, ob die Monate davor gut genutzt wurden.
Abnahmetest und Akzeptanztest: Begriffe klären
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
Die Begriffe Abnahmetest und Akzeptanztest werden im deutschsprachigen Raum synonym verwendet. Der Abnahmetest trägt eine formale, oft vertragliche Dimension: Sein Ergebnis entscheidet, ob eine Vereinbarung zwischen Auftraggeber und Auftragnehmer als erfüllt gilt. Ein bestandener Abnahmetest kann Zahlungsmeilensteine auslösen, den Übergang in die Wartungsphase einleiten oder den Go-live freigeben.
Beide Wörter meinen dieselbe Teststufe. Das ISTQB-Glossar führt sie als Abnahmetest, die zugehörigen Kriterien heißen im Lehrplan Akzeptanzkriterien. Welches Wort ein Team wählt, ändert nichts am Prüfauftrag. Ein Projekt, das Abnahme rein vertraglich denkt, riskiert ein System, das formal abgenommen und im Alltag trotzdem umgangen wird.
Welche Formen gibt es, vom Benutzerakzeptanztest bis zum Beta-Test?
Der ISTQB-Lehrplan Foundation Level nennt sechs Hauptformen: Benutzerabnahmetest, betrieblicher Abnahmetest, vertraglicher Abnahmetest, regulatorischer Abnahmetest, Alpha-Test und Beta-Test. In den meisten Projekten tragen die ersten beiden das Gewicht.
Benutzerakzeptanztest (User Acceptance Testing, UAT), im ISTQB-Lehrplan Benutzerabnahmetest genannt, ist in meinen Projekten die häufigste Form. Repräsentative Endbenutzer testen die Software in Szenarien, die ihrem späteren Arbeitsalltag entsprechen. Das Ziel ist die praktische Tauglichkeit aus Nutzersicht; die technische Vollständigkeit war Aufgabe des Systemtests. Bestanden ist der Test, wenn die Endbenutzer bestätigen, dass sie ihre Arbeit mit der Software erledigen können.
Betrieblicher Abnahmetest (Operational Acceptance Testing, OAT) prüft die Betriebstauglichkeit aus Sicht des IT-Betriebs: Backup und Recovery, Monitoring, Wartbarkeit, Performance unter Last und die korrekte Integration in die Betriebsinfrastruktur. Projekte vergessen OAT häufig. Weil es kein fachliches Testen ist, fühlt sich auf Fachseite niemand zuständig, und seine Prüfungen rutschen oft bis in den Livebetrieb.
Vertraglicher Abnahmetest (Contract Acceptance Testing) stellt sicher, dass alle vertraglich vereinbarten Anforderungen erfüllt sind. Das Ergebnis hat unmittelbaren Bezug zu den Vertragsbestandteilen und den vereinbarten Abnahmekriterien. Die vertragliche Präzision der Anforderungen wiegt hier deshalb mehr als anderswo.
Regulatorischer Abnahmetest findet in regulierten Branchen statt: Medizintechnik, Automotive, Luftfahrt, Finanzwesen. Bevor ein System dort in Betrieb gehen darf, müssen Normen und Nachweispflichten erfüllt sein. Die Abnahme erfolgt nicht allein durch den Kunden, sondern auch durch Behörden oder Zertifizierungsstellen.
Alpha- und Beta-Testing sind Sonderformen für Produktsoftware. Alpha-Tests finden beim Hersteller mit einer kontrollierten Gruppe statt, Beta-Tests geben die Software an ausgewählte externe Nutzer in deren realer Umgebung. Beide sind weniger formalisiert als klassische Abnahmetests. Dafür liefern sie Signale zur Marktfähigkeit eines Produkts, die sich aus einer kontrollierten Testumgebung heraus kaum gewinnen lassen.
Testbasis und Testziele
Die Testbasis für den Abnahmetest sind die fachlichen Vorgaben des Auftraggebers oder Anwenders: Geschäftsprozesse, User Stories, Epics und Anwendungsfälle. Bei Migrationen kann auch die Dokumentation oder Bedienungsanleitung des Altsystems als Testbasis dienen. Oft ist das bewährte System der genaueste vorhandene Beleg dafür, wie sich das neue verhalten soll.
Ziel des Abnahmetests ist zu prüfen, ob die funktionalen und nicht-funktionalen Anforderungen aus Kundensicht erfüllt sind. Der Auftraggeber entscheidet, ob seine Konzepte so umgesetzt wurden, wie er sie sich vorgestellt hat. Das Ergebnis ist die finale Abnahme: Das Projekt endet oder geht in die Wartung über, Zahlungsflüsse werden ausgelöst, Schulungen und Produktivsetzung folgen.
Auch die nicht-funktionalen Anforderungen gehören zum Abnahmeumfang. Die Abnahme prüft Performance, Usability, Sicherheit und Verfügbarkeit vor dem Go-live, mit derselben Art von Kriterien wie die Funktionen.
Wie legt man gute Abnahmekriterien fest?
Auftraggeber und Auftragnehmer legen die Abnahmekriterien vor dem Test fest. Sie beschreiben messbar, unter welchen Bedingungen die Software als abnahmefähig gilt. Fehlende oder vage Kriterien sind eine zuverlässige Quelle für Konflikte zwischen Auftraggeber und Auftragnehmer.
„Die Software muss benutzerfreundlich sein“ taugt nicht als Abnahmekriterium, weil niemand es prüfen kann. „Alle Kernprozesse aus der vereinbarten Prozessliste müssen fehlerfrei ausführbar sein“ taugt. Ein gutes Abnahmekriterium ist konkret, nachprüfbar und eindeutig formuliert.
Zum Aufschreiben haben sich zwei Formate durchgesetzt, der ISTQB-Lehrplan Foundation Level nennt beide. Szenarioorientierte Kriterien folgen dem Gegeben/Wenn/Dann-Muster aus BDD und beschreiben einen Ablauf. Regelorientierte Kriterien sind eine Prüfliste oder eine Tabelle, die Eingaben erwarteten Ausgaben zuordnet. Zu jedem Kriterium gehört dann mindestens ein Testfall, positiv und negativ, und jeder Testfall nennt das Kriterium, das er abdeckt. Im Abnahmemeeting lässt sich das Ergebnis dann Kriterium für Kriterium durchgehen.
Weil das Ergebnis des Abnahmetests so weitreichende Konsequenzen hat, kann es bei unklaren Kriterien heiß hergehen. Die Luft in manchen Abnahmemeetings ist spürbar dick, wenn Auftraggeber und Auftragnehmer unterschiedliche Vorstellungen davon haben, was als bestanden gilt. Das ließe sich vermeiden: Kriterien früh und gemeinsam erarbeiten, statt sie erst im Streitfall zu interpretieren.
Welche Testumgebung braucht die Abnahme?
Das Testobjekt ist das integrierte Gesamtsystem, so wie es in Produktion laufen wird. Schnittstellen zu anderen Systemen sind bereits verbunden und aktiv. Die Applikation wird von außen getestet, genau so, wie die Nutzer sie später täglich bedienen werden.
Eine belastbare Aussage zum Testergebnis gibt es nur, wenn die Tests in der finalen Infrastruktur des Kunden oder in einer vollständig produktionsnahen Umgebung stattfinden. Nur dort lassen sich Inkompatibilitäten und Seiteneffekte ausschließen, die in einer abweichenden Testumgebung unsichtbar bleiben. Wird ein System zum ersten Mal produktiv gesetzt, wird gelegentlich sogar die künftige Produktivumgebung direkt für die Abnahmetests genutzt. Virtualisierungs- und Container-Technologien haben die Bereitstellung solcher Umgebungen erheblich vereinfacht und einen guten Teil des früheren Aufwands aufgelöst.
Wer erstellt die Testfälle für die Abnahme?
Fachliche Anforderungen liegen häufig in Textform vor. Aus diesen Texten sinnvolle Testfälle abzuleiten ist keine triviale Aufgabe. Schon gar nicht, wenn die Tester Fachbereichsexperten oder Endbenutzer sind, die keine Erfahrung mit strukturiertem Testen mitbringen.
Methoden wie Äquivalenzklassenbildung oder Grenzwertanalyse sind Fachbereichsexperten in der Regel unbekannt. Ebenso das Wissen, wie man Testfälle dokumentiert, strukturiert und bewertet. Eine kurze Einführung zu Beginn der Abnahmetestaktivitäten zahlt sich hier spürbar aus. Ein paar Stunden Training können die Qualität der Tests eines ganzen Fachbereichs erheblich heben.
Am tragfähigsten ist die Kombination beider Welten: strukturierte Testfallmethoden, verbunden mit erfahrungsbasierter Testfallerstellung, die die typischen Arbeitsszenarien der Nutzer abbildet. Der Fachbereich kennt seine Prozesse, die Tester kennen ihre Methoden. Gemeinsam decken sie die echten Arbeitsabläufe ab und die Grenzfälle, die erst strukturierte Verfahren sichtbar machen.
Testdaten
Die Testdaten für den Abnahmetest stellt der Auftraggeber bereit, oder er steuert sie zumindest. Anonymisierte Produktivdaten sind eine gute Wahl: Sie bilden realistische Szenarien ab und bringen die Eigenheiten echter Datenbestände mit, die sich künstlich nur schwer nachbauen lassen. Alternativ greift das Projekt auf das Testdatenmanagement aus dem Systemtest zurück. In jedem Fall müssen die Testdaten die spätere Anwenderperspektive so genau wie möglich abbilden.
Wie läuft die Abnahme ab, von der Planung bis zur Abnahmeerklärung?
Im klassischen Projekt ist die Abnahme eine Phase mit klarer Reihenfolge. Die Planung legt Umfang, Beteiligte, Termine, Umgebung und die Eingangskriterien fest: welche Teststufen abgeschlossen, welche Fehler behoben und welche Dokumente geliefert sein müssen, bevor die Abnahme beginnt. Die Vorbereitung umfasst die Abnahmekriterien, die daraus abgeleiteten Testfälle, die Testdaten und eine Einweisung der Fachtester. Die Durchführung folgt dem vereinbarten Testablauf: Jeder Testfall läuft gegen das integrierte Gesamtsystem, der Tester protokolliert das Ergebnis je Testfall und je Kriterium, und jede Abweichung wird ein Fehlerbericht mit Schweregrad.
Der Abnahmebericht führt die Ergebnisse zusammen: was die Tester abgedeckt haben, welche Kriterien erfüllt sind, welche Fehler offen bleiben und wie schwer sie wiegen, und wo das Ergebnis von der Vereinbarung abweicht. Auf dieser Grundlage trifft der Auftraggeber die Abnahmeentscheidung. Drei Ausgänge sind üblich: abgenommen, abgenommen unter Vorbehalt (offene Fehler mit vereinbarten Fristen) oder abgelehnt mit festgelegtem Nachtest. Auftraggeber und Auftragnehmer dokumentieren und unterschreiben die Entscheidung, weil sie in der Regel Zahlung, Gewährleistungsfristen und die Übergabe an den Betrieb auslöst.
Welche Schritte gelten und wie formal jeder davon ist, unterscheidet sich von Projekt zu Projekt. Regulierte Umgebungen und Festpreisverträge brauchen die volle Abfolge mit Unterschriften; ein internes Produkt kommt mit einer Demo, einer Checkliste und einer kurzen schriftlichen Notiz aus. Auch die Kurzform hält fest, wer welches Kriterium mit welchem Ergebnis geprüft hat.
Automatisierung: Einmal am Ende oder in jedem Sprint?
In klassischen Projekten läuft der Abnahmetest meist nur ein einziges Mal. Automatisierung lohnt sich dort selten, weil ein einzelner Durchlauf den Aufwand kaum wieder einspielt.
In agilen Projekten laufen Akzeptanztests in jedem Sprint, mitunter täglich. Ohne Automatisierung schafft das Team diese Frequenz nicht. Behaviour-Driven Development (BDD) verbindet die fachlichen Akzeptanzkriterien direkt mit ausführbaren Tests: In Frameworks wie Cucumber oder Robot Framework formulieren Fachexperten die Kriterien in lesbarer Sprache, das Framework führt sie automatisiert aus. Fachliche Anforderung und ausführbarer Test stehen dann im selben Text und laufen nicht auseinander. Ein eigenes Abnahmetest-Tool braucht es selten: Testfälle, Ergebnisse und Fehler liegen im Testmanagement-Werkzeug des Projekts, automatisierte Akzeptanztests in einem BDD-Framework.
Wie funktioniert die Abnahme in agilen Projekten?
In Scrum und Kanban verschiebt sich die Abnahme auf die Sprint-Ebene. Zwei Dinge verwechseln Teams dabei gern: Die Definition of Done beschreibt den Qualitätszustand, den jedes Inkrement erreichen muss, und gilt für das ganze Produkt; der ISTQB-Lehrplan behandelt sie als agilen Namen für die Endekriterien. Die Akzeptanzkriterien beschreiben, was eine einzelne User Story fachlich leisten soll. Beides braucht man, aber das eine ersetzt das andere nicht. Teams, die abnahmetestgetrieben entwickeln (ATDD), schreiben die Abnahmetests vor der Umsetzung der Story; die Tests sind dann zugleich ausführbare Anforderungen.
Kontinuierliches Feedback des Auftraggebers oder Product Owners ergänzt den klassischen Abnahmetest am Projektende und nimmt ihm den größten Teil der Last ab. Automatisierte Regressionstests sichern abgenommene Inkremente ab, und vertragliche, regulatorische und Release-Abnahmen bleiben als eigene manuelle Schritte bestehen. Der Sprint-Rhythmus hält den Abstand zwischen zwei Rückmeldungen klein, sodass der Auftraggeber Abweichungen innerhalb eines Sprints sieht.
Woran scheitern Abnahmen in klassischen Projekten?
In klassischen Projekten treten beim Abnahmetest immer wieder dieselben Schwierigkeiten auf. Nicht-funktionale Anforderungen wurden bis zur Abnahmephase nicht betrachtet und zeigen jetzt ihre Performance- oder Usability-Probleme. Lücken im Requirements Engineering kommen ausgerechnet hier zutage, mit maximalen Konsequenzen, weil kaum noch Zeit zum Nachbessern bleibt. Der Zeitdruck ist hoch, das Projekt soll bald abgeschlossen sein, die Reizbarkeit aller Beteiligten steigt entsprechend. Und den fachlichen Testern fehlen oft die Grundlagen des strukturierten Testens.
Am meisten hilft gegen diese Probleme die frühe Einbindung. Je früher Auftraggeber und Endbenutzer im Entwicklungsprozess mitarbeiten, desto weniger Überraschungen bleiben für die Abnahme übrig. Das Agile Manifest macht diese Zusammenarbeit zum Prinzip: Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
Aus der Praxis
Abnahmetests verlaufen selten so entspannt, wie es die Theorie vermuten lässt. Es gibt Projekte, in denen die Abnahme aus drei Klicks besteht und per Handschlag besiegelt wird. Und es gibt Kunden, die für ihre Abnahmen professionelle Testcenter aufbauen. Die Bandbreite ist enorm, die Konsequenzen beider Extreme sind es ebenso.