Wenn niemand mehr durch die Testbasis blickt

Vor einiger Zeit habe ich eine Testbasis gesehen, die aus hunderten von Testfällen bestand.

Alle lagen in einem einzigen Ordner.

Der Name des Ordners lautete: „Orphans“.

In diesem Ordner steckte ungefähr ein Jahr Projektarbeit. Testfälle wurden erstellt, erweitert und ausgeführt. Trotzdem konnten am Ende nur noch wenige Personen erklären, welche Tests dort enthalten waren, welche Anforderungen sie prüften und ob sie überhaupt noch aktuell waren.

Heute wird dort eine neue Testbasis aufgebaut. Mit einer klaren Struktur. Teilweise sogar mit neu erstellten Testfällen.

Als ich den Ordner gesehen habe, musste ich nicht lange überlegen, wo das eigentliche Problem lag.

Es waren nicht zu wenige Testfälle vorhanden.

Es waren vermutlich sogar zu viele.

Eine Testbasis besteht aus mehr als Testfällen

Wenn über Testbasis gesprochen wird, denken viele zuerst an klassische Testfälle mit Testschritten und erwarteten Ergebnissen.

Für mich greift diese Sichtweise zu kurz.

Auch Test Charter aus dem explorativen Testen gehören für mich zur Testbasis. Genauso wie Anforderungen, User Stories oder Testmodelle.

Eine Testbasis ist für mich die Sammlung aller Informationen, die mir helfen zu verstehen, was geprüft werden soll und wie ich diese Prüfung durchführen kann.

Dabei geht es vor allem um Transparenz.

Ich möchte schnell erkennen können, welche Bereiche eines Systems bereits abgedeckt sind, welche Risiken betrachtet werden und welche Tests dafür existieren.

Das eigentliche Problem beginnt oft viel früher

Eine gute Testbasis entsteht nicht erst beim Schreiben von Testfällen.

Sie beginnt beim Verstehen.

Wenn ich in ein neues Projekt komme, schaue ich mir zuerst die vorhandenen Anforderungen an. Das können klassische Anforderungen sein, aber auch User Stories. In agilen Projekten liefern oft auch Refinements wichtige Informationen. Dort werden Anforderungen erklärt, fachliche Zusammenhänge diskutiert und offene Fragen beantwortet.

Dabei fällt mir immer wieder auf, dass ein Teil des Wissens nur in den Köpfen einzelner Fachexperten vorhanden ist.

Die eigentliche Herausforderung besteht deshalb oft nicht darin, Tests zu schreiben.

Die Herausforderung besteht darin, sicherzustellen, dass alle Beteiligten das Gleiche verstanden haben.

Deshalb arbeite ich gerne mit Testmodellen.

Testmodelle helfen mir dabei, Abläufe sichtbar zu machen und Anforderungen besser zu verstehen. Während ich ein Modell erstelle, erkenne ich häufig sehr schnell, wo noch Informationen fehlen oder wo ich einen Prozess noch nicht vollständig verstanden habe.

Warum ich lieber Testmodelle reviewe als Testfälle

Früher habe ich häufig fertige Testfälle mit dem Fachbereich besprochen.

Heute mache ich das anders.

Ich reviewe die Testmodelle.

Aus meiner Erfahrung ist das deutlich effizienter.

Im Modell kann ich gemeinsam mit dem Fachbereich prüfen, ob der Ablauf korrekt dargestellt ist. Missverständnisse werden früh sichtbar. Änderungen können direkt im Modell vorgenommen werden.

Wenn das Modell anschließend freigegeben ist, kann mein Werkzeug die daraus entstandenen Testfälle automatisch aktualisieren oder neu generieren.

Dadurch muss niemand hunderte einzelne Testfälle durchgehen.

Wir diskutieren die eigentliche fachliche Logik und nicht die Formulierung einzelner Testschritte.

Woran man eine schlechte Testbasis erkennt

Eine schlechte Testbasis erkennt man selten daran, dass Testfälle fehlen.

Oft erkennt man sie daran, dass niemand mehr den Überblick hat.

Für mich beginnt eine gute Testbasis bei der Struktur.

Kann ich die fachlichen Bereiche des Produkts erkennen?

Sind zusammengehörige Tests auch zusammen abgelegt?

Kann ich erkennen, welche Tests für eine Regression wichtig sind?

Gibt es Prioritäten?

Kann ich nachvollziehen, zu welcher Anforderung ein Test gehört?

Ist klar, welche Testdaten benötigt werden?

Die Anzahl der Testfälle spielt dabei für mich kaum eine Rolle.

Lieber die richtigen Testfälle als tausende von Testfällen, die später niemand mehr pflegen kann.

Wenn Vertrauen verloren geht

Eine schlechte Testbasis verursacht oft Kosten, die auf den ersten Blick nicht sichtbar sind.

Wenn niemand weiß, welche Tests bereits existieren, werden neue Tests erstellt, obwohl ähnliche Tests bereits vorhanden sind.

Wenn Testfälle veraltet sind, wird die Analyse von Abweichungen schwieriger.

Schlägt ein Test fehl, stellt sich sofort die Frage:

Ist die Implementierung fehlerhaft?

Oder prüft der Testfall einen veralteten Stand?

Allein die Beantwortung dieser Frage bindet Zeit bei Fachbereich, Entwicklung und Qualitätssicherung.

Noch kritischer wird es bei Releases.

Vielleicht sind alle Testergebnisse grün.

Vielleicht wurden alle geplanten Tests erfolgreich durchgeführt.

Aber welchen Wert hat diese Aussage, wenn niemand mehr beurteilen kann, ob überhaupt die richtigen Dinge getestet wurden?

Irgendwann geht dann das Vertrauen verloren.

Dann hört man Sätze wie:

„Ich muss im UAT sowieso noch einmal alles selbst testen, weil ich mich auf die Tests aus dem Team nicht verlassen kann.“

Spätestens dann hat das Projekt ein ernstes Problem.

Was das mit Testautomatisierung zu tun hat

An dieser Stelle wird häufig über Testautomatisierung gesprochen.

Dabei wird eine wichtige Frage oft übersehen.

Welchen Wert haben tausende automatisierte Tests, wenn niemand mehr sagen kann, ob die richtigen Dinge geprüft werden?

Viele Teams investieren viel Zeit und Geld in ihre Automatisierung.

Sie bauen Frameworks auf, integrieren Tests in ihre Pipelines und automatisieren Regressionstests.

Das ist sinnvoll.

Aber eine schlechte Testbasis wird durch Testautomatisierung nicht automatisch besser.

Wenn wir den Überblick über unsere Testbasis verlieren, verlieren wir früher oder später auch den Überblick über unsere Testautomatisierung.

Dann laufen zwar alle Tests erfolgreich durch.

Die eigentliche Frage bleibt aber unbeantwortet:

Prüfen wir überhaupt noch die richtigen Dinge?

Die Testbasis gehört dem Team

Wer für die Testbasis verantwortlich ist, wird häufig schnell beantwortet.

Der Tester macht das schon.

Genau das halte ich für problematisch.

In vielen Teams gibt es mehrere Personen in der Entwicklung und vielleicht eine Person mit besonderem Fokus auf Qualität.

Diese eine Person kann die Testbasis nicht dauerhaft allein pflegen.

Die Testbasis gehört deshalb in die Verantwortung des gesamten Teams.

Für mich ist eine Anforderung erst dann wirklich fertig, wenn auch die Testbasis aktualisiert wurde.

Nicht wenn der Code entwickelt wurde.

Nicht wenn der Code ausgerollt wurde.

Sondern dann, wenn die Testbasis den aktuellen Stand des Produkts widerspiegelt.

Mein wichtigster Rat

Wenn ihr morgen genau eine Sache verbessern möchtet, dann schaut euch die Struktur eurer Testbasis an.

Passt sie wirklich zu eurem Produkt?

Erkennt ihr die fachlichen Bereiche wieder?

Findet ihr die richtigen Tests schnell?

Könnt ihr Änderungen gezielt vornehmen?

Eine gute Testbasis beginnt nicht mit mehr Testfällen.

Sie beginnt mit einer Struktur, durch die das Team auch in einem Jahr noch durchblickt.