Jetzt kommt der neue Baustein des Moduls, der letzte im Bauplan der Stufe: Ein Testfall ist ein Beispiel-Input mit vorab festgelegtem erwartetem Ergebnis. Testfälle professionalisieren die Prüfung aus K3 zum wiederholbaren Test; sie sind die Abnahmekriterien aus K4 in ausführbarer Form.
Eine gute Testsammlung deckt vier Typen ab: Normalfall (typischer Input, muss sitzen), Grenzfall (gerade noch oder gerade nicht mehr im Rahmen, etwa ein Zahlungsziel exakt an der Grenze der Checkliste), Fehlerfall (Input mit einem Mangel, der erkannt werden muss, etwa eine fehlende Klausel) und Leerfall (die Information ist nicht vorhanden; erwartet wird „nicht im Material“, nicht eine erfundene Angabe, die Lückenregel aus K6).
Warum das erwartete Ergebnis vorab festgelegt wird: Wer das Soll erst nach der Ausgabe formuliert, biegt es unbewusst zur Ausgabe hin, ein Bestätigungsfehler, verwandt mit dem Automation Bias aus K3. Vorab festgelegt ist der Test unbestechlich. Dazu der Regressionsgedanke in Alltagssprache: Eine Prompt-Änderung kann an anderer Stelle etwas kaputtmachen. Deshalb laufen nach jeder Änderung alle Testfälle, nicht nur der neue; bei vier bis sechs Fällen ist das eine Sache von Minuten. Testfälle stammen aus echten anonymisierten Fällen (K2 beachten), aus bekannten Problemfällen der Vergangenheit und aus gezielt konstruierten Grenzfällen. Die KI kann beim Konstruieren helfen; die Erwartungswerte legt der Mensch fest, sonst prüft sich das System selbst.
Was ist unklar geblieben? Halten Sie es hier fest. Ihre Fragen erscheinen gesammelt auf der Modul- und Startseite und auf Ihrer Ergebnisseite.
