Wer verantwortet eure Testautomatisierung langfristig?

Wir glauben jedoch, dass sich dahinter eine tieferliegende Frage verbirgt:

„Wer sollte für die Testautomatisierung verantwortlich sein?“

Und noch grundsätzlicher:

„Für welche verschiedenen Bereiche der Testautomatisierung kann man verantwortlich sein?“

Die zwei Bereiche der Testautomatisierung: Test Harness und End User Workflows

Wir bei Eficode teilen die Testautomatisierung gerne in zwei klar getrennte Bereiche auf:

Test Harness

Ein Test Harness lässt sich auf viele Arten definieren. Wir verstehen darunter jedoch „alles, was ein Testfall zur Ausführung benötigt“. Die wichtigsten Komponenten sind:

• die ausgewählten Test-Tools

• die Umgebungen

• die Testdaten

• die Continuous-Delivery-Lösung

• weitere unterstützende Tools (z. B. Docker)

End User Workflows

In diesem zweiten Bereich der Testautomatisierung geht es um den Inhalt eines Testfalls: Was macht er und warum? Das ist eng mit den Anforderungen an die Software selbst und den geschäftlichen Problemen verknüpft, die sie löst.

Habt ihr euch schon einmal gefragt, warum bei der Behebung von Testfehlern so häufig Verantwortlichkeiten hin- und hergeschoben werden? Man hört dann Sätze wie: „Unsere Testfälle sind in der Pipeline fehlgeschlagen – wer könnte das beheben?“ Genau darin liegt der Grund. Ein Test kann fehlschlagen, weil etwas im Test Harness nicht stimmt. Oder weil der fachliche Inhalt des Testfalls nicht mit der getesteten Anwendung übereinstimmt.

Verantwortungsprobleme im Projekt

Wenn Tests bei der Feature-Entwicklung nicht Schritt halten können

In den frühen Projektphasen entsteht eine Art fortlaufendes Rennen zwischen der Feature-Entwicklung und der Entwicklung des Test Harness. Um Entwickeltes zu testen, müsst ihr auch neue Funktionen zum Test Harness hinzufügen. Dabei kann es verlockend sein, beim Test Harness den einfachen Weg zu wählen und ihn „einfach schnell fertigzustellen“.

Wenn jedoch der Funktionsumfang wächst und neue Testfälle automatisiert werden, geht unserer Erfahrung nach die meiste Zeit in die Analyse, warum bestehende Testfälle fehlgeschlagen sind. Dadurch bleibt euch immer weniger Zeit, neue Testfälle zu schreiben. Kommt euch das bekannt vor?

Wenn niemand Verantwortung übernimmt

Wenn niemand Verantwortung für den Bereich End User Workflows der Testautomatisierung übernimmt, entstehen Probleme. Im schlimmsten Fall, den wir erlebt haben, können oder wollen die QA-Experten nicht einmal mit den Feature-Entwicklern sprechen: „Ich habe diese Tests nicht geschrieben, also bin ich nicht für ihre Fehler verantwortlich.“

Solche Situationen erschweren die Analyse der Testfälle zusätzlich und können das Team ernsthaft in Schwierigkeiten bringen, weil neue Features möglicherweise nicht getestet werden – zumindest nicht automatisiert.

Verantwortungsprobleme lösen

Es gibt viele Möglichkeiten, diese beiden Probleme anzugehen. Zum Beispiel:

• Ein fest zugewiesener QA-Experte oder eine SDET-Position im Team kann beide Herausforderungen gemeinsam mit dem restlichen Team bewältigen. 

• Ein Tester könnte für die End User Workflows verantwortlich sein, während das Entwicklungsteam den Test Harness verantwortet. Das funktioniert hervorragend, da es funktionsübergreifende Teams auf natürliche Weise fördert. 

• Vielleicht können der Product Owner oder ein anderer Geschäftsverantwortlicher mit Unterstützung eines QA-Experten und des restlichen Entwicklungsteams ATDD einsetzen – das Fachteam erstellt die End User Workflows, das Entwicklungsteam automatisiert sie.

• Eine der besten Möglichkeiten, Testprobleme nach links zu verlagern, besteht darin, die Experten bereits bei der Definition neuer Features einzubeziehen – gemeinsam mit anderen Stakeholdern wie Sicherheitsverantwortlichen. So werden das Testen und die Weiterentwicklung des Test Harness Teil des Feature-Designs.

Es gibt keine Universallösung. Sie muss in eurem individuellen Kontext sinnvoll sein. Bei der Abstimmung eurer Arbeitsweisen solltet ihr euch jedoch auf Folgendes einigen: 

• Wie erstellen wir einen hochwertigen Test Harness? 

• Wie stellen wir sicher, dass die End User Workflows das abbilden, was wir tatsächlich wollen?

Verantwortung für die Testautomatisierung während der Wartungsphase

Wenn eure Testfälle ständig unnötig fehlschlagen, die Analyse von Testfehlern ewig dauert oder schon die Implementierung eines Testfalls zu viel Zeit in Anspruch nimmt, leidet ihr wahrscheinlich unter erheblichen technischen Schulden.   

Codequalität hat sich von den klassischen Schimpfwörtern pro Minute hin zu der Frage entwickelt, wie einfach und reibungslos sich automatisierte Testfälle zu euren Anwendungen hinzufügen und warten lassen. Ständige Frustration ist ein Zeichen dafür, dass es Zeit ist, technische Schulden abzubauen. Langfristig zahlt sich das aus, denn 60 % der Lebensdauer eurer Software entfallen auf die Wartung. 

Befindet sich euer Softwareprojekt in der Wartungsphase, solltet ihr keine allzu großen Änderungen mehr erwarten. Wie die Software selbst benötigen auch der Test Harness und die End User Workflows nur minimale Anpassungen. 

Auch wenn der Aufwand möglicherweise gering ist, kann es sinnvoll sein, diese Aufgabe zusammen mit dem Projekt an ein Team zu übergeben, das mehrere Anwendungen wartet. Oft ist es nicht einmal sinnvoll, dies intern zu erledigen. Möglicherweise ist es sinnvoller, sowohl die Anwendung als auch die Wartung der Testautomatisierung auszulagern.

Kurz gesagt: Wer sollte die Testautomatisierung verantworten?

Wer sollte also die Verantwortung für die Testfälle übernehmen? Wir bei Eficode sind der Meinung, dass alle, die an der Projektentwicklung beteiligt sind, auch die Tests verantworten sollten. Wie die Arbeit zwischen Test Harness und End User Workflows aufgeteilt wird, sollte von allen Beteiligten ausdrücklich vereinbart werden. 

Letztlich sind Tests genauso Teil des Produkts wie der Quellcode.