Von allen Praktiken des Clean Craftsmanship sind die Akzeptanz- oder Abnahmetests diejenigen, über die Programmierer die geringste Kontrolle haben. Die Umsetzung dieser Praktik erfordert die Beteiligung des Unternehmens. Woher weiß man, wann ein System bereit für den Einsatz ist?
Unternehmen auf der ganzen Welt treffen diese Entscheidung häufig, indem sie eine Qualitätssicherungsabteilung beauftragen, die Bereitstellung »abzusegnen«. In der Regel bedeutet dies, dass die Qualitätssicherungsmitarbeiter eine Vielzahl manueller Tests durchführen, die die verschiedenen Verhaltensweisen des Systems durchlaufen, bis sie überzeugt sind, dass sich das System wie angegeben verhält. Wenn diese Tests »bestanden« sind, kann das System in Betrieb genommen werden. Das bedeutet, dass die wahren Anforderungen an das System diese Tests sind. Es spielt keine Rolle, was im Anforderungsdokument steht; nur die Tests sind wichtig.
Wenn die Qualitätssicherung (QS) nach der Durchführung ihrer Tests ihre Zustimmung gibt, wird das System bereitgestellt. Daher sind diese Tests die Anforderungen. Die Praktik der Akzeptanztests erkennt diese einfache Tatsache an und empfiehlt, dass alle Anforderungen als Tests spezifiziert werden. Diese Tests sollten von den Teams für Business-Analyse (BA) und Qualitätssicherung für jede einzelne Funktion geschrieben werden, kurz bevor die jeweilige Funktion implementiert wird.
Die QS ist nicht für die Durchführung dieser Tests verantwortlich. Diese Aufgabe wird vielmehr den Programmierern überlassen; daher werden die Programmierer diese Tests sehr wahrscheinlich automatisieren. Kein Programmierer, der bei Verstand ist, möchte das System immer wieder manuell testen.
Programmierer automatisieren Dinge. Wenn also die Programmierer für die Durchführung der Tests verantwortlich sind, werden die Programmierer diese Tests automatisieren. Da jedoch BA und QS die Tests verfassen, müssen die Programmierer in der Lage sein, BA und QS zu beweisen, dass die Automatisierung tatsächlich die Tests durchführt, die sie verfasst haben. Daher muss die Sprache, in der die Tests automatisiert werden, eine Sprache sein, die BA und QS verstehen. Tatsächlich sollten BA und QS sogar in der Lage sein, die Tests in dieser Automatisierungssprache selbst zu schreiben.
Im Laufe der Jahre wurden mehrere Tools erfunden, die bei diesem Problem helfen sollen: FitNesse, JBehave, SpecFlow, Cucumber und andere. Aber die Tools sind nicht wirklich das Problem. Die Spezifikation des Softwareverhaltens ist immer eine einfache Funktion aus der Angabe von Eingabedaten, der auszuführenden Aktion und den erwarteten Ausgabedaten spezifiziert. Dies ist das bekannte AAA-Pattern: Arrange/Act/Assert.
Alle Tests beginnen mit dem Anordnen (engl. arrange) bzw. Vorbereiten der Eingabedaten für den Test; dann veranlasst der Test die Ausführung (engl. act) der getesteten Aktion. Zum Schluss bestätigt der Test, dass die Ausgabedaten dieser Aktion mit der Erwartung übereinstimmen (engl. assert).
Diese drei Elemente können auf unterschiedliche Weise spezifiziert werden, am einfachsten ist jedoch eine einfache tabellarische Darstellung. Die Abbildung zeigt zum Beispiel einen Teil eines der Akzeptanztests im FitNesseTool. FitNesse ist ein Wiki, und dieser Test prüft, ob die verschiedenen Auszeichnungsgesten korrekt in HTML übersetzt werden. Die auszuführende Aktion ist Widget should render, die Eingabedaten sind der Wiki-Text, und die Ausgabe ist der html-Text.
Ein anderes gängiges Format ist Geben-Wenn-Dann:
Gegeben eine Seite mit dem Wiki-Text: !1 header
Wenn diese Seite gerendert wird
Dann wird die Seite enthalten: <h1>header</h1>
Es sollte klar sein, dass diese Formalismen relativ leicht zu automatisieren sind, unabhängig davon, ob sie in einem Akzeptanztestprogramm, in einer einfachen Tabellenkalkulation oder einem Texteditor geschrieben werden.
akzeptanztests – Die Praktiken
In der strengsten Form der Praktik werden die Akzeptanztests von BA und QS geschrieben. Die BA konzentriert sich auf die Positivszenarien (engl. happy path), während die QS die unzähligen Möglichkeiten erforscht, wie das System scheitern kann.
Diese Tests werden zur gleichen Zeit oder kurz vor der Entwicklung der zu testenden Funktionen geschrieben. In einem agilen Projekt, das in Sprints oder Iterationen aufgeteilt ist, werden die Tests in den ersten Tagen des Sprints geschrieben. Am Ende des Sprints sollten sie alle bestanden sein. BA und QS stellen den Programmierern diese Tests zur Verfügung, und die Programmierer automatisieren sie in einer Weise, dass BA und QS beteiligt bleiben.
Diese Tests werden zur Definition of done. Eine Funktion ist erst dann fertig, wenn alle Akzeptanztests bestanden sind. Und wenn alle Akzeptanztests bestanden sind, ist die Funktion fertig.
Dies bringt natürlich eine große Verantwortung für BA und QS mit sich. Die Tests, die sie schreiben, müssen vollständige Spezifikationen der zu testenden Funktionen sein. Die Suite der Akzeptanztests ist das Anforderungsdokument für das gesamte System. Durch das Schreiben dieser Tests bescheinigen BA und QS, dass die spezifizierten Funktionen fertig sind und funktionieren, wenn sie bestanden werden.
Einige BA- und QS-Teams sind es vielleicht nicht gewohnt, solch formale und detaillierte Dokumente zu schreiben. In diesen Fällen können die Programmierer die Abnahmetests unter Anleitung von BA und QS schreiben. Das Zwischenziel besteht darin, Tests zu erstellen, die BA und QS lesen können und absegnen können. Das endgültige Ziel ist es, BA und QS so weit zu bringen, dass sie die Tests selbst schreiben können.
Akzeptanztests – Der kontinuierliche Build
Sobald ein Akzeptanztest bestanden ist, wird er in die Testsuite aufgenommen, die während des kontinuierlichen Builds ausgeführt wird.
Der kontinuierliche Build ist ein automatisiertes Verfahren, das jedes Mal abläuft, wenn ein Programmierer Code in das Quellcode-Versionierungssystem eincheckt. Dieses Verfahren erstellt das System aus dem Quellcode und führt dann die Testsuiten der automatisierten Programmierertests und der automatisierten Akzeptanztests durch. Die Ergebnisse dieses Laufs werden sichtbar veröffentlicht, oft in einer E-Mail an alle Programmierer und Interessierten. Der Status des kontinuierlichen Builds ist etwas, dessen sich jeder ständig bewusst sein sollte.
Durch die kontinuierliche Durchführung all dieser Tests wird sichergestellt, dass spätere Änderungen am System keine funktionierenden Funktionen zerstören. Wenn ein zuvor bestandener Akzeptanztest während des kontinuierlichen Builds fehlschlägt, muss das Team sofort reagieren und den Fehler beheben, bevor weitere Änderungen vorgenommen werden. Es ist lebensmüde, zuzulassen, dass sich Fehler während des kontinuierlichen Bauens ansammeln.
Dieser Artikel ist ein Auszug aus dem Buch „Clean Craftsmanship“ von Robert C. Martin. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe findet ihr bei uns im Shop.