Sind automatisierte Akzeptanztests schädlich?

Viele Pioniere der automatisierten Akzeptanztests haben ihr Schicksal mit schwerfälligen automatisierten Testsuiten angeprangert. Ein aktueller Artikel auf InfoQ fasst den Trend ganz gut zusammen. Ich werde nicht auf diesen Zug aufspringen, aber ich werde versuchen, einen sicheren Mittelweg zwischen dem übereifrig geschaffenen Wartungsaufwand und der Anarchie zu finden. Der wichtigste Punkt ist, dass die Automatisierung von Akzeptanztests der richtige Weg ist, Sie sollten nur keine unnützen Tests automatisieren und pflegen. Der schwierige Teil besteht darin, herauszufinden, welche Tests nützlich sind und welche nicht. Bevor ich beginne, möchte ich den Unterschied zwischen automatisierten Abnahmetests und automatisierten Integrationstests oder Unit-Tests betonen. Unit-Tests sind absolut unerlässlich. Jeder, der Ihnen etwas anderes erzählt, ist entweder unwissend, weil er es noch nicht versucht hat, oder ein Idiot. Wir können eine lange Diskussion darüber führen, wie man Unit-Tests richtig durchführt, aber das ist nicht das Thema dieses Beitrags. Automatisierte Integrationstests (in einem vernünftigen Rahmen) sind äußerst nützlich und in einigen Bereichen sogar unerlässlich. Wenn Sie mit externen Systemen oder Dingen in Berührung kommen, deren Nachahmung sonst sehr teuer wäre, sind einige der Vorbehalte vielleicht vertretbar. Automatisierte Akzeptanztests sind Tests, bei denen das Ziel darin besteht, die Interaktion des Benutzers mit dem System zu simulieren. Hier geht es darum, wann und wie dies sinnvoll ist. Lassen Sie uns zunächst die Argumente für automatisierte Akzeptanztests auflisten:

1. Je kürzer die Iteration, desto mehr müssen Sie testen. Je kürzer die Iteration, desto schneller der ROI.
2. Wenn Sie ein automatisiertes Testframework verwenden, das für den Kunden verständlich ist, können Sie das Schreiben der Tests wieder an den Kunden delegieren, so dass die korrekt definierte Funktionalität sein Problem ist.
3. Menschen lassen sich sehr leicht dazu verleiten, bestimmte Details zu übersehen. Automatisierte Tests sind für diese Art von Korruption unempfindlich.

Und dann gibt es noch die Nachteile:

1. Tests sind teuer in der Wartung. Sie werden sich nie rentieren, denn je mehr Sie ändern, desto mehr müssen Sie Ihre Tests ändern, was letztendlich die Kosten des Projekts erhöht.
2. Die Kunden verstehen die Testwerkzeuge nicht, so dass die Entwickler diese Tests ohnehin schreiben und pflegen müssen.
3. Tests schlagen ständig fehl, wenn Sie Kleinigkeiten ändern, bei denen ein Tester seinen Kopf benutzen und Sie in Ruhe lassen würde, wenn die Änderung sinnvoll wäre.

Ad 1: Einerseits stimmt es, dass manuelle Tests eine sich wiederholende Arbeit sind. Aber wenn es viele Änderungen gibt, kann der Grad der Wiederholung geringer sein, als zuvor angenommen wurde. Es ist nur sinnvoll, sich wiederholende Arbeiten zu automatisieren, aber erst dann, wenn Sie sichergestellt haben, dass sie sich wiederholen. Daraus folgt, dass es eine schlechte Idee ist, automatisierte Tests im Voraus zu schreiben (wenn Sie nicht sichergestellt haben, dass sie wiederholt werden). Sie überhaupt nicht zu schreiben, ist ebenfalls eine schlechte Idee, da Sie die Automatisierung von sich wiederholenden Aufgaben von vornherein ausschließen. Wir müssen genau definieren, wann es sinnvoll ist, einen Test zu automatisieren. Ich werde später in Ad 3 darauf zurückkommen. Ad 2. Die derzeitigen Frameworks für automatisierte Tests sind für den Kunden nicht verständlich. Zumindest nicht ganz von selbst. Ich habe allerdings schon viele Gegenbeispiele gesehen, in denen Product Owner Selenium-Tests aufzeichnen, um sie durch langweilige Abläufe zu bringen, und Kundentester Fitnesse-Fixtures schreiben, um zu sehen, ob sie eine Headless-Anwendung knacken können. Das funktioniert nur, wenn ein Team ernsthafte Anstrengungen unternimmt, um dem Kunden bei der Verwendung der Tools zu helfen. Ich mache dafür in erster Linie die Qualität dieser Tools verantwortlich, so weit sind wir noch nicht. Aber wenn diese Anfangsinvestition getätigt wird, gibt es eine besondere Art der Interaktion mit den Beteiligten, die sonst unmöglich wäre. Ad 3. Es gibt keine Möglichkeit, sowohl gut definierte Spezifikationen als auch agile, sich entwickelnde Software zu haben. Sie müssen entscheiden, was variabel und was fix ist. Für diese Entscheidung sollte nicht der Tester, sondern der Stakeholder verantwortlich sein. Ich denke, wenn der Stakeholder mit einer bestimmten Funktion zufrieden ist und sie beibehalten möchte, dann ist es an der Zeit, den Test zu automatisieren. Sie können damit warten, bis der erste Fehler auftritt, der die besagte Funktion beeinträchtigt, aber Sie können nicht zulassen, dass eine Regression nach der anderen oder ein manueller Testlauf nach dem anderen die Kosten in die Höhe treibt. Wenn es fertig ist, ist es fertig und Sie können es in Stein meißeln. Es gibt zwei Arten von Kosten, die Sie beim Schreiben von automatisierten Akzeptanztests berücksichtigen müssen. Was kostet es mich anfangs, was kostet es mich, diese Tests zu pflegen. Wenn diese Kosten die Einsparungen überwiegen, sollten Sie nicht investieren. Bei den meisten Projekten, die über mehr als eine Handvoll Iterationen laufen, sind die Kosten für Regressionen jedoch ziemlich hoch, so dass ich sagen würde, dass es in den meisten Fällen effizient ist, die Dinge richtig einzurichten. Sobald Sie eine Einrichtung haben, die für automatisierte Akzeptanztests verwendet werden kann, stellt sich immer noch die Frage, was getestet werden soll. Mir gefällt die Idee, sich auf die Automatisierung von sich wiederholenden Aufgaben zu konzentrieren. Aus diesem Grund ist ein menschlicher Tester vielleicht der beste Experte für das, was automatisiert werden muss, einfach weil er die sich wiederholende Arbeit erledigen darf. Wenn automatisierte Tests hauptsächlich eine Kosteneinsparungsmaßnahme sind, ist es ziemlich egal, wer die Tests durchführt. Wenn die Entwickler die Tests effizienter durchführen können als der Kunde, weil die Tools für den Normalsterblichen noch zu klobig sind, dann lassen Sie die Entwickler das einfach machen, bis sie bessere Tools auswählen oder herstellen. Die Entwickler sind faul genug, um herauszufinden, wann das effizient wird.