Alle reden über Testautomatisierung, aber sollten wir nicht lieber Geredetes automatisieren?

Bevor wir uns an das Automatisieren von Tests machen, unterhalten wir uns im Normalfall darüber, was alles getestet und vor allem was alles automatisiert werden soll. Allerdings birgt dies eine Gefahr. Der amerikanische Basketballtrainer Dick DeVenzio hat einmal gesagt, dass das, was gesagt wird, das, was verstanden wird, und das, was gemeint ist, drei verschiedene Dinge sind. Dies gilt nicht nur im Basketball, sondern eigentlich überall. Beispiele kennen wir alle zur Genüge, mal mit kleineren Auswirkungen wie etwa der falschen Getränkesorte beim Einkaufen, mal mit größeren Auswirkungen wie etwa dem Scheitern von Weltraummissionen, weil imperiales und metrisches System nun doch etwas unterschiedlich sind.

Warum ist das nun ein Problem?

Bei Kommunikation geht es ganz grundlegend um den Transfer von Informationen. Informationen sind allerdings nie komplett kontextfrei. Und dieser Kontext kann, um im Sprachgebrauch der Kommunikationsforschung zu bleiben, beim Sender, also der Person, die etwas sagt, und beim Empfänger, also der Person, die etwas versteht, sehr unterschiedlich sein. Diese Darstellung finden wir auch in etlichen Kommunikationsmodellen, wie etwa dem Vier-Seiten-Modell nach Friedemann Schulz von Thun. Hier wird der eigentlichen Nachricht noch Kontext auf vier verschiedenen Ebenen mitgegeben, die von Sender und Empfänger unterschiedlich aufgefasst werden können. Daher bieten einfache Sätze wie „Wir haben morgen einen Releasetermin“ auch ein enormes Konfliktpotenzial. Während der Sender vielleicht nur auf das Datum hinweisen möchte, kommt beim Sender „Ich muss Überstunden machen“ an.

Muss ich das nun einfach so hinnehmen?

Im Testen und für die Auswahl von Automatisierungsinhalten kann ich diese Frage mit einem eindeutigen „Nein“ beantworten. Denn Abhilfe in Sachen Verständnisschwierigkeiten bringt BDD. Für mich ist das Behaviour Driven Development – und dafür steht BDD – in erster Linie eine Kommunikationsgrundlage und in zweiter ein Entwicklungsvorgehen. Es geht wörtlich darum, Verhalten im Vorfeld abzustecken und als Grundlage für die Entwicklung zu nutzen. Dieses Nutzerverhalten herauszufinden und das Schaffen eines gemeinsamen Verständnisses sind für mich die beiden zentralen Kernpunkte. Wenn wir das geschafft haben, sind wir meist ein gutes Stück weiter, was die Auswahl der Automatisierungsinhalte und somit auch die Softwarequalität angeht.

Gehts auch konkreter?

Erfahrungsgemäß bedienen sich Menschen beim Erklären komplexer Sachverhalte gerne konkreter Beispiele. Die Konkretisierung mit Beispielen führt dazu, dass der Kontext der Nachricht zwischen Sender und Nachricht synchronisiert wird. Es besteht dadurch weniger Möglichkeit, die Nachricht in einen persönlichen Kontext zu rücken. Es gab Zeiten, da hat mein Team die Frage „Hast du mal ein Beispiel?“ schon beantwortet, bevor ich sie stellen konnte. Als Tester darf man hier aber gerne auch mal etwas nerven und diese Fragen stellen, so sie denn nicht alleine auf den Tisch kommen.

BDD bedient sich dieses Konzepts von konkreten Beispielen, die exemplarisch für das Anwenderverhalten stehen, um sie in allen Phasen des Softwareentwicklungsprozesses zu nutzen und vor allem, um den Brückenschlag zwischen den verschiedenen Phasen zu schaffen, also die Kontexte anzugleichen. Durch die Nutzung einer domänenspezifischen Sprache, die sehr nahe an natürlicher Sprache ist, ermöglicht es BDD, eine Grundlage zu schaffen, die von allen Parteien verständlich ist. Oder um es mit einem konkreten Beispiel zu sagen: Angenommen, ich habe mich für BDD in einem Projekt entschieden, wenn ich ab jetzt konkrete Beispiele nutze, dann habe ich die Grundlage für ein gemeinsames Verständnis.

Eine Sprache für alle!

In diesem Fall umfasst „alle“ auch die Stakeholder und Fachabteilungen. Gerade hier habe ich die Erfahrung gemacht, dass es der Zusammenarbeit zuträglich ist, wenn man eine gemeinsame Sprache spricht und sich nicht jede Seite in ihrem jeweiligen Soziolekt verliert oder im Klischee: Entwickler sprechen Java, Fachabteilungen Fachchinesisch. In der Semantik geht man davon aus, dass Wortbedeutungen als Denotationen und Konnotationen gespeichert werden, also Kernbedeutungen und – Sie ahnen es vielleicht bereits – Bedeutungen im Kontext. Dieser sollte natürlich gering gehalten werden, um Missverständnisse zu vermeiden.

Das Schöne ist nun, dass ich mit diesen Beispielen bereits vor Entwicklungsbeginn Tests auf fachlicher Ebene habe, an denen ich meine Aktivitäten ausrichten kann. Gleichzeitig können sie auf allen Teststufen genutzt werden, wobei sie gerade im Bereich der Abnahmetests ihre besonderen Stärken ausspielen. Dies vor allem aufgrund ihrer Verständlichkeit, die es auch Fachanwendern ermöglicht, sie zu verstehen und durchzuführen oder auch einen automatisierten Testfall zu verstehen. Da die Fachanwender im Optimalfall bereits bei der Erstellung der Beispiele involviert waren, schließt sich hier der Kreis und die Gefahr eines „Das habe ich aber ganz anders gemeint“-Moments reduziert sich deutlich.

Beispiele können sich natürlich mit der Zeit ändern. Das ist auch gut und durchaus gewollt. Dadurch erfüllt BDD auch den Anspruch einer lebenden Dokumentation. Wichtig ist hierbei, dass der zentrale Charakter der Kommunikationsgrundlage beibehalten wird, sprich Änderungen besprochen werden und allen Beteiligten bekannt sind.

Tests im BDD-Kontext bilden einen guten Startpunkt für die Automatisierung. Durch die Schwerpunktlegung auf die fachlichen Inhalte und nicht auf die konkrete Umsetzung sind sie auch deutlich robuster gegenüber Änderungen an der Umsetzung. Auch sind diese automatisierten Tests für alle Beteiligten besser lesbar, als es oft bei anderen Tests der Fall ist. Ich habe auch gute Erfahrung mit BDD ohne größere Automatisierung gemacht. Der Kommunikationsaspekt und das Schaffen des gemeinsamen Verständnisses sind häufig genauso wichtig, wenn nicht sogar wichtiger als die Automatisierung.

Apropos Semantik

Neben BDD, also Behaviour Driven Development, begegnen uns in der Praxis weitere Abkürzungen wie SBE, TDD oder ATDD. Diese haben alle ihre Berechtigung, sind aber durchaus unterschiedliche Ansätze, sodass es sich aus Sicht der semantischen Merkmalstheorie lohnt, einmal einen Blick darauf zu werfen. Specification by Example (SBE) ist hierbei vielleicht am klarsten abzugrenzen, beziehungsweise gerade auch nicht, da sich hinter SBE die Nutzung von BDD-Szenarien zu Dokumentationszwecken verbirgt. Somit sind SBE und BDD synonym zu sehen.

Test-Driven Development (TDD) ist vielleicht das bekannteste Konzept in dieser Aufzählung. Auch beim TDD geht es um einen Test-first-Ansatz, wir befinden uns hier jedoch ganz klar auf Code-Ebene und sind dokumentenorientiert unterwegs. Es wird hier zunächst der Testcode auf Basis von Anforderungen geschrieben und erst anschließend der Produktivcode. Es geht also primär darum zu prüfen, ob wir die Software richtig gebaut haben. Die Frage, ob auch die richtige Software gebaut wurde, wird hier nicht näher betrachtet. Aus Automatisierungsperspektive können wir hier im Worst Case einiges an Energie in etwas gesteckt haben, was an den Bedürfnissen der Nutzer komplett vorbei geht. Eine Geschichte finden wir an dieser Stelle ebenfalls nicht und anstatt eines konkreten Beispiels haben wir es eher mit einem spezifischen Skript und konkreten Testdaten zu tun. Weitere zentrale Elemente sind kleine Schritte und ständiges Refactoring. Es wird also teilweise nach der Änderung einer Codezeile geprüft, wie der vorher geschriebene Test sich verhält und gleichzeitig bedeutet das Bestehen des Tests nicht automatisch das Ende der Entwicklungsaktivitäten an dieser Stelle.

Acceptance Test Driven Development (ATDD) stellt Akzeptanztests in den Mittelpunkt. Es geht auch hierbei um konkrete Beispiele, die den Entwicklungsprozess leiten. Im Gegensatz zu BDD stehen allerdings die Geschichten nicht im Mittelpunkt und die Szenarien stellen einen Fixpunkt dar, der nicht ohne Weiteres änderbar ist. Die Szenarien sind hier also weniger Kommunikationsgrundlage als Kommunikationsrahmen, der im Hinblick auf den Abnahmetest festgezurrt ist. Eine Festlegung im Sinne einer domänenspezifischen Sprache ist hier per definitionem nicht gegeben, wird in der Praxis jedoch häufig genutzt.

Auf Grund der hier aufgezeigten Ähnlichkeiten werden ATDD und BDD häufig gleichgesetzt, allerdings geht durch diese Gleichsetzung genauso häufig eine Reduzierung von BDD auf die Abnahme einher, was nicht im Sinne eines Ansatzes ist, der die ständige Kommunikation und Adaption fördert.

Was kann schon schief gehen?

Natürlich kann ich mich mit BDD, wie mit so ziemlich jeder Methodik oder Vorgehensweise, auch in die Nesseln setzen. Häufig lassen sich drei Antipatterns beobachten, die dazu führen, dass BDD zum Selbstzweck verkommt. Jedes dieser Muster ist glücklicherweise recht zügig zu identifizieren und kann auch mit einfachen Bordmitteln begegnet werden.

In Szenarien werden Klickleitfäden abgebildet

Bilde ich in Szenarien viele, sehr detaillierte Einzelschritte ab, so werden diese sehr schnell unübersichtlich und gleichen herkömmlichen Testskripten. Hier hilft es häufig, sich auf die zugrunde liegende Geschichte zu besinnen und Inhalte zu kondensieren. Bei Grimms Märchen hat es ja auch gereicht, dass Hänsel und Gretel in den Wald gehen. Ob sie zuerst mit dem linken Fuß gegangen sind und ob sie nach 300 m über oder unter dem umgestürzten Baum her sind, ist für die Geschichte gar nicht so relevant. Ähnlich verhält es sich auch mit BDD-Szenarien. In Unittests, wie sie etwa für TDD genutzt werden, mögen singuläre Schritte sicherlich eine gute Idee sein, für Geschichten haben wir mit Einzelschritten ein Granularitätsniveau erreicht, das dem Verständnis nicht unbedingt zuträglich ist. Wir sehen den sprichwörtlichen Testwald vor lauter Testschrittbäumen nicht mehr.

Was sich hier in der Praxis bewährt hat, ist ein Medienwechsel. Digitale Medien erlauben natürlich eine schier unendliche Anzahl an Schritten, probiere ich mein Szenario auf einem einzelnen Klebezettel festzuhalten, so muss ich mich automatisch aus Platzgründen alleine schon kurzfassen. Selbst wenn ich den Klebezettel nicht später an die Wand hänge, sondern in einem Vorgangsverwaltungssystem überführe, kann ich es so schaffen, die richtige Flughöhe zu erreichen.

Es gibt keine Tests jenseits der BDD-Szenarien

BDD-Szenarien sind hauptsächlich als Kommunikationsgrundlage gedacht. Wenn ich sie nun als Tests nutze und darüber hinaus keine weiteren Tests mache, so werden mir sicherlich einige Bugs durch das aufgespannte Netz gehen. Nicht umsonst führt Brian Marick sie in seinem Testquadrantenmodell nur in einem der Quadranten auf. Aber auch, wenn mir agiles Testen mit seinen Modellen nicht so geläufig ist, reicht es oft schon, sich auf sein Testwissen und seine Erfahrung zu verlassen, um diesem Punkt begegnen zu können.

Wir haben hier also eine genauso unzureichende Abdeckung wie mit ausschließlich Unittests. Es geht also weniger um „entweder oder“, sondern um „sowohl als auch“. Der Diskussionspunkt ist vielmehr, in welchem Verhältnis ich die verschiedenen Ansätze gewichte. Eine Patentlösung gibt es auch hier nicht, zu sehr unterscheiden sich doch die Kontexte, beginnend mit regulatorischen Gegebenheiten und endend mit individuellen Fähigkeiten und Kenntnissen der beteiligten Personen. Einen erfahrenen Tester im Team zu haben, ist hier meist schon ein erster Schritt, um das Problem anzugehen. Wenn dieser nicht verfügbar oder gar gewollt ist, so kann diese Person beispielsweise im Sinne eines Quality-Evangelisten oder Test-Coaches auch übergreifend sicherlich unterstützend eingreifen. Alternativ kann ich natürlich auch das Quadrantenmodell heranziehen und hier eine Überdeckung von mehr als ¼ anstreben.

Die Szenarien werden vorgegeben

Häufig begegnet man Arbeitsumgebungen, in denen die BDD-Szenarien von einer Person vorgegeben werden. Diese mögen sogar wohl formuliert sein. Problematisch ist aus BDD-Sicht jedoch, dass sie nicht gemeinsam entwickelt und diskutiert werden, sondern schlimmstenfalls sogar delegiert werden. Dieses Verhalten tritt insbesondere in Kontexten auf, die ATDD und BDD als synonym betrachten. BDD kann seine Stärken jedoch insbesondere dann ausspielen, wenn ich die Szenarien als Grundlage meiner Kommunikation nutze und nicht als schlimmstenfalls im Vorfeld festgeschriebene Kommunikationsaussage.

In unseren Seminaren empfehlen wir gerade in agilen Kontexten Vorgehensweisen wie die drei Amigos, wie PO, Entwickler und Tester, oder Refinements, die eine gute Möglichkeit der gemeinsamen Erstellung und Diskussion der Szenarien darstellen. Zumindest aber kann ich in meiner Definition of Ready oder in meinen Testeingangskriterien einen Punkt festhalten, der besagt, dass die BDD-Szenarien gemeinsam erstellt wurden.

Berücksichtige ich jedoch diese Punkte, so habe ich mit BDD einen starken Verbündeten, der Teams und Anwendern dabei helfen kann, ein gemeinsames Verständnis zu entwickeln und zu entscheiden, welche Inhalte sinnvollerweise automatisiert werden und welche eher nicht.