Acceptance Testing

Der Abnahmetest ist die letzte logische Teststufe im Softwareentwicklungsprozess und bewertet, ob ein System gut genug für den Einsatz ist. Sein Ziel ist keine Fehlersuche, sondern Vertrauen aufzubauen: Qualität soll vorher entstehen, nicht im Abnahmetest noch hineingeprueft werden. Wer früh einbindet, spart am Ende erheblich.

Das Wichtigste in Kürze

• Der Abnahmetest hat das Ziel, Vertrauen zu schaffen, nicht Fehler zu finden. Wer ihn als letzte Qualitätssicherung einsetzt, zahlt dafür die höchsten Fehlerbehebungskosten im gesamten Entwicklungsprozess.
• Tester, die von Anfang an Anforderungen mitgestalten, erhöhen die Wahrscheinlichkeit, das Richtige zu bauen, weil sie Testbarkeit, Edge Cases und nicht-funktionale Kriterien einbringen, bevor die erste Zeile Code geschrieben ist.
• Ein zu umfangreicher Abnahmetest ist meistens ein Symptom fehlender Transparenz darüber, was in vorgelagerten Stufen bereits geprüft wurde, nicht ein Zeichen von Gründlichkeit.
• Acceptance Testing im agilen Kontext und klassischer Abnahmetest verfolgen dasselbe Ziel, unterscheiden sich aber darin, wie tief der Test in den Entwicklungsprozess eingewoben ist und wie früh alle Beteiligten zusammenarbeiten.

Was ist ein Abnahmetest und wozu dient er

Ein Abnahmetest prüft aus der Perspektive des Auftraggebers, der Fachseite oder der Anwender, ob ein Testobjekt gut genug für den Einsatz ist. Er ist logisch gesehen die letzte Teststufe nach Komponenten-, Integrations- und Systemtest.

Der zentrale Unterschied zum Systemtest liegt in der Blickrichtung. Der Systemtest schaut aus der Hersteller- oder Auftragnehmerperspektive auf das integrierte System. Der Abnahmetest wechselt die Seite und nimmt die Sicht des Nutzers ein.

Anders als die vorgelagerten Teststufen ist der Abnahmetest nicht primär darauf ausgerichtet, Fehler zu finden. Er ist eine vertrauensbildende Maßnahme. Das Ziel ist im Kern, keine Fehler mehr zu finden, weil das Testobjekt das tut, was es tun soll.

Florian Fieber, Co-Autor des Buchs “Basiswissen Abnahmetest”, beschreibt den Abnahmetest als die spannendste Teststufe. An ihr lasse sich besonders gut zeigen, was man im Testen richtig oder falsch machen kann.

Abnahmetest im agilen und im traditionellen Umfeld: gleiches Ziel, andere Ausprägung

Vom Ziel her sind Akzeptanztest, Abnahmetest und Acceptance Test dasselbe. Der Unterschied liegt darin, wie gut die Aktivitäten in den Entwicklungsprozess eingewoben sind.

Im agilen Kontext ist der Abnahmetest in den Entwicklungsprozess eingebaut. Build-in-Quality, Shift-Left und die Zusammenarbeit der Rollen sind dort stärker ausgeprägt. Dadurch findet die Abnahme früher, kollaborativer und effizienter statt.

Im klassischen Wasserfall- oder V-Modell-Projekt verfolgt der Abnahmetest dasselbe Prinzip, kämpft aber mit anderen Bedingungen. Häufig findet er sehr spät statt. Anforderungsdefinition, Entwicklung und Test sind entkoppelt, und der Test kommt erst spät hinzu.

Die inhaltliche Idee bleibt identisch. Was sich ändert, ist der Wirkungsgrad: je besser die Abnahme in Prozess und Zusammenarbeit verwoben ist, desto effizienter lässt sie sich ausspielen.

Warum der Zeitpunkt über den Erfolg entscheidet

Der Zeitpunkt, zu dem Tester in den Abnahmeprozess eingebunden werden, bestimmt fast alle weiteren Möglichkeiten. Mit ihm steht und fällt, wie gut sich der Abnahmetest mit der Entwicklung verzahnen lässt.

Der schlechte Fall sieht so aus: Die Entwicklung läuft längst, die Anforderungen sind seit Langem geschrieben, an der Implementierung wird gefeilt. Erst wenige Wochen vor der Lieferung beginnt die Vorbereitung der Abnahme. Genau das willst du vermeiden.

Hier steckt ein verbreiteter Denkfehler. Der Abnahmetest ist logisch die letzte Teststufe, aber daraus folgt nicht, dass du dich auch als Letztes mit ihm beschäftigen musst.

Du musst nicht warten, bis der Systemtest abgeschlossen und die Lieferung da ist, um dann über Testplanung, Testumfang und Testfälle nachzudenken. Diese Arbeit lässt sich deutlich früher leisten.

Ist der Tester von Anfang an dabei, klinkt er sich in den Anforderungsprozess ein. Idealerweise nicht als Gast, der um Mitsprache bittet, sondern in einem Umfeld, das gemeinsames Arbeiten an Anforderungen vorsieht. Das setzt organisatorische Rahmenbedingungen voraus, die im agilen Umfeld leichter gegeben sind als in getrennten Silos.

Was eine gute Anforderung für die Abnahme ausmacht

Eine gute Anforderung ist zuerst einmal testbar. Die Testsicht muss früh in die Anforderung einfließen, damit sie überhaupt prüfbar wird.

Tester bringen dabei einen eigenen Blick mit. Sie stellen Fragen, denken um die Ecke, berücksichtigen Edge Cases und wollen genau wissen, wo die Grenze zwischen zwei Fällen verläuft. Diese Genauigkeit deckt Lücken auf, bevor Code entsteht.

Zur Testbarkeit gehört eine gewisse Vollständigkeit. Eine User Story braucht nicht nur die guten Fälle, sondern auch die Edge Cases und die negativen Fälle.

Mindestens ebenso wichtig sind die nicht funktionalen Anforderungen. Gebrauchstauglichkeit, Zugänglichkeit, Sicherheit und Performance lassen sich über geeignete Abnahmekriterien früh verankern. Hier liegt ein echter Mehrwert, den ein Tester für das Team leisten kann.

Der Idealfall: Bevor die erste Zeile Code entsteht, erarbeiten Business-Analyse, Test und Entwicklung ein gemeinsames Verständnis. Abnahmekriterien und vorab erstellte Testfälle liefern konkrete Beispiele und erhöhen die Wahrscheinlichkeit, dass das Richtige gebaut wird.

Der ideale Abnahmetest ist der, der gar nicht stattfinden muss

Ein Abnahmetest, der Qualität ins Produkt hineintestet, kommt zum schlechtesten möglichen Zeitpunkt. Genau das willst du nicht.

In der Praxis sind Abnahmetests oft viel umfangreicher als nötig. Der Grund liegt selten am Testobjekt selbst, sondern am fehlenden Vertrauen und an mangelnder Transparenz. Wer nicht weiß, was schon getestet wurde, testet sicherheitshalber noch einmal alles.

Dieses Misstrauen wächst mit der Entkopplung. Wenn ein Lieferant oder eine fremde Entwicklungsabteilung Software über den Zaun wirft, tendieren die Abnahmetests dazu, auszuufern. Am Ende wird die Qualität ganz zum Schluss hineingeprüft.

Der ideale Abnahmetest ist einer, der gar nicht stattfinden muss. Das Ziel ist, Vertrauen zu schaffen, und Vertrauen schaffe ich nicht durch Fehler finden. Die Fehler sollten vorher gefunden werden.

Florian Fieber

Das Argument lässt sich an den relativen Fehlerbehebungskosten festmachen. Der Abnahmetest ist ein schlechter Kandidat, um in dieser späten Phase noch viele Fehler aufzudecken und zu beheben. Effektiv kann er sein, als letzte Verteidigungslinie. Effizient ist er dabei nicht.

Daraus folgt nicht, dass man im Abnahmetest nicht mehr testen soll. Du testest weiter, aber das, was du testest, funktioniert. Wenn die Stufen davor sauber laufen und transparent sind, kann die Abnahme entspannt verlaufen, statt am Ende die Kuh vom Eis zu holen.

Wie Testfachlichkeit und Fachwissen im Abnahmetest zusammenkommen

Abnahmetests werden oft von Fachleuten durchgeführt, die das Produkt aus Anwenderperspektive kennen, aber keine Testexperten sind. Wie viel Testfachlichkeit nötig ist, hängt davon ab, was der Abnahmetest leisten soll.

Wenn der Abnahmetest noch ernsthaft Fehler aufdecken soll, braucht er die Kombination beider Sichten. Testverfahren, unterschiedliche Testausprägungen und geeignete Testdaten sind nicht jedem Anwender vertraut. Hier muss Testperspektive und Anwenderperspektive zusammenarbeiten.

Geht es dagegen rein um die vertrauensbildende Maßnahme, sieht es anders aus. Ein Beta-Test oder eine Form explorativen Testens kann genügen, bei der Anwender das Testobjekt in ihrer normalen Arbeit nutzen, statt formale Testfälle abzuarbeiten. Dann ist starke Testfachlichkeit nicht zwingend nötig.

Entscheidend ist auch, ob die Anwender das Testobjekt im Abnahmetest zum ersten Mal sehen oder ob sie die Entwicklung über die ganze Zeit begleitet haben. Im zweiten Fall geht es nur noch um den letzten prüfenden Blick.

Test-first als Hebel: ATDD und BDD im Abnahmetest

Test-first-Ansätze verlagern die Abnahme nach links und schärfen das gemeinsame Verständnis vor der Implementierung. Acceptance-Test-Driven Development (ATDD) und Behaviour-Driven Development (BDD) sind die zentralen Werkzeuge dafür.

Der Effekt: Testfälle, die vor der Implementierung entstehen, liefern konkrete Beispiele. Diese Beispiele erleichtern das Verständnis und unterstützen die Implementierung, weil Entwickler genauer wissen, womit sie arbeiten.

Damit das trägt, müssen die Aktivitäten der Business-Analyse und des Abnahmetests zusammengeführt werden. Die Rollen Business-Analyst und Tester bleiben unterschiedlich, gehören aber inhaltlich zusammen und sollten eng zusammenarbeiten.

Modellierung von Geschäftsprozessen und Geschäftsregeln als Testunterstützung

Modelle dienen im Abnahmetest doppelt: Sie spezifizieren das Testobjekt und liefern die Grundlage, um erwartetes Verhalten abzuleiten. Für die Geschäftsprozessmodellierung bietet sich BPMN an.

Geschäftsregeln lassen sich über DMN (Decision Modeling and Notation) und Entscheidungstabellen abbilden. Aus solchen Modellen leitest du ab, welche Pfade in einem kritischen Geschäftsprozess abgedeckt werden müssen.

Der Wert der Modellierung liegt nicht nur in der Spezifikation. Aus Testsicht hilft sie, erwartetes Verhalten zu identifizieren und gezielt jene Wege zu prüfen, die fachlich entscheidend sind.

Die folgende Übersicht ordnet die Schwerpunkte des Lehrplans Certified Tester Acceptance Testing, der dem Buch “Basiswissen Abnahmetest” zugrunde liegt: