Was ist der Entscheidungstabellentest?
Der Entscheidungstabellentest ist ein regelbasiertes Black-Box-Testverfahren für Logiken, deren Verhalten von einer Kombination mehrerer Bedingungen abhängt: Die Geschäftsregel wird als Entscheidungstabelle aufgeschrieben, und aus jeder Spalte dieser Tabelle entsteht ein Testfall.
Die Entscheidungstabelle selbst ist eine Matrix. Oben stehen die Bedingungen, unten die Aktionen, und jede Spalte ist eine Regel: eine konkrete Bedingungs-Kombination mit den Aktionen, die daraus folgen sollen. Der Reiz dieser Form liegt in ihrer Unerbittlichkeit: Sobald die Regel als Tabelle vorliegt, hat jede denkbare Kombination eine Spalte, und jede Spalte erzwingt eine Antwort. Es gibt keinen Sonderfall mehr, über den einfach niemand nachgedacht hat.
Das Verfahren prüft damit mehr als die Reaktion auf einzelne Bedingungen: Es prüft, ob jede Kombination die jeweils richtige Aktion auslöst. Genau da verstecken sich die Fehler, die stichprobenhaftes Testen übersieht: der Fall, in dem zwei Regeln gleichzeitig greifen sollten und nur eine es tut. Der Entscheidungstabellentest gehört zu den regelbasierten Testentwurfsverfahren.
Wann ist das Verfahren geeignet?
Überall dort, wo Geschäftsregeln mehrere Bedingungen verknüpfen: Tarif- und Rabattlogiken, Versicherungsprüfungen, Genehmigungsregeln, Berechtigungsprüfungen, Validierungen mit mehreren Feldern. In all diesen Fällen lässt sich das gewünschte Verhalten als Tabelle ausdrücken, was den Testentwurf erleichtert und oft auch die Anforderung selbst präzisiert.
Bei einer oder zwei Bedingungen ist das Verfahren meist Overkill; da reichen direkte Testfälle oder eine Grenzwertanalyse. Ab drei Bedingungen wird es interessant, ab vier oder fünf praktisch unverzichtbar, weil dann niemand mehr alle Kombinationen im Kopf behält.
Ein Nebeneffekt zeigt sich schon vor dem ersten Test: Beim Aufstellen der Tabelle kommen Widersprüche und Lücken in den Anforderungen ans Licht, widersprüchliche Regeln, fehlende Kombinationen, Bedingungen, die sich gegenseitig ausschließen. Die Tabelle wirkt als statisches Prüfinstrument für die Spezifikation selbst. Gut gepflegt überlebt sie mehrere Releases als verlässlichste Beschreibung der Regel, idealerweise gemeinsam mit Product Owner und Entwicklung gepflegt, direkt in der Anforderung oder als Anhang zur User Story.
Vorgehen in fünf Schritten
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
- Bedingungen identifizieren. Welche Bedingungen beeinflussen die Entscheidung? Jede wird binär oder als kleine Wertemenge formuliert.
- Aktionen identifizieren. Welche Reaktionen kann das System zeigen?
- Vollständige Tabelle aufstellen. Bei n binären Bedingungen entstehen 2 hoch n Spalten.
- Tabelle reduzieren. Zwei Regeln lassen sich nur dann zusammenfassen, wenn sie dieselben Aktionen auslösen, sich in genau einer Bedingung unterscheiden und dabei alle Werte dieser Bedingung abdecken. Diese Bedingung wird dann mit “egal” markiert. Nicht erfüllbare Regeln vorher entfernen.
- Testfälle ableiten. Pro Regel ein Testfall mit konkreten Werten und erwarteter Aktion; bei hoher Risikostufe auch mehrere pro reduzierter Regel.
Ein kompaktes Beispiel
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
Eine Hausratversicherung entscheidet über Leistungsanträge nach drei Bedingungen: Ist die Police zum Schadenzeitpunkt aktiv? Wurde der Schaden fristgerecht gemeldet? Liegt die Schadenhöhe über der Selbstbeteiligung? Drei binäre Bedingungen, also 2 × 2 × 2 = 8 Kombinationen. Die Reduktion bringt sie auf vier Regeln, denn eine inaktive Police führt immer zur Ablehnung, und bei aktiver Police entscheidet die verpasste Frist unabhängig von der Schadenhöhe:
| Bedingung / Regel | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Police zum Schadenzeitpunkt aktiv | nein | ja | ja | ja |
| Schaden fristgerecht gemeldet | egal | nein | ja | ja |
| Schadenhöhe über Selbstbeteiligung | egal | egal | ja | nein |
| Aktion: Auszahlung anweisen (abzüglich Selbstbeteiligung) | nein | nein | ja | nein |
| Aktion: Ablehnungsschreiben mit Begründung | ja | ja | nein | ja |
Die Kontrolle per Prüfsumme: R1 trägt zwei “egal”-Werte und deckt damit 2 hoch 2 = 4 Kombinationen ab, R2 mit einem “egal” deckt 2 ab, R3 und R4 je eine. Die Summe 4 + 2 + 1 + 1 = 8 entspricht genau den möglichen Kombinationen. Damit ist ein Warnsignal ausgeblieben, mehr nicht. Liegt die Summe zu hoch, überschneiden sich Regeln; liegt sie zu niedrig, fehlen Kombinationen. Stimmt sie, kann sich immer noch eine Lücke gegen eine gleich große Überlappung aufheben. Die Prüfsumme ist ein Rauchmelder, kein Beweis. Den Rest erledigt das inhaltliche Review der Tabelle. Vier Testfälle erreichen hier 100 Prozent Überdeckung.
Angenommen, im Testlauf fällt R2 durch: Ein verspätet gemeldeter Schaden über der Selbstbeteiligung wird ausgezahlt statt abgelehnt. Die Ursache: Die Fristprüfung war nur im Kundenportal umgesetzt, nicht in der Schnittstelle, über die Makler Anträge einreichen. Ein klassischer Kombinationsfehler, den ein Test mit zwei, drei “typischen” Anträgen kaum je gefunden hätte, weil typische Anträge nun einmal fristgerecht kommen.
Überdeckung und Erfolgskriterien
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
Die zentrale Metrik ist die Entscheidungstabellenüberdeckung, auch Spaltenüberdeckung genannt: der Anteil der ausgeführten an den erfüllbaren Spalten. Nicht erfüllbare Kombinationen, die logisch nie eintreten können, fallen aus dem Nenner heraus.
Beim Review der Tabelle, am besten gemeinsam mit der Fachseite, haben sich vier Prüffragen bewährt: Führen überlappende Regeln zur selben Aktion (Konsistenz)? Gibt es Regeln, deren Bedingungs-Kombination nie eintreten kann (Durchführbarkeit)? Fehlt eine erfüllbare Kombination (Vollständigkeit)? Und bilden die Regeln das fachlich gewünschte Verhalten ab (Korrektheit)? Das Prüfsummenverfahren ergänzt das Review rechnerisch, ersetzt es aber nicht: Weicht die Prüfsumme von der Zahl der möglichen Kombinationen ab, gibt es sicher ein Problem. Stimmt sie, ist nur eine von mehreren Fehlerquellen ausgeschlossen.
Stärken und Grenzen
Die Stärke des Verfahrens ist seine Zwangsläufigkeit. Jede Kombination bekommt eine Spalte, jeder Sonderfall eine Antwort; Mehrdeutigkeiten, die im Fließtext einer Anforderung überleben, lösen sich in der Tabelle zwingend auf. Dazu kommt die Verständlichkeit: Eine Entscheidungstabelle ist in wenigen Minuten erklärt, auch der Fachseite.
Die wichtigste Grenze ist das exponentielle Wachstum. Mit jeder zusätzlichen binären Bedingung verdoppelt sich die Tabelle; bei sieben Bedingungen stehen schon 128 Spalten auf dem Papier. Dann helfen Reduktion, Aufteilung in Teil-Tabellen pro Themenbereich oder die Kombination mit dem kombinatorischen Test für die Bedingungs-Permutationen; ab etwa fünf Bedingungen lohnt Werkzeugunterstützung. Eine zweite Falle sind nicht-binäre Bedingungen: Hat eine Bedingung drei oder mehr Werte, wächst die Tabelle entsprechend schneller. Solche Bedingungen werden explizit mit allen Werten modelliert oder in mehrere binäre zerlegt.
Verwandte Verfahren
Der Wertebereichstest prüft die einzelnen Schwellwerte, aus denen die Bedingungen bestehen; die Entscheidungstabelle prüft ihr Zusammenwirken. Bei sehr vielen Parametern mit reduzierten Wertelisten übernimmt der kombinatorische Test. Geht es um Abläufe statt um Regeln, ist der Zustandsübergangstest das passende Verfahren. Einen Überblick über alle elf Verfahren gibt die Seite Testentwurfsverfahren.