Modul 12 - Testfälle systematisch planen

Was du danach weißt: Wie du vor dem Testen weißt welche Fälle du brauchst — und warum drei Kategorien ausreichen, um nichts Wichtiges zu übersehen.

Was du schon kannst — und was noch fehlt

In Modul 05 hast du gelernt, wie du einen Sachverhalt als Given/When/Then aufschreibst. In Modul 07 hast du gelernt, wie du einen Fehler als Ticket dokumentierst. Das Bindeglied fehlt noch: wie weißt du, welche Fälle du testen sollst, bevor du anfängst?

Ohne Plan testest du, was dir gerade einfällt — und findest manche Fehler, übersiehst aber systematisch andere. Mit drei Kategorien kannst du begründen, warum dein Test vollständig ist.

Drei Kategorien — vollständige Abdeckung

Normalfall

standard case

Der typische, erwartete Ablauf. Hier fängt jeder Test an.

Eintritt am 15. Mai, Vollzeit, Standard-KV

Grenzfall

edge case · boundary

Gültige Extremwerte — selten, aber möglich. Hier verstecken sich viele Fehler.

Eintritt am 1. oder 31. Mai, Februar, Schaltjahr

Fehlerfall

error case

Ungültige Eingabe — was tut das System, wenn etwas fehlt oder falsch ist?

Kein Eintrittsdatum, Datum liegt in der Zukunft

Angewendet: Teilmonatseintritt

Statt zufällig einen Fall zu testen, gehst du die drei Kategorien durch. Für Eintritt in Teilmonat ergibt das diese Testfälle:

Testfall	Kategorie	Erwartet
Eintritt 15. Mai — Standardfall	Normalfall	Brutto aliquot für 17 von 31 Tagen
Eintritt 1. Mai	Grenzfall	Kein Aliquot — voller Monat, kein Abzug
Eintritt 31. Mai	Grenzfall	Aliquot für 1 von 31 Tagen — trotzdem SV-pflichtig
Eintritt 15. Februar (kein Schaltjahr)	Grenzfall	Divisor 28 — kein fixer Wert, abhängig vom Jahr
Eintrittsdatum nicht eingetragen	Fehlerfall	System verhindert den Lauf oder zeigt Fehlermeldung — kein stilles Ergebnis

Jede Zeile in dieser Tabelle wird zu einem Given/When/Then (Modul 05), bevor du testest — und zu einem Bug-Ticket (Modul 07), wenn der Test fehlschlägt. Die drei Kategorien sind der Zwischenschritt, der beides zusammenhält.

In deiner Arbeit bei P&I

Wenn du nach einem Release testen sollst: liste die zu testenden Funktionen auf, geh für jede die drei Kategorien durch, und teste mindestens den Normalfall und alle Grenzfälle die du aus der Personalverrechnung kennst. Du findest dann nicht durch Glück Fehler — sondern durch Methode.

Dein Vorteil dabei: du weißt, welche Grenzfälle existieren. Dass Februar 28 oder 29 Tage hat, dass ein Eintritt am letzten Tag des Monats trotzdem volle SV-Pflicht auslöst — das weiß kein automatisierter Test ohne dein Zutun. Dein Fachwissen ist der Inhalt, die drei Kategorien sind die Form.

Denke mal nach: Nimm eine Funktion aus deinem Alltag bei P&I — zum Beispiel Krankenstand oder Austritt. Welche Grenzfälle würdest du testen? Was wäre ein typischer Fehlerfall, der leicht übersehen wird?