Der Weg zum Softwaretester: vom Testfall zur Automatisierung

Was den Alltag ausmacht, und was Leute erwarten

Erwartet wird oft, dass Testen heißt, eine fertige Anwendung so lange zu bedienen, bis etwas kaputtgeht. Tatsächlich beginnt die Arbeit vor der Entwicklung: Anforderungen lesen, Unklarheiten benennen, Fälle sammeln, die niemand bedacht hat. Ein Fehler, der in der Anforderung gefunden wird, kostet ein Gespräch, derselbe Fehler nach der Auslieferung kostet einen Nachtrag mit allem, was daran hängt.

Der zweite große Anteil ist Kommunikation, und zwar mit einem eingebauten Konflikt. Du meldest die Arbeit anderer als fehlerhaft, oft unter Zeitdruck vor einem Termin. Wer das als Rechthaben betreibt, wird umgangen. Wer den Fehler sachlich beschreibt, seine Wirkung einschätzt und die Entscheidung über die Behebung anderen überlässt, wird gefragt.

Dazu kommt der unspektakuläre Teil: Testdaten beschaffen, Umgebungen aktuell halten, nach einer Auslieferung dieselben Prüfungen wiederholen. Genau dieser Teil ist der Grund, warum Automatisierung im Testberuf so früh zum Thema wird.

Der Weg hinein, und was die Zertifikatslandschaft wirklich hergibt

Testen ist die häufigste Tür zum Quereinstieg in die IT, und das aus einem sachlichen Grund: Wer eine Fachanwendung als Anwender kennt, weiß, welche Fälle im Alltag vorkommen und welche Fehler wehtun. Aus Sachbearbeitung, Support, Buchhaltung oder Logistik kommend bringst du fachliches Wissen mit, das im Team knapp ist.

Die Zertifikatslandschaft ist übersichtlich aufgebaut. Das Foundation Level ist der Einstieg und die gemeinsame Sprache. Darauf setzen Erweiterungen auf, etwa für agiles Testen, sowie die Stufen für Testanalyse, technische Testanalyse und Testmanagement. Daneben stehen Spezialisierungen, unter anderem für Testautomatisierung und für das Testen von Systemen mit KI-Anteil. ISTQB-Zertifikate laufen nicht ab, eine Verlängerung wie bei Herstellerzertifikaten gibt es also nicht.

Sammlerwert haben Nachweise, die niemand im Projekt anwendet. Zwei Stufen ohne ein einziges Projekt dahinter beeindrucken niemanden im Fachgespräch, während ein Foundation Level plus eine kleine, selbst gebaute Testreihe sofort Gesprächsstoff liefert. Frag im Zweifel bei einer Ausschreibung nach, welche Stufe dort wirklich verlangt wird.

Vom manuellen Test zur Automatisierung

Dieser Schritt ist ein Berufswechsel innerhalb des Berufs, und er wird regelmäßig unterschätzt. Du hörst nicht auf zu testen, aber deine Arbeit besteht ab jetzt aus Code, der gepflegt, gelesen und in einer Versionsverwaltung geführt wird. Wer das nur nebenbei macht, produziert eine Testreihe, die nach einem halben Jahr niemand mehr anfasst.

Die häufigste Fehlentscheidung ist die Ebene. Alles über die Oberfläche zu prüfen ist verführerisch, weil es dem manuellen Vorgehen ähnelt. Solche Tests sind aber langsam, hängen an jeder Gestaltungsänderung und schlagen sprunghaft fehl. Der übliche Ausweg besteht darin, den größten Teil eine Ebene tiefer zu prüfen, bei einzelnen Funktionen und an den Schnittstellen, und über die Oberfläche nur die wichtigsten Wege abzudecken.

Die zweite Falle sind Tests, die manchmal fehlschlagen. Ursache sind fast immer feste Wartezeiten, Abhängigkeiten zwischen Testfällen oder gemeinsam benutzte Testdaten. Wer solche Läufe einfach wiederholt, bis sie grün sind, gewöhnt das Team daran, rote Ergebnisse zu ignorieren, und ab da hat die Automatisierung keinen Wert mehr.

Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden

Der erste Unterschied ist die Auswahl. Die eine prüft dreißig Fälle und trifft damit die Risiken, der andere prüft hundert und übersieht denselben Fehler. Diese Fähigkeit kommt aus der Verbindung von Verfahren und Fachwissen über das Produkt, und deshalb wird jemand mit fachlichem Hintergrund in diesem Beruf schnell wertvoll.

Der zweite Unterschied ist das Verhältnis zur Entwicklung. Wer als Teil desselben Teams arbeitet, früh mitliest und Fehler ohne Vorwurf beschreibt, bekommt Testbarkeit geschenkt: Schnittstellen zum Prüfen, Testdaten, brauchbare Protokolle. Wer als Kontrollinstanz auftritt, bekommt nichts davon und muss alles über die Oberfläche erkämpfen.

Der dritte Unterschied ist die Pflege. Automatisierte Tests sind Software mit allen Folgen, und wer sie aufräumt, benennt und wartbar hält, hat nach zwei Jahren eine Testreihe, auf die sich das Team verlässt. Wer nur ergänzt, hat einen Haufen, den niemand mehr versteht.

Wohin es von hier weitergeht

Drei Richtungen sind üblich. Testautomatisierung, wo du dich in Richtung Entwicklung bewegst und am Ende Werkzeuge und Rahmenwerke für andere baust. Testmanagement, wo Planung, Risikobewertung und Abstimmung mit Fachbereich und Auftraggeber in den Vordergrund rücken. Und die Spezialisierung auf ein Feld mit eigenen Regeln, etwa Sicherheit, Leistung oder Systeme mit KI-Anteil.

Zur Frage, was KI im Testberuf verändert: Werkzeuge schlagen inzwischen Testfälle vor und erzeugen Testdaten, und das nimmt Fleißarbeit ab. Was bleibt, ist die Entscheidung, welches Risiko geprüft wird, und die Beurteilung, ob ein Ergebnis richtig ist. Dazu kommt ein neues Feld, nämlich das Testen der KI-Anteile selbst, für die die üblichen Erwartungen an gleichbleibende Ergebnisse nicht gelten.