Automatisierte Tests sind Code mit Wartungspflicht
Eine Testreihe ist nur so viel wert wie das Vertrauen in sie. Sobald rote Läufe zur Gewohnheit werden, hat die Automatisierung ihren Zweck verloren.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die meisten Testreihen sterben nicht an Technik, sondern an Zuständigkeit
Der übliche Verlauf ist immer derselbe. Jemand baut mit Begeisterung eine Reihe automatisierter Tests, sie laufen ein halbes Jahr, dann ändert sich die Oberfläche, dreißig Tests werden rot, niemand hat Zeit, und der Lauf wird zunächst ignoriert und später abgeschaltet. Die Arbeit ist damit nicht nur verloren, sie hat das Vertrauen ins Automatisieren im Team beschädigt.
Die Ursache liegt fast nie im Werkzeug, sondern darin, dass die Testreihe einer Person gehört statt dem Team, dass niemand festgelegt hat, was ein roter Lauf für die Auslieferung bedeutet, und dass die Auswahl der Testfälle nie an einem Risiko ausgerichtet wurde, sondern an dem, was sich leicht automatisieren ließ.
Dazu kommt die falsche Ebene. Wer alles über die Oberfläche prüft, baut Tests, die langsam sind, bei jeder Gestaltungsänderung brechen und gelegentlich ohne erkennbaren Grund fehlschlagen. Genau diese sprunghaft fehlschlagenden Tests sind der Anfang vom Ende, weil das Team sich angewöhnt, den Lauf einfach zu wiederholen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, und wer setzt um
Automatisierung berührt Testmanagement, Entwicklung und Betrieb gleichzeitig. Diese fünf Zeilen legen fest, wer wofür geradesteht, und decken die üblichen Streitfälle ab.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Was überhaupt automatisiert wird | Testmanagement und Team gemeinsam, entlang von Risiko und Wiederholhäufigkeit | Die Testautomatisierung baut die ausgewählten Fälle und meldet zurück, was unverhältnismäßig teuer wird | Als Ziel wird alles automatisieren ausgegeben. Danach entsteht eine Reihe, deren Pflege mehr Zeit kostet als der manuelle Test, den sie ersetzen sollte. |
| Testdaten und Umgebungen | Der Betrieb stellt bereit, der Datenschutz entscheidet über die Herkunft der Daten | Die Testautomatisierung setzt vor jedem Lauf einen bekannten Ausgangszustand her | Alle teilen sich eine Umgebung. Dann scheitern Tests an Änderungen anderer, und niemand kann mehr unterscheiden, ob ein roter Lauf einen Fehler oder eine Kollision anzeigt. |
| Umgang mit einem roten Lauf | Die Verantwortung für die Auslieferung, also Produktverantwortung oder Release-Verantwortung | Das Entwicklungsteam behebt oder begründet, die Automatisierung liefert die Auswertung dazu | Rot wird zur Normallage. Ab dem Punkt, an dem ein roter Lauf nichts mehr auslöst, ist die gesamte Reihe wertlos, egal wie viele Tests darin stehen. |
| Pflege der Testreihe | Die Teamleitung, weil es um dauerhaft eingeplante Zeit geht | Das ganze Team, mit der Testautomatisierung als Ansprechpartner für das Rahmenwerk | Die Reihe hängt an einer Person. Deren Urlaub blockiert dann Auslieferungen, und nach einem Wechsel traut sich niemand mehr an den Aufbau heran. |
| Auswahl der Werkzeuge | Die Testautomatisierung zusammen mit der Entwicklung, weil die Anwendung prüfbar sein muss | Die Teams, die damit arbeiten und Tests ergänzen sollen | Ein Werkzeug wird nach einer Vorführung gewählt, ohne die eigene Anwendung anzusehen. Fehlen stabile Kennzeichen in der Oberfläche oder eine ansprechbare Schnittstelle, hilft kein Werkzeug der Welt. |
Was überhaupt automatisiert wird
- Wer entscheidet
- Testmanagement und Team gemeinsam, entlang von Risiko und Wiederholhäufigkeit
- Wer setzt um
- Die Testautomatisierung baut die ausgewählten Fälle und meldet zurück, was unverhältnismäßig teuer wird
- Stolperfalle
- Als Ziel wird alles automatisieren ausgegeben. Danach entsteht eine Reihe, deren Pflege mehr Zeit kostet als der manuelle Test, den sie ersetzen sollte.
Testdaten und Umgebungen
- Wer entscheidet
- Der Betrieb stellt bereit, der Datenschutz entscheidet über die Herkunft der Daten
- Wer setzt um
- Die Testautomatisierung setzt vor jedem Lauf einen bekannten Ausgangszustand her
- Stolperfalle
- Alle teilen sich eine Umgebung. Dann scheitern Tests an Änderungen anderer, und niemand kann mehr unterscheiden, ob ein roter Lauf einen Fehler oder eine Kollision anzeigt.
Umgang mit einem roten Lauf
- Wer entscheidet
- Die Verantwortung für die Auslieferung, also Produktverantwortung oder Release-Verantwortung
- Wer setzt um
- Das Entwicklungsteam behebt oder begründet, die Automatisierung liefert die Auswertung dazu
- Stolperfalle
- Rot wird zur Normallage. Ab dem Punkt, an dem ein roter Lauf nichts mehr auslöst, ist die gesamte Reihe wertlos, egal wie viele Tests darin stehen.
Pflege der Testreihe
- Wer entscheidet
- Die Teamleitung, weil es um dauerhaft eingeplante Zeit geht
- Wer setzt um
- Das ganze Team, mit der Testautomatisierung als Ansprechpartner für das Rahmenwerk
- Stolperfalle
- Die Reihe hängt an einer Person. Deren Urlaub blockiert dann Auslieferungen, und nach einem Wechsel traut sich niemand mehr an den Aufbau heran.
Auswahl der Werkzeuge
- Wer entscheidet
- Die Testautomatisierung zusammen mit der Entwicklung, weil die Anwendung prüfbar sein muss
- Wer setzt um
- Die Teams, die damit arbeiten und Tests ergänzen sollen
- Stolperfalle
- Ein Werkzeug wird nach einer Vorführung gewählt, ohne die eigene Anwendung anzusehen. Fehlen stabile Kennzeichen in der Oberfläche oder eine ansprechbare Schnittstelle, hilft kein Werkzeug der Welt.
Fünf Gründe, warum Testreihen abgeschaltet werden
- 01 Alles wurde über die Oberfläche geprüft und ist entsprechend langsam.
- 02 Tests schlagen sprunghaft fehl, und Wiederholen wird zur Gewohnheit.
- 03 Die Reihe gehört einer Person und nicht dem Team.
- 04 Testdaten wandern, jeder Lauf startet aus einem anderen Zustand.
- 05 Niemand hat festgelegt, was ein roter Lauf für die Auslieferung heißt.
Was diese Rolle verantwortet
Die Aufgabe ist weniger das Schreiben einzelner Tests als der Aufbau von etwas, das ein Team dauerhaft benutzen kann, ohne dass eine Person daneben stehen muss.
Die Ebene bestimmen
Du entscheidest je Prüfung, ob sie auf der Ebene einzelner Funktionen, an der Schnittstelle oder über die Oberfläche gehört, und begründest die Verteilung mit Laufzeit und Wartungsaufwand.
Ein Rahmenwerk bauen, das andere benutzen
Du schaffst Bausteine, mit denen auch Kolleginnen und Kollegen ohne tiefe Kenntnis einen Test ergänzen können, statt jeden Testfall selbst zu schreiben.
Testdaten und Umgebungen sichern
Du sorgst dafür, dass jeder Lauf von einem bekannten Zustand ausgeht, und verhinderst, dass zwei Läufe sich über gemeinsame Daten gegenseitig zerschießen.
Sprunghafte Fehlschläge beseitigen
Du gehst den Ursachen nach, statt Läufe zu wiederholen, und kennst die üblichen Verdächtigen: feste Wartezeiten, Abhängigkeiten zwischen Testfällen, gemeinsam benutzte Daten.
In die Auslieferungsstrecke einbinden
Du bindest die Tests so ein, dass sie bei jeder Änderung laufen, dass das Ergebnis sichtbar ist und dass eine feste Regel gilt, was bei einem roten Lauf passiert.
Nutzen belegen
Du kannst zeigen, welche Fehler die Automatisierung gefunden hat und wie lange ein Durchlauf dauert, denn beides entscheidet darüber, ob die Reihe weiter gepflegt werden darf.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was den Alltag ausmacht, und was Leute falsch erwarten
Erwartet wird Testen. Tatsächlich verbringst du den Tag überwiegend mit Entwicklungsarbeit: Code schreiben, Code lesen, Anmerkungen einarbeiten, Abhängigkeiten aktualisieren, Laufzeiten verkürzen, Fehlerursachen in der eigenen Testreihe suchen. Wer aus dem manuellen Test kommt, unterschätzt regelmäßig, wie sehr diese Rolle eine Entwicklungsrolle ist.
Der zweite große Anteil ist die Diagnose fremder Fehler. Ein roter Lauf sagt zunächst nur, dass etwas nicht wie erwartet war. Ob die Anwendung falsch ist, der Test falsch, die Umgebung kaputt oder die Testdaten geändert wurden, musst du in wenigen Minuten unterscheiden können, sonst blockiert die Auslieferung.
Unterschätzt wird die politische Seite. Du lieferst regelmäßig Nachrichten, die niemand hören will, und zwar kurz vor einem Termin. Wer die Auswertung sachlich aufbereitet und die Entscheidung über das Weitergehen bewusst anderen überlässt, bleibt handlungsfähig. Wer sie selbst treffen will, gerät zwischen die Fronten.
Die Abgrenzung zum manuellen Testen
Beide Rollen brauchen dieselbe Grundlage, nämlich die Fähigkeit, aus unendlich vielen Möglichkeiten eine begründete Auswahl zu treffen. Danach trennen sie sich deutlich. Der manuelle Test arbeitet erkundend, prüft neue Funktionen, findet das Unerwartete und beurteilt, ob ein Ergebnis fachlich richtig ist. Die Automatisierung sichert das Bekannte gegen Rückschritte ab.
Daraus folgt, was sich nicht automatisieren lässt: die Frage, ob eine Anzeige verständlich ist, ob ein Ablauf für einen Menschen zumutbar bleibt, ob ein neuer Bereich Fehler enthält, an die vorher niemand gedacht hat. Wer glaubt, Automatisierung mache manuelles Testen überflüssig, hat den Zweck beider Tätigkeiten verwechselt.
Für den Einstieg in diese Rolle heißt das: Aus dem manuellen Test kommend fehlt dir die Entwicklungsseite, also eine Sprache, Versionsverwaltung, Code-Review und der Umgang mit einer Auslieferungsstrecke. Aus der Entwicklung kommend fehlt dir die Testmethodik, also Auswahlverfahren, Risikobewertung und ein Blick, der nicht nur den erwarteten Weg prüft. Beide Lücken sind schließbar, aber man sollte wissen, welche man hat.
Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden
Der erste Unterschied ist die Behandlung sprunghafter Fehlschläge. Die eine nimmt jeden davon als Fehler in der eigenen Testreihe und beseitigt die Ursache. Der andere baut eine Wiederholung ein, und drei Monate später glaubt niemand mehr einem roten Lauf. Es gibt in dieser Rolle keine Entscheidung, die stärker über den Wert der Arbeit bestimmt.
Der zweite ist die Laufzeit. Eine Testreihe, die zwei Stunden braucht, wird nicht bei jeder Änderung gestartet, sondern nachts, und damit verliert sie den größten Teil ihres Nutzens. Wer Tests parallelisiert, auf die passende Ebene verschiebt und unnötige Wartezeiten entfernt, verändert die Arbeitsweise des ganzen Teams.
Der dritte ist die Übergabe. Wer ein Rahmenwerk so baut, dass ein Entwickler einen Test in zwanzig Minuten ergänzt, hat eine Reihe, die mit der Anwendung wächst. Wer alles selbst schreibt, hat einen Engpass und wird zum Flaschenhals in genau dem Moment, in dem es eilig wird.
Wohin die Rolle führt
Drei Richtungen sind üblich. Die erste geht tiefer in die Entwicklung, bis zu Rollen, die Werkzeuge und Umgebungen für andere Teams bauen. Die zweite geht in die Auslieferungsstrecke und den Betrieb, weil Testautomatisierung und Auslieferung technisch dieselbe Strecke teilen. Die dritte geht in Richtung Qualitätssicherung und Testmanagement, wo Auswahl, Risiko und Abstimmung wichtiger werden als Code.
Zwei Felder wachsen daneben: Lasttests, also die Frage, wie sich eine Anwendung unter vielen gleichzeitigen Zugriffen verhält, und automatisierte Prüfungen auf Sicherheitsschwächen als Teil der Auslieferung. Beides baut auf denselben Fähigkeiten auf und ist deutlich dünner besetzt als der klassische Funktionstest.
Als Nachweis ist die Spezialisierungsstufe des ISTQB für Testautomatisierung verbreitet und wird in Ausschreibungen genannt. Zu den Zahlen weiter unten passt ein Hinweis: Der Median ist die belastbarere Größe, weil einzelne sehr hohe Verdienste den Durchschnitt anheben.
Dazu passende Kurse
Wenn du den Schritt formal belegen willst, gibt es Kurse, in denen du den anerkannten Nachweis für Testautomatisierung erwirbst .
Die amtlichen Zahlen zu dieser Rolle
Die amtliche Systematik führt Testautomatisierung nicht getrennt, sondern unter Softwareentwicklung, und inhaltlich ist das richtig, weil die Tätigkeit überwiegend aus Entwicklungsarbeit besteht. Die Kehrseite: In derselben Zelle stecken alle, die keine Tests bauen, und ein Vergleich zwischen manuellem Test und Automatisierung ist daraus nicht ablesbar. Das Anforderungsniveau Spezialist beschreibt zudem den Zuschnitt der Stelle und nicht deinen Weg dorthin, wer aus dem manuellen Test kommt, landet mit dem ersten Automatisierungsjahr also nicht automatisch in dieser Zeile. Die Werte gelten für Vollzeit ohne Sonderzahlungen, Weihnachts- und Urlaubsgeld kommen noch dazu.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43413, Durchschnitt 6.238 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Wo du genau das übst
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Ist Testautomatisierung eine Testrolle oder eine Entwicklungsrolle?
Welche Sprache soll ich lernen?
Wie viel soll über die Oberfläche geprüft werden?
Übernimmt KI diese Rolle?
Passt thematisch dazu
Wenn die Entscheidung über das Werkzeug ansteht, hilft der direkte Vergleich, welches Werkzeug für Oberflächentests zu euch passt .
Weil jeder Lauf einen bekannten Zustand braucht, gehört dazu die Frage, wie Testdaten entstehen, die man benutzen darf .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Eine Testreihe, der das Team wirklich glaubt
Bei cmt baust du Tests auf mehreren Ebenen, von der einzelnen Funktion über die Schnittstelle bis zum durchgehenden Ablauf, und lernst dabei, warum Läufe sprunghaft fehlschlagen.
Passt dazu
- Softwaretester werden: der Weg über ISTQB und die erste Testautomatisierung
- Python-Entwickler werden: der Einstieg ist leicht, der Betrieb nicht
- Release Engineer: zwischen dem letzten Commit und dem ersten Nutzer
- Java-Entwickler werden: die Sprache ist der kleinere Teil