Qualität als Beruf

Vom ersten Testfall zur eigenen Automatisierung

Testen ist keine Frage der Gründlichkeit, sondern der Auswahl: Du kannst nie alles prüfen, also entscheidest du begründet, was geprüft wird und was nicht.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Vollständiges Testen gibt es nicht, und daran scheitern die meisten Einstiege

Wer ohne Ausbildung ins Testen kommt, prüft zuerst das, was er sieht: die Eingabemaske, den Normalfall, den offensichtlichen Fehler. Das findet Fehler, aber unsystematisch, und es lässt sich niemandem erklären. Auf die Frage, warum dieser Fall geprüft wurde und jener nicht, gibt es dann keine Antwort außer dem Gefühl.

Genau darauf zielt die Methodik im Testberuf. Äquivalenzklassen, Grenzwerte, Entscheidungstabellen und Zustandsübergänge sind keine Prüfungsinhalte um ihrer selbst willen, sondern Verfahren, mit denen du aus unendlich vielen möglichen Eingaben eine begründete Auswahl triffst. Wer sie beherrscht, prüft weniger und findet mehr.

Der zweite Bruch kommt beim Fehlerbericht. Ein Bericht, in dem steht, dass etwas nicht geht, kostet die Entwicklung eine halbe Stunde Rückfrage und kommt oft ungelöst zurück. Ein Bericht mit Schritten zur Reproduktion, erwartetem und tatsächlichem Verhalten, Umgebung und einer Einschätzung, wen der Fehler wie hart trifft, wird bearbeitet. Diese Unterscheidung entscheidet darüber, ob jemand im Team als nützlich gilt.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Schritt für Schritt

Der Weg in sieben Schritten

Die ersten vier Schritte machen dich im Projekt einsetzbar, die letzten drei sind ein Berufswechsel innerhalb des Berufs. Wer beides gleichzeitig anfängt, macht keines davon richtig.

  1. 1

    Testen als Verfahren lernen

    Äquivalenzklassen und Grenzwerte für Eingaben, Entscheidungstabellen für Regelwerke, Zustandsübergänge für alles, was einen Ablauf hat. Nimm ein Formular, das du kennst, und leite dazu zwanzig Testfälle ab, die sich alle begründen lassen.

    Geschafft, wenn: du erklärst zu jedem Testfall, welches Risiko er abdeckt

  2. 2

    Fehlerberichte schreiben, die angenommen werden

    Reproduktionsschritte, erwartetes Verhalten, tatsächliches Verhalten, Umgebung und Datenstand. Trenn dabei die Schwere von der Priorität: Ein Schreibfehler auf der Startseite kann dringender sein als ein Absturz in einer Funktion, die niemand benutzt.

    Geschafft, wenn: die Entwicklung fragt bei deinen Berichten nicht mehr nach

  3. 3

    Das Foundation Level als gemeinsame Sprache

    Der Lehrplan liegt in der Version 4.0 vor und ordnet genau das, was du in den ersten beiden Schritten getan hast. Der Wert liegt weniger im Zertifikat als darin, dass du danach dieselben Begriffe benutzt wie das Team. In Deutschland läuft die Prüfung über das German Testing Board und dessen akkreditierte Anbieter.

    Geschafft, wenn: du kommst mit deinem Nachweis durch die Vorauswahl

  4. 4

    Im Team testen statt danach

    In agil arbeitenden Teams ist Testen keine Phase am Ende, sondern Teil jeder Aufgabe. Du liest Anforderungen mit der Frage, wie man sie prüfen würde, und bringst fehlende Fälle ein, bevor jemand sie baut. Die ISTQB-Erweiterung für agiles Testen behandelt genau diesen Zuschnitt.

    Geschafft, wenn: Fälle, die du nennst, landen in der Anforderung statt im Fehlerbericht

  5. 5

    Programmieren lernen

    Python oder JavaScript und TypeScript sind die üblichen Einstiege, dazu Git. Du brauchst keine Anwendungsentwicklung, aber Datentypen, Schleifen, Funktionen, Fehlerbehandlung und die Fähigkeit, fremden Code zu lesen. Genau hier trennt sich, wer im manuellen Test bleibt und wer weitergeht.

    Geschafft, wenn: du liest den Code der Anwendung, die du prüfst

  6. 6

    Auf der richtigen Ebene automatisieren

    Wenige Tests über die Oberfläche, viele darunter auf der Ebene einzelner Funktionen und Schnittstellen. Playwright deckt den Weg durch die Oberfläche ab, pytest die Ebene darunter. Der häufigste Fehler ist, alles über die Oberfläche zu prüfen: Solche Tests sind langsam, brechen bei jeder Gestaltungsänderung und werden nach einem halben Jahr abgeschaltet.

    Geschafft, wenn: deine Testreihe läuft bei jeder Änderung und wird nicht ignoriert

  7. 7

    Vertiefen und Richtung wählen

    Von hier führen zwei Wege weiter: tiefer in die Automatisierung, wo die ISTQB-Stufe für Testautomatisierung den Rahmen ordnet, oder in Richtung Steuerung und Testmanagement. Ein drittes Feld ist der Test von Systemen mit KI-Anteil, für den es inzwischen eigene Lehrpläne gibt.

    Geschafft, wenn: du hast eine Richtung, in der die nächsten zwei Jahre einen Plan haben

Sechs Stationen vom ersten Testfall zur Automatisierung

  1. 01 Testverfahren lernen und Fälle begründet auswählen.
  2. 02 Fehlerberichte schreiben, die nicht zurückkommen.
  3. 03 Das Foundation Level als gemeinsame Sprache erwerben.
  4. 04 Im Team testen statt am Ende der Entwicklung.
  5. 05 Eine Programmiersprache und Git dazunehmen.
  6. 06 Auf der richtigen Ebene automatisieren und dann vertiefen.
Was du mitnimmst

Was du am Ende dieses Wegs kannst

Der Weg hat zwei Hälften, und die zweite ist ein anderer Beruf als die erste. Beide Hälften beginnen mit derselben Fähigkeit, nämlich begründet auszuwählen, was geprüft wird.

Testfälle begründen

Du leitest Testfälle aus Klassen, Grenzen und Entscheidungstabellen ab und kannst zu jedem Fall sagen, welches Risiko er abdeckt und warum ein anderer weggelassen wurde.

Fehler berichten, die bearbeitet werden

Du schreibst Reproduktionsschritte, erwartetes und tatsächliches Verhalten und trennst dabei die Schwere des Fehlers von der Frage, wie dringend er behoben werden muss.

Risiko statt Vollständigkeit

Du priorisierst nach Eintrittswahrscheinlichkeit und Schaden, kannst begründen, warum ein Bereich ungeprüft bleibt, und machst diese Entscheidung sichtbar, statt sie zu verschweigen.

Im Team statt am Ende testen

Du bringst Testbarkeit schon in die Anforderung ein, prüfst nicht erst nach der Entwicklung und weißt, was in einer gemeinsamen Definition von fertig stehen muss.

Automatisieren, was sich lohnt

Du entscheidest, welche Prüfung als Test auf Oberflächenebene sinnvoll ist und welche eine Ebene tiefer gehört, und vermeidest damit die Wartungslast, an der die meisten Automatisierungen sterben.

Tests stabil halten

Du erkennst die üblichen Ursachen für sprunghaft fehlschlagende Tests, etwa feste Wartezeiten und Abhängigkeiten zwischen Testfällen, und baust sie ab, statt sie zu wiederholen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

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.

Zur Statistik weiter unten gehört ein Vorbehalt: Für den Softwaretest gibt es keine eigene amtliche Berufsgattung, die Tätigkeit läuft unter Softwareentwicklung. Die Zellen zeigen also die Nachbartätigkeit, und ob manueller Test und Testautomatisierung unterschiedlich bezahlt werden, lässt sich daraus nicht ablesen.

Dazu passende Kurse

Welche Stufe zu deinem Stand passt, siehst du an den Zertifizierungswege im Softwaretest auf einen Blick.

Wenn beim Schritt in die Automatisierung der Code fehlt, holst du dir die Programmierkenntnisse für die Testautomatisierung an derselben Stelle.

Was verdient man

Die amtlichen Zahlen zu dieser Rolle

Für den Softwaretest gibt es keine eigene amtliche Berufsgattung, die Tätigkeit wird unter Softwareentwicklung geführt, und genau das zeigen die beiden Zellen: die Nachbartätigkeit und nicht den Testberuf selbst. Ob manueller Test und Testautomatisierung unterschiedlich bezahlt werden, lässt sich daraus nicht ablesen, weil beides in derselben Gattung steckt. Fachkraft und Spezialist bezeichnen den Zuschnitt der Stelle und nicht deine Berufserfahrung, und die Werte gelten für Vollzeit ohne Sonderzahlungen, Weihnachts- und Urlaubsgeld kommen also noch dazu. Der Median ist die belastbarere Zahl, weil einzelne Spitzenverdienste den Durchschnitt heben.

Amtliche Medianverdienste, April 2025

Brutto im Monat

Statistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.

Softwareentwicklung Fachkraft 4.201 €

KldB 43412, Durchschnitt 4.608 €, gerundet rund 50.000 € im Jahr ohne Sonderzahlungen

Softwareentwicklung Spezialist 5.986 €

KldB 43413, Durchschnitt 6.238 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen

02k4k6k
  • 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.

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
LimeSurvey - Anwendertraining Teil 1 (Grundlagen)
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
BricsCAD 2D Schulung Grundkurs
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
BricsCAD 3D Schulung - Grundlagen

Häufige Fragen

Brauche ich das ISTQB-Zertifikat wirklich?
Für den Einstieg ist es der wirksamste einzelne Schritt, weil es in vielen Ausschreibungen namentlich steht und die Vorauswahl darauf filtert. Fachlich ersetzt es keine Projekterfahrung, aber es sortiert deine Begriffe und macht dich im Team sofort anschlussfähig. Wenn du bereits im Test arbeitest, ist der Nutzen kleiner und liegt vor allem beim Wechsel des Arbeitgebers.
Muss ich programmieren können?
Für den manuellen Test nicht, für die Automatisierung ja. Dort schreibst du Code, der anderen Code prüft, und dieser Code muss gelesen, versioniert und gewartet werden. Üblich sind Python oder JavaScript und TypeScript, dazu Git. Wer den Schritt nicht gehen will, bleibt fachlich wertvoll, sollte aber wissen, dass ein Teil der wiederkehrenden Arbeit über die Jahre automatisiert wird.
Läuft das Zertifikat ab?
Nein, ISTQB-Zertifikate haben keine Gültigkeitsdauer und müssen nicht verlängert werden. Das unterscheidet sie von Herstellerzertifikaten wie dem CCNA. Fachlich veraltet der Inhalt trotzdem, deshalb wird der Lehrplan überarbeitet, aktuell liegt das Foundation Level in der Version 4.0 vor.
Macht KI den Testberuf überflüssig?
Sie verschiebt ihn. Vorschläge für Testfälle, erzeugte Testdaten und Hilfe beim Schreiben von Automatisierung nehmen Fleißarbeit ab. Die Entscheidung, welches Risiko geprüft wird, und die Beurteilung eines Ergebnisses bleiben menschliche Arbeit. Dazu entsteht ein neues Feld, nämlich das Prüfen von Systemen mit KI-Anteil, deren Antworten sich nicht bei jedem Durchlauf gleich verhalten.

Passt thematisch dazu

Beim Schritt in die Automatisierung fällt zuerst die Werkzeugentscheidung, und dabei hilft der Vergleich von Playwright und Cypress für einen neuen Testbestand .

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

Testen lernt man an einer Anwendung, nicht an einer Folie

Bei cmt leitest du Testfälle selbst ab, bereitest die ISTQB-Prüfung mit Fragen aus dem Lehrplan vor und schreibst deine erste automatisierte Testreihe mit Playwright oder pytest.