Inhalt
Warum ist die Frage falsch gestellt?
Testautomatisierung ist kein Projekt mit Abschluss, sondern ein Bestand mit Wartungslast. Die Frage lautet deshalb nicht „wer baut sie", sondern „wer pflegt sie in drei Jahren". Wer das überspringt, kauft eine Testsuite, die nach zwei Releases rot ist, dann übersprungen und schließlich abgeschaltet wird - und hat den Aufwand zweimal.
Wie stehen die beiden Wege gegeneinander?
| Kriterium | Interner Aufbau | Externe Vergabe |
|---|---|---|
| Anlaufzeit | Lang. Werkzeugauswahl, Lernkurve und die ersten verworfenen Ansätze inklusive | Kurz. Erfahrung ist eingekauft, die ersten Tests laufen in Tagen |
| Fachwissen über das Produkt | Vorhanden. Der größte Vorteil und oft unterschätzt | Muss aufgebaut werden, kostet die ersten Wochen |
| Werkzeug- und Methodenwissen | Muss aufgebaut werden | Vorhanden |
| Kosten kurzfristig | Niedriger, aber verdeckt: Entwicklerzeit, die anderswo fehlt | Höher und sichtbar in der Rechnung |
| Kosten langfristig | Niedriger, wenn die Kompetenz im Haus bleibt | Laufend, solange extern gepflegt wird |
| Priorisierung im Alltag | Verliert regelmäßig gegen das nächste Kundenticket | Geschützt, weil beauftragt und terminiert |
| Testtiefe | Steigt langsam, dafür passgenau zum Produkt | Steigt schnell, kann aber am Produktverständnis vorbeigehen |
| Wartbarkeit nach Übergabe | Hoch, weil die Autoren im Haus sitzen | Abhängig davon, ob Wissenstransfer Teil des Auftrags war |
| Typischer Fehlschlag | „Wir machen das nebenbei" | Übergabe ohne Wissenstransfer |
Wo scheitert der interne Aufbau?
Fast immer an derselben Stelle: Testautomatisierung läuft neben dem Tagesgeschäft und verliert jede Priorisierung gegen ein Kundenticket. Nach einem Quartal existieren zwanzig Tests, nach zwei sind fünf davon rot, und niemand hat Zeit, sie zu reparieren.
Der zweite Klassiker ist die Werkzeugwahl ohne Erfahrung. Ein Framework, das nicht zur Anwendung passt - GUI-Automatisierung für eine Qt-Oberfläche mit einem Werkzeug, das nur den DOM kennt -, kostet später mehr als der gesamte Aufbau. Diese Entscheidung fällt am Anfang, wenn das Wissen am geringsten ist.
Der dritte ist die fehlende Verankerung. Tests, die nicht als Merge-Gate laufen, sind Dokumentation, keine Absicherung. Solange ein roter Test niemanden aufhält, wird er nicht repariert.
Wo scheitert die externe Vergabe?
An der Übergabe. Eine Suite, die extern entstanden ist und intern niemandem gehört, wird beim ersten größeren Umbau nicht angepasst, sondern deaktiviert. Der Fehler liegt selten in der Suite - er liegt darin, dass Wissenstransfer nicht Teil des Auftrags war.
Der zweite Grund ist fehlendes Produktverständnis. Ein externer Dienstleister testet, was spezifiziert ist. Die interessanten Fehler liegen aber dort, wo die Spezifikation schweigt: in Sonderfällen, historischen Datenbeständen und der einen Konstellation, die nur ein Kunde hat. Diese Fälle kennt Ihr Team.
Welche Mischform funktioniert?
Extern aufbauen, intern weiterführen - mit drei Bedingungen, die nicht verhandelbar sind:
Von Anfang an gemeinsam. Mindestens eine Person aus Ihrem Team arbeitet in der Aufbauphase mit, nicht erst bei der Übergabe. Wissenstransfer am Projektende ist ein Termin, kein Transfer.
Werkzeuge nach Ihrer Landschaft wählen, nicht nach Vorliebe des Dienstleisters. Wenn Ihr Team C# schreibt, ist eine Suite in einer anderen Sprache eine Übergabebremse - unabhängig davon, wie elegant sie ist.
Die CI-Verankerung ist Teil der Lieferung. Tests, die nicht als Merge-Gate laufen, zählen nicht als geliefert. Das gehört in die Leistungsbeschreibung, nicht in die Hoffnung.
Was kostet eine Testsuite im Unterhalt?
Die Zahl, die in keinem Angebot steht. Erfahrungsgemäß liegt der laufende Pflegeaufwand bei einem spürbaren Anteil des Aufbauaufwands pro Jahr - getrieben von Änderungen an der Oberfläche, an Schnittstellen und an Testdaten.
Zwei Hebel senken ihn deutlich:
- Tests gegen stabile Schnittstellen statt gegen die Oberfläche, wo immer es geht. Ein API-Test überlebt ein Redesign, ein GUI-Test nicht.
- Echte Abhängigkeiten statt Mocks in der Integrationsebene. Ein Mock muss bei jeder Änderung nachgezogen werden; eine über Testcontainers hochgefahrene Datenbank zieht sich selbst nach. Wie wir das schneiden, steht in E2E-Tests gegen echte Datenbanken mit Testcontainers.
Welche Testebenen lohnen sich zuerst?
Nicht die, die am sichtbarsten sind. Die Reihenfolge, die sich bei uns bewährt hat:
- Integrationstests gegen echte Abhängigkeiten. Sie finden die Fehler, die tatsächlich auftreten - Transaktionsgrenzen, Migrationsreihenfolgen, Zeitzonenverhalten - und sind erstaunlich stabil, weil sie nicht an der Oberfläche hängen.
- Unit-Tests im fachlichen Kern. Schnell, billig, aber nur dort wertvoll, wo tatsächlich Logik sitzt. Getter zu testen erhöht die Abdeckungszahl und sonst nichts.
- E2E-Tests für die kritischen Pfade. Anmeldung, Bestellstrecke, der eine Ablauf, dessen Ausfall teuer wird. Bewusst wenige - sie sind die teuersten im Unterhalt.
- GUI-Automatisierung zuletzt und nur dort, wo die Fachlogik ausschließlich über die Oberfläche erreichbar ist. In Fachverfahren mit Formularlogik ist das der Regelfall, in einer API-getriebenen Anwendung die Ausnahme.
Wer umgekehrt anfängt - erst GUI, dann der Rest -, hat nach einem halben Jahr eine langsame, instabile Suite und keine Aussage über den Kern.
Woran erkennt man einen brauchbaren Dienstleister?
An drei Fragen, die er von sich aus stellt:
- „Was läuft heute in eurer CI?" Wer das nicht fragt, plant eine Suite, die neben der Pipeline steht.
- „Welche Fehler sind euch zuletzt in Produktion durchgerutscht?" Das ist die einzige belastbare Grundlage für die Priorisierung. Wer stattdessen nach der Wunsch-Abdeckungszahl fragt, optimiert eine Kennzahl.
- „Wer bei euch übernimmt die Suite?" Wenn diese Frage nicht kommt, ist Wissenstransfer nicht eingeplant.
Umgekehrt ein Warnsignal: ein Angebot, das eine Zielabdeckung in Prozent zusichert, ohne den Code gesehen zu haben. Abdeckung ist ein Nebenprodukt, kein Ziel - 90 % über triviale Pfade sind weniger wert als 40 % über die Stellen, an denen es weh tut.
Was ist mit KI-generierten Tests?
Sie verschieben die Rechnung, aber nicht die Frage. Ein Agent schreibt Tests schnell und in Menge - und genau das ist das Risiko: Eine große Suite aus Tests, die alle gegen dieselbe falsche Annahme laufen, ist gefährlicher als gar keine, weil sie Sicherheit vortäuscht.
Was hilft, ist die Absicherung dahinter. Bei uns durchlaufen agentenerzeugte Tests dieselben Gates wie handgeschriebene, und ein Regressionstest gilt erst dann als echt, wenn er ohne den zugehörigen Fix nachweislich fehlschlägt. Ohne diesen Nachweis ist ein grüner Test nur eine Behauptung. Wie wir das absichern, steht in Welche Leitplanken wir Agenten setzen.
Für die Ausgangsfrage heißt das: KI senkt die Kosten des Aufbaus deutlich, die des Unterhalts nur wenig. Die Frage „wer pflegt sie in drei Jahren" bleibt unverändert.
Was ist der übliche Einstieg?
Eine Bestandsaufnahme der vorhandenen Testlandschaft: Was deckt ab, was ist rot, was ist flaky, wo liegt die Laufzeit, was läuft überhaupt in der CI. Das sind wenige Tage Aufwand und beantwortet die Ausgangsfrage meist von selbst.
In der Praxis ist das Ergebnis selten „alles neu". Häufiger ist es: eine Handvoll instabiler Tests stabilisieren, die Laufzeit halbieren, die Suite ins Merge-Gate hängen - und danach entscheiden, wer ausbaut. Details unter Qualitätssicherung & Testautomatisierung.