Abnahmetest oder Akzeptanztest

Der Abnahme- oder auch Akzeptanztest ist die oberste der Teststufen. Die Theorie sagt, dass hier der Kunde testet und mit einem Lächeln im Gesicht feststellt, wie wunderbar all seine Anforderungen umgesetzt sind. Dann gibt er sein ok, der Vertrag ist erfüllt und alle sind zufrieden.

In der Praxis sieht das meist leider etwas anders aus. Abstürze, unklare Bedienung, fehlende oder falsche Funktionen. Statt einem zufriedenen Lächeln gibt es Wutausbrüche, Frustration und Streit darüber, was wie gemeint war.

Eine Möglichkeit das zu verhindern, ist die vorherigen Teststufen wie Unittest, Integrationstest und Systemtest ausreichend zu nutzen. Oder aber den Kunden so früh wie möglich mit einzubinden. Genau das ist auch ein maßgeblicher Treiber für agile Methoden und agiles Testen. Frühe, kurze Feedbackschleifen und Reviews durch den Kunden und Anwender. All das trägt dazu bei, dass am Ende nicht das böse Erwachen kommt.

Definition Abnahmetest

Das ISTQB definiert Abnahmetest als: “Eine Teststufe mit dem Schwerpunkt zu bestimmen, ob ein System abgenommen werden kann.”

Ob diese Definition hilfreich ist, darf jeder selbst entscheiden. Im Kern ist der Unterschied zu vorherigen Teststufen, dass nun der Kunde oder Anwender als Tester fungiert. Das bringt natürlich eine neue Perspektive auf das Testobjekt und damit neue Fragen, Meinungen und Ideen.

Bei Projekten, die nun nicht auf einer Kundenumgebung laufen, z.B. einer mobilen App für den Consumer-Markt, kommen hier häuft Alpha- oder Beta-Tests zum Einsatz.

Testbasis

Als Testbasis für den Abnahmetest dienen die fachlichen Vorgaben des Kunden, Auftraggebers oder Anwenders. Beispiele sind Geschäftsprozesse, User Stories, Epics, Anwendungsfälle, etc.

Bei Migrationen dient manchmal auch die Bedienungsanleitung oder Dokumentation des Alt-Systems als Testbasis.

Da es hier häufig auch um die vertragliche Abnahme geht, hat die Entscheidung, ob ein Test erfolgreich ist oder nicht, weitreichende Konsequenzen.

Ebenso wichtig ist es, hier auch nicht-funktionale Anforderungen zu prüfen und deren Umsetzung zu bestätigen, z.B. durch einen betrieblichen Abnahmetest.

Testfallerstellung für Abnahme- bzw. Akzeptanztest

Fachliche Anforderungen liegen häufig in Textform vor. Wie kann man aus diesen Anforderungen nun Testfälle erstellen? Ähnlich wie beim Systemtest kombiniert man am besten strukturierte Testfallmethoden mit erfahrungsbasierter Testfallerstellung.

Ein Problem dabei ist, dass der Kunde oder Anwender die strukturierten Testmethoden wie Äquivalenzklassenbildung, Grenzwertanalyse oder Entscheidungstabellen nicht kennt. Auch fehlt hier häufig Wissen, wie Testfälle dokumentiert, strukturiert und abgearbeitet werden. Es hat sich bewährt, zu Beginn der Testaktivitäten ein kleines Training anzusetzen, um dieses grundlegende Wissen zu vermitteln. Ein paar Tipps und Ideen genügen schon, um die Qualität der Tests eines Fachbereichs massiv zu erhöhen.

Testobjekt

Das Testobjekt für den Akzeptanztest ist das integrierte Gesamtsystem. Die Applikation wird von außen geprüft, in der Regel so wie es künftig die Anwender tagtäglich tun werden.

Schnittstellen sind dazu schon integriert und mit den anderen System verbunden. Ziel ist es, ganz nahe am späteren Produktivstand zu testen.

Testziele des Abnahmetests

Das Ziel des Abnahmetests ist es, zu prüfen, ob die funktionalen und nicht-funktionalen Anforderungen an die Applikation erfüllt und ausreichend umgesetzt sind. Und zwar aus Kundensicht. Dieser entscheidet schlussendlich ob seine Ideen und Konzepte so umgesetzt wurden, wie er sich das vorgestellt hat.

Das Ergebnis des Abnahmetests ist die finale Abnahme. Dadurch ist z.B. das Projekt beendet und geht in die nächste Phase der Wartung über. Auch Zahlungsflüsse, Schulungen und die Produktivsetzung hängen oft vom Ergebnis des Abnahmetests ab.

Testumgebung für Abnahmetests

Eine valide Aussage zum Testergebnis lässt sich beim Abnahmetest nur erreichen, wenn die Tests in der finalen Infrastruktur des Kunden durchgeführt werden. Nur so können Inkompatibilitäten und Seiteneffekte ausgeschlossen werden.

Wird ein System zum ersten Mal produktiv gesetzt, wird manchmal auch die künftige Produktivumgebung für die Abnahmetests genutzt. In Zeiten virtueller Systeme ist die Bereitstellung und Verwaltung der Infrastruktur deutlich zeit- und ressourcenschonender.

Testdaten

Auch die Testdaten sollten von Kunden- bzw. Auftraggeberseite bereitgestellt oder zumindest gesteuert werden. Es können anonymisierte Produktivdaten genutzt werden. Eine Alternative ist auf das Testdatenmanagement des Systemtests zurückzugreifen. Egal welche Option genutzt wird, es gilt so gut wie möglich die spätere Anwenderperspektive einzunehmen.

Testautomatisierung des Abnahmetests

Da in klassischen Projektvorgehen der Abnahmetest meist nur einmal durchgeführt wird, spielt Testautomatisierung hier eher eine untergeordnete Rolle.

Im agilen Akzeptanztest sieht das ganz anders aus. Hier ist Testautomatisierung heute Pflicht, da sie immer und immer wieder ausgeführt werden müssen.

Einen Trend in diesem Kontext erlebt gerade die Robotergesteuerte Prozessautomatisierung (RPA), die sich vom Abnahmetest weiter bis in die Produktivumgebung nutzen lässt.

Akzeptanztest in agilen Projekten

Der Akzeptanztest ist im agilen Kontext essentiell. Hier ist der Fokus ja ganz stark auf dem Kundennutzen, seinem Feedback und seinen Vorstellungen. Durch die meist kurzen Iterationen und dem intensiven Austausch mit dem Kunden oder späteren Anwender, wird hier der Akzeptanztest zu einem laufenden Prozess. Das stetige Feedback des Nutzers wird aufgegriffen und in die nächsten Schritte aufgenommen. Das reduziert natürlich auch massiv den potentiellen Frustfaktor am Ende des Projekts. In manchen agilen Projekten gilt jeder abgenommene Teilschritt als komplett erledigt und wird nur mehr über automatisierte Regressionstests geprüft. Es findet dafür dann kein weiterer manueller Test mehr statt.

Typische Probleme

In agilen Projekten bin ich bisher kaum auf Probleme mit Akzeptanztests gestoßen. Ganz im Gegenteil. Alle Beteiligten profitieren von dem intensiven und laufenden Austausch.

In klassischen Projekten mit einem Abnahmetest zum Schluss sieht die Welt leider anders aus. Hier treten immer wieder Herausforderungen auf:

• Nicht funktionale Anforderungen wurden bis zum Abnahmetest nicht betrachtet und bringen jetzt Probleme, z.B. Usability-Tests, Performance- oder Zuverlässigkeits-Tests.
• Der Abnahmetest basiert komplett auf den Anforderungen und Vorstellungen des Kunden oder Anwenders. Wenn im Requirments Engineering oder im Systemtest Lücken oder ein anderes Verständnis nicht geklärt wurden, treten diese jetzt zu Tage und haben umso mehr Konsequenzen.
• Der Zeitdruck ist in der Abnahmephase häufig sehr groß, da das Projekt bald beendet sein soll. Das erhöht den Stress bei allen Beteiligten und auch deren Reizbarkeit.
• Fachlichen Abnahmetestern, Endnutzern oder Anwendern fehlen manchmal die Grundlagen des Software-Tests. Wie werden Testfälle erstellt? Wie dokumentiert? Und wie durchgeführt? Das führt in der Praxis oft zu Problemen und Verzögerungen.

Abnahmetest in der Praxis

Ich habe mit Staunen Projekte gesehen, wo der Abnahmetest aus drei Klicks bestand. Dann wurde Abnahme erklärt und alles, was nicht funktioniert, über Wartungsverträge korrigiert. Am anderen Ende der Skala habe ich Kunden erlebt, die professionelle Testcenter eingerichtet haben um Abnahmetests durchführen. Die Bandbreite ist groß, aber ebenso die Konsequenz.

Es kann heiß hergehen und in so manchem Abnahmemeeting herrscht dicke Luft. Das müsste nicht sein, wenn die Monate davor gemeinsam auf den Moment der Abnahme hingearbeitet worden wäre. Mir persönlich ist es daher immer ein Anliegen, diese Phase gemeinsam zu planen und durchzuführen. Auftraggeber und Auftragnehmer.