KI-gestütztes Testdesign bezeichnet den Einsatz von Sprachmodellen wie Copilot oder ChatGPT, um Äquivalenzklassen, Grenzwerte und Testfälle systematisch zu generieren. Die Systeme liefern brauchbare Ergebnisse in Minuten, machen aber Fehler. Wer die Ergebnisse bewerten will, muss die klassischen Testdesign-Methoden selbst beherrschen.
Das Wichtigste in Kürze
- Testdesignmethoden wie Äquivalenzklassen und Grenzwertanalyse werden in der Praxis kaum angewendet, obwohl fast alle Tester sie im Zertifikatslehrgang gelernt haben.
- KI-Systeme liefern Testdesign-Ergebnisse in 30 bis 40 Sekunden, die mit Nachprompting in zwei bis drei Minuten ein Qualitätsniveau erreichen, das Michael Fischlein im Kundeneinsatz selten gesehen hat.
- Wer KI-generierte Testergebnisse bewerten will, braucht selbst Methodenwissen, sonst fehlt die Fähigkeit, Fehler und Lücken im Output zu erkennen.
- Grenzwertanalyse ist die Testdesignmethode mit dem breitesten Nutzwert, weil Grenzwertfehler systematisch auftreten und schon eine ungenaue Formulierung wie “zwischen” zu falschen Testableitungen führt.
- Bei zigtausenden Testfällen ließ sich durch Äquivalenzklassenanalyse mehr als die Hälfte streichen, weil Werte aus derselben Klasse redundant sind, während andere Bereiche vollständig ungetestet blieben.
Testdesign aus dem Bauch ist die Regel, nicht die Ausnahme
Viele erfahrene Tester arbeiten ohne formale Testdesign-Methoden, obwohl sie diese gelernt haben. Testdaten, Requirements und Testfälle entstehen aus Erfahrung und Bauchgefühl, nicht aus Äquivalenzklassen oder Grenzwertanalysen.
Das zeigt sich schon im Foundation-Level-Training. Selbst Leute, die seit zehn oder zwanzig Jahren testen und jetzt erst ihr Zertifikat machen, lernen dort Grundlegendes neu. Das Konzept der Äquivalenzklasse haben sie vielleicht intuitiv verstanden, den Namen kennen sie nicht. An Grenzwerte erinnern sie sich vage. Die größeren Testdesign-Methoden, die danach kommen, sind weitgehend unbekannt.
Das ist nicht zwingend ein Problem. Wer mit der Qualität seiner Auslieferungen zufrieden ist und rechtzeitig liefert, macht vieles richtig. Möglich macht das oft eine Person im Team mit einem ausgeprägten Gespür für die Software, einer Art realer Intelligenz, die Fehler findet, ohne formale Technik zu brauchen.
Warum Testdesign-Methoden den Weg in die Praxis nicht finden
Der Hauptgrund ist fehlende Übung. Im Foundation-Level-Lehrgang von vier Tagen entfällt nur etwa ein halber bis ganzer Tag auf das Üben von Testdesign-Techniken. Das reicht nicht, um sie zu verinnerlichen.
Reale Projekte sind komplexer als die Standardbeispiele aus der Schulung. Kaffeemaschine, Colaautomat oder Bankautomat lassen sich überschauen. Eine Entscheidungstabelle mit fünf Bedingungen ergibt 2 hoch 5 Zeilen, das ist handhabbar. Bei zwanzig Bedingungen wird daraus eine riesige Tabelle, vor der viele zurückschrecken.
Dann steht das weiße Blatt Papier. Und die Angst vor dem weißen Blatt kennen wir alle.
Michael Fischlein
Die agile Welt verschärft das Problem, wenn sie falsch verstanden wird. Aus “wir dokumentieren weniger” wird “wir schreiben gar nichts mehr auf”. Tester glauben, schnell sein zu müssen, und nehmen sich keine Zeit für Testdesign. Den Invest, eine Methode erst mühsam zu üben, scheuen viele unter Zeitdruck.
Auch organisatorisch fehlt oft der Auftrag. Testmanager mit Advanced-Level-Zertifikat haben das Papier, aber nicht zwingend das Wissen, um Testdesign im Team einzufordern und vorzuleben.
Exploratives Testen ersetzt Methoden nicht, es braucht sie
Der häufigste Ausweg ist exploratives Testen: einfach nebenher prüfen, ohne formales Design. Doch gutes exploratives Testen setzt voraus, dass du Testdesign-Methoden beherrschst.
Wer explorativ testet, sollte Äquivalenzklassen, Grenzwerte und Entscheidungstabellen implizit anwenden. Genau dieses Wissen hilft beim Streifen durch die Software: welche Preiskategorie, welche Wertebereiche, welche Kombinationen relevant sind. Die Methoden verschwinden nicht, sie wirken im Hintergrund.
Die einfachen Methoden bringen den größten Hebel
Grenzwerte und Äquivalenzklassen sind die zwei Techniken, die fast immer Nutzen bringen. Sie sind simpel und decken einen Großteil der typischen Fehler ab.
Grenzwerte gehen in der Praxis regelmäßig schief, weil Anforderungen textuell formuliert sind. Ein Satz wie “das kürzeste Brett liegt zwischen einem Meter und fünf Meter” ist mehrdeutig. Heißt “zwischen”, dass die Grenzen ausgeschlossen sind, also 1,01 Meter und 4,99 Meter? Das ist offensichtlich nicht gemeint, aber genau hier entstehen Fehler.
Äquivalenzklassen reduzieren die Menge der Testfälle drastisch. Bei einem Kunden mit zigtausenden Testfällen ließ sich nach Analyse mehr als die Hälfte streichen, weil es aus Sicht der Äquivalenzklassen Duplikate waren: andere Werte, dieselbe Klasse. Gleichzeitig waren ganze Wertebereiche überhaupt nicht abgedeckt.
Wie schlecht das Grundverständnis verbreitet ist, zeigt eine simple Übungsfrage aus Einstellungsgesprächen. Wer ein geschlossenes Intervall von 9 bis 99 testen soll, sollte einen Wert darunter, einen darin und einen darüber wählen. Stattdessen schrieben manche Kandidaten am Flipchart eins, zwei, drei, vier bis hin zu 100 herunter, ohne zu merken, wie sinnlos das ist.
Auch zustandsbasiertes Testen taugt für den Alltag, wenn das System Zustände hat. Ein Ticketing-System lässt sich gut visualisieren und verstehen. Wichtig ist: keine Rocket Science, sondern einfache Methoden, die du hands-on anwenden kannst, auch unter agilem Zeitdruck.
KI schließt die Methodenlücke, aber nur die Hälfte davon
Große Sprachmodelle liefern brauchbare Testdesigns in Sekunden, obwohl sie nicht aufs Testen trainiert sind. Systeme wie ChatGPT oder Copilot werten Sprache statistisch aus und erzeugen Testfälle, Akzeptanzkriterien, Grenzwerte und Äquivalenzklassen auf Anfrage.
Die Ergebnisse sind nicht fehlerlos. Halluzinationen und Unsinn sind dabei. Grob geschätzt sind die Resultate zu etwa 80 Prozent richtig. Lässt du dieselbe Aufgabe von Fachleuten lösen, liegt das Ergebnis ähnlich bei 80 bis 90 Prozent, dauert aber ein bis zwei Tage. Die KI braucht 30 bis 40 Sekunden, mit etwas Prompt-Optimierung steht in zwei, drei Minuten ein Konzept.
Damit löst KI die Lücke zwischen “Methode gelernt” und “Methode nie angewendet” pragmatisch auf. Doch es bleibt eine zweite, schwerere Lücke: jemand muss das Ergebnis bewerten. Wer die Methoden nicht beherrscht, erkennt die Fehler im KI-Output nicht.
Hier entsteht die eigentliche Ausbildungsaufgabe. Ein erfahrener Trainer sieht den Fehler im komplexen Testdesign sofort. Der Junior-Consultant direkt nach dem Foundation-Level sieht ihn nicht. Diese Bewertungsfähigkeit aufzubauen, ist die kommende Herausforderung.
So steigst du praktisch in KI-gestütztes Testdesign ein
Rede mit den Systemen wie mit einer Person. Es sind Chat-Systeme, ein “bitte” im Prompt schadet nicht. Formuliere klar, was du willst, etwa: schreib mir bitte für diesen Zustand die Äquivalenzklassen heraus.
Ein gangbarer Ablauf beginnt beim Fachkontext und arbeitet sich zur Methode vor:
- Kontext setzen: “Ich bin ein Versicherungsunternehmen und möchte Neukunden anlegen. Welche Variablen und Felder habe ich, wie sind sie attributiert?”
- Variablen verfeinern: mehr Felder, weniger Felder, anpassen, bis die Liste passt.
- Methode anwenden: “Bau daraus die Äquivalenzklassen.”
- Nachschärfen: einzelne Bereiche vertiefen, fehlende Punkte ergänzen lassen.
Das funktioniert auch zu zweit, indem du die KI als dritte Person an den Tisch holst und die Ergebnisse gemeinsam reizt. In Schulungen wird der Fehler im Output zum Lernmoment: Wer erkennt, dass eine KI-Antwort falsch ist, hat die Methode verstanden.
Beim Befüllen gilt eine Grenze. Kundendaten und sensible Informationen gehören nicht ungeprüft in ein Chat-System. Ein Requirement zu einem gängigen Shop-System ohne Namen darin lässt sich dagegen per Copy-Paste nutzen, um Äquivalenzklassen zu erzeugen und erste Lücken zu sehen.
Bemerkenswert ist, woher die Systeme ihr Domänenwissen ziehen. Bei einer Anforderung aus dem Automobilbereich, rund um Rückfahr- und Absicherungssysteme, lieferte Copilot brauchbare Anforderungen samt Quellenlinks. Die Quellen waren die öffentlich verbreiteten Seiten des Herstellers selbst. Eine Woche geplanter Arbeit war damit fast erledigt, abzüglich der Details, die noch fehlten.
Spielen ist die schnellste Lernmethode
Der beste Einstieg ist Ausprobieren, nicht Nachlesen. Über das Spielen lernst du, was Prompt Engineering praktisch bedeutet und wie ein System auf Rollen, Facetten und Formulierungen reagiert.
Der Effekt einer Formulierung wird erst beim Tun greifbar. Wenn du das System bittest, in einer bestimmten Rolle zu agieren oder eine zusätzliche Facette einzubringen, ändert sich die Antwort. Manchmal ergibt das Unsinn, manchmal genau den Treffer, den du brauchst. Dieses Gefühl baust du nur durch eigenes Reizen auf.
Dasselbe Prinzip lässt sich auf Facharbeit übertragen. Wer mit der KI eine Geschichte oder ein Szenario aufbaut, lernt dieselben Mechaniken, die später beim Schreiben von Testfällen und Anforderungen tragen.
Know-how bleibt der Engpass, auch wenn die Basisarbeit verschwindet
Die einfachen, repetitiven Testdesign-Arbeiten werden KI-Systeme übernehmen. Was bleibt, ist die Notwendigkeit, ein Problem richtig zu formulieren und das Ergebnis mit gesundem Menschenverstand zu prüfen.
Damit verschiebt sich das Gewicht zurück zum Requirements Engineering. Du musst dem System klar machen, was du willst, und dann mit Fachwissen über das Ergebnis schauen. Beides setzt aufgebautes Know-how voraus.
Ein Vergleich macht die offene Frage deutlich. Heute weiß kaum jemand, wie ein Compiler funktioniert, trotzdem verlassen sich alle darauf, dass er das Richtige tut. Denkbar, dass KI-gestütztes Testen denselben Weg geht. Die ungelöste Frage ist, wie Tester künftig das Know-how aufbauen, um die Ergebnisse überhaupt noch bewerten zu können.
Häufig gestellte Fragen
Warum wenden erfahrene Tester Testdesign-Methoden im Alltag so selten an?
Der Hauptgrund ist fehlende Übung. Im viertägigen Foundation-Level-Lehrgang entfällt nur ein halber bis ganzer Tag auf das Üben der Techniken, das reicht nicht zum Verinnerlichen. Dazu kommt, dass reale Projekte komplexer sind als Kaffeemaschine oder Bankautomat: Eine Entscheidungstabelle mit fünf Bedingungen ist handhabbar, bei zwanzig Bedingungen schrecken viele zurück. Oft fehlt auch der organisatorische Auftrag, Testdesign einzufordern.
Ist es ein Problem, wenn ein Team Testfälle aus Erfahrung und Bauchgefühl ableitet?
Nicht zwingend. Wer mit der Qualität seiner Auslieferungen zufrieden ist und rechtzeitig liefert, macht vieles richtig. Möglich macht das häufig eine Person im Team mit ausgeprägtem Gespür für die Software, die Fehler ohne formale Technik findet. Der Verzicht wird erst dann teuer, wenn niemand mehr beurteilen kann, welche Wertebereiche gar nicht abgedeckt sind.
Kann exploratives Testen formale Testdesign-Methoden ersetzen?
Nein. Gutes exploratives Testen setzt voraus, dass die Methoden beherrscht werden. Wer durch die Software streift, wendet Äquivalenzklassen, Grenzwerte und Entscheidungstabellen implizit an: welche Preiskategorie, welche Wertebereiche, welche Kombinationen relevant sind. Die Methoden verschwinden nicht, sie wirken im Hintergrund. Exploratives Testen ist damit kein Ausweg aus fehlendem Methodenwissen.
Warum gehen Grenzwerte in der Praxis so oft schief?
Weil Anforderungen textuell formuliert sind und Sprache mehrdeutig ist. Ein Satz wie “das kürzeste Brett liegt zwischen einem Meter und fünf Meter” lässt offen, ob die Grenzen eingeschlossen sind oder erst 1,01 Meter und 4,99 Meter gemeint sind. Gemeint ist meist das Gegenteil dessen, was dort steht, und genau an dieser Stelle entstehen falsche Testableitungen.
Wie viel Testaufwand lässt sich mit Äquivalenzklassen einsparen?
Bei einem Kunden mit zigtausenden Testfällen ließ sich nach der Analyse mehr als die Hälfte streichen: andere Werte, dieselbe Klasse, also Duplikate ohne zusätzlichen Erkenntnisgewinn. Gleichzeitig zeigte die Analyse, dass ganze Wertebereiche überhaupt nicht abgedeckt waren. Die Methode reduziert also nicht nur die Menge, sie deckt auch blinde Flecken auf.
Wie zuverlässig sind Testfälle, die ein Sprachmodell erzeugt?
Grob geschätzt sind rund 80 Prozent der Ergebnisse richtig, Halluzinationen und Unsinn sind dabei. Fachleute kommen bei derselben Aufgabe auf 80 bis 90 Prozent, brauchen dafür aber ein bis zwei Tage. Das Sprachmodell liefert in 30 bis 40 Sekunden, mit Nachprompting steht in zwei bis drei Minuten ein Konzept. Die Bewertung des Outputs bleibt Aufgabe des Menschen.
Darf man Anforderungen aus Kundenprojekten in ein Chat-System kopieren?
Kundendaten und sensible Informationen gehören nicht ungeprüft in ein Chat-System. Ein Requirement zu einem gängigen Shop-System, in dem keine Namen stehen, lässt sich dagegen per Copy-Paste nutzen, um Äquivalenzklassen erzeugen zu lassen und erste Lücken zu sehen. Die Grenze verläuft also nicht beim Werkzeug, sondern beim Inhalt der eingegebenen Unterlagen.
Was müssen Tester können, wenn KI die einfache Testdesign-Arbeit übernimmt?
Zwei Dinge: ein Problem präzise formulieren und das Ergebnis fachlich prüfen. Beides setzt aufgebautes Know-how voraus, das Gewicht verschiebt sich zurück Richtung Requirements Engineering. Ein erfahrener Trainer sieht den Fehler in einem komplexen Testdesign sofort, ein Junior direkt nach dem Foundation Level nicht. Wie diese Bewertungsfähigkeit künftig entsteht, ist die offene Frage.
