Wer sich schon einmal mit Testautomatisierung beschäftigt hat, weiß: Es ist toll, automatisierte Tests zu haben, die man jederzeit durchführen und beliebig oft wiederholen kann – aber dorthin zu kommen, kann ein langer und oft steiniger Weg sein. Und sogar noch schwieriger ist es für Projekte, ihre wachsende Zahl an automatisierten Tests lauffähig und aktuell zu halten: Viele Testautomatisierungen werden leider irgendwann über Bord geworfen, weil ihre Wartungs- und Pflegeaufwände nicht mehr gestemmt werden können. Vor diesem Hintergrund ist die Frage „Braucht man das alles wirklich?“ vollkommen berechtigt. Dr. Christian Brandes, unser „Head of Test & QA“, wurde mit genau dieser Frage konfrontiert, und da wir die kurze und lange Antwort darauf nicht für uns behalten wollten, haben wir hier für euch alles Wichtige zum Thema zusammengefasst.

Jetzt kommt das ABER…

Entscheidend für den Erfolg einer Automatisierung ist, sich vorher ausreichend Gedanken darüber zu machen, WELCHE Tests automatisiert werden sollen und WIE diese Automatisierung aussehen soll. Die erste Frage „Welche Tests?“ führt vor allem zur Regressionsstrategie: Welche Tests sind so wertvoll, dass sie immer wieder wiederholt werden sollen? Typische Antworten darauf sind: Tests zu Normalabläufen (Pareto-Regel, „happy path“), Tests der Akzeptanzkriterien, sowie nachträgliche Tests zu „durchgerutschten“ Fehlern (Korrekturprinzip). Denn: „Alles“ zu automatisieren ist nicht möglich und meist auch nicht sinnvoll, worauf schon Dorothy Graham hinwies („Automated chaos just gives faster chaos“). Nicht vergessen: Testen liefert „nur“ Informationen, und automatisierte Tests liefern diese Informationen eben schneller und häufiger.

Die zweite Frage „Wie automatisieren?“ muss eine grundlegende Tatsache berücksichtigen: Testautomatisierung ist Softwareentwicklung, d.h. dafür sind Programmierkenntnisse notwendig. Und um nicht mit stetig zunehmender „technischer Schuld“ im Testcode konfrontiert zu werden, sollte man sich im Vorfeld eine Automatisierungs-Architektur überlegen, die zur Aufgabenstellung passt, die die Modularisierung und Wiederverwendung von Testcode fördert, sinnvolle Schichten definiert, damit nicht bei jeder UI-Anpassung zahllose Skripten angefasst werden müssen, und vielleicht auch Testschritte und Testdaten trennt. Hier kommen also bewährte Techniken wie KDT (keyword-driven testing) und DDT (data-driven testing) zum Zuge. Testcode sollte außerdem nicht als „zweitklassiger“ Code betrachtet werden, auch er muss lesbar und verständlich sein, versioniert werden und Coding Guidelines folgen. Und als Sahnehäubchen ist irgendwann das Thema „Kontrolle über die Testumgebung“ zu knacken, da mangelnde Kontrolle über Datenbestände u.ä. leider häufig mittels „intelligenterer Testautomatisierung“ kompensiert wird – was aber wiederum die Pflegeaufwände und Fehleranfälligkeit des Testcodes erhöht und in Summe oft teurer ausfällt als die Behebung des Problems „an der Wurzel“.

Fazit

Die einzigen Projekte, die sich mit Testautomatisierung NICHT zu beschäftigen brauchen, sind solche, die ein sehr simples Produkt bauen und/oder keine nennenswerten Produktrisiken beachten müssen. Für alle anderen gilt: die „richtigen“ Tests automatisieren, diese „richtig“ automatisieren, und das Ganze in einem durchdachten Mix mit manuellen Testaktivitäten auf die Straße zu bringen – „das ist der Weg“, wie ein Mandalorianer sagen würde. 😉

Eine ausführlichere Antwort auf die Frage „Sind automatisierte Tests notwendig?“ kannst du dir im Video von Dr. Christian Brandes ansehen. Dieses und weitere informative Videos findest du auf unserem Youtube-Kanal isento.insights.