Wenn eine Tabelle klarer ist
Kurz gesagt: Text ist gut für eine Regel, aber schlecht für viele Fälle. Ein Prozess zeigt, wer was in welcher Reihenfolge tut, ein Anwendungsfall zeigt das Ziel und was schiefgehen kann, ein Zustandsautomat zeigt das Leben der Bestellung, und eine Entscheidungstabelle zeigt jede Kombination.
Problem
Drei Sätze, zwei Antworten
Der Inhaber schreibt die Rabattregel auf:
Der Gutscheincode gibt 10 % Rabatt. Der Code gilt nicht für reduzierte Produkte. Stammkunden bekommen immer 5 % Rabatt. Rabatte werden nicht addiert.
Der Entwickler und der Tester lesen sie. Ein Stammkunde mit gültigem Code kauft ein Produkt, das nicht reduziert ist. Der Entwickler rechnet 10 %. Der Tester rechnet 15 %, wegen „immer“. Jeder Satz ist für sich klar. Die Kombination nicht.
Drei Bedingungen mit je zwei Antworten ergeben acht Fälle. Der Text beschreibt sie in Stücken. Eine Tabelle zeigt alle.
Die Idee
Wenn ein Bild klarer ist
Text ist gut für eine Regel. Gibt es eine Reihenfolge von Schritten, viele Beteiligte, viele Zustände oder viele Kombinationen, sagt ein Modell mehr:
| Die Frage | Das Modell | Im Shop |
|---|---|---|
| Wer tut was, und in welcher Reihenfolge? | Geschäftsprozess | die Bestellung vom Warenkorb bis zum Paketdienst |
| Wie erreicht ein Mensch ein Ziel, und was kann schiefgehen? | Anwendungsfall | „Eine Bestellung aufgeben“ |
| Wie sieht das Leben einer Sache aus? | Zustandsautomat | neu → bezahlt → versandt → zugestellt |
| Was passiert bei jeder Kombination von Bedingungen? | Entscheidungstabelle | Gutscheincode, reduzierter Preis und Stammkundenstatus |
Ein Modell ersetzt die Anforderungen nicht. Es ist eine Anforderung in einer anderen Form und lässt sich deshalb wie jede andere prüfen und testen.
Die Idee
Der Geschäftsprozess
Ein Geschäftsprozess zeigt die Schritte einer Arbeit, der Reihe nach, nach Beteiligten. Die Standardnotation ist BPMN. Vier Symbole reichen hier: ein Ereignis (ein Kreis: Etwas geschieht, etwa ein Anfang oder ein Ende), eine Aktivität (ein Rechteck: Jemand tut etwas), ein Gateway (eine Raute: eine Frage mit mehreren Ausgängen) und Bahnen (Streifen: eine pro Beteiligtem).
Der Bestellprozess als Tabelle:
| # | Bahn | Symbol | Schritt |
|---|---|---|---|
| 1 | Kunde | Ereignis (Start) | Der Kunde drückt „Bestellen“. |
| 2 | Shop | Aktivität | Legt eine Bestellung im Zustand „neu“ an. |
| 3 | Kunde | Aktivität | Bezahlt mit Karte. |
| 4 | Shop | Gateway | Ging die Zahlung durch? Nein → Ende „Die Bestellung wartet auf die Zahlung“. Ja → 5. |
| 5 | Shop | Aktivität | Markiert die Bestellung als „bezahlt“. Das Lager druckt das Etikett. |
| 6 | Lager | Aktivität | Packt das Paket und übergibt es dem Paketdienst. Die Bestellung ist „versandt“. |
| 7 | Paketdienst | Aktivität | Stellt das Paket zu. Die Bestellung ist „zugestellt“. |
| 8 | Kunde | Ereignis (Ende) | Der Kunde hat das Paket. |
Die Tabelle ist ärmer als die Zeichnung, sagt aber dasselbe. Am wertvollsten ist Schritt 5: Dort geht die Arbeit vom Shop ans Lager über, und dort ging die neue Adresse verloren.
Genauer, für Neugierige
BPMN (Business Process Model and Notation) ist ein Standard der OMG, Version 2.0. Er hat viel mehr Symbole: Nachrichten zwischen Beteiligten, Zeitgeber, Teilprozesse, Ausnahmen. Im BABOK ist Process Modelling eine eigene Technik. Für Analystin und Tester reicht das Lesen: die Bahnen, die Gateways und die Stellen sehen, an denen die Arbeit von einem zum anderen übergeht.
Probier es aus
Lies den Prozess
Die Idee
Der Anwendungsfall
Ein Anwendungsfall (use case) beschreibt, wie ein Akteur (eine Rolle außerhalb des Systems) mit dem System ein Ziel erreicht. Er hat einen Hauptablauf, in dem alles gut geht, und Alternativabläufe für alles, was schiefgehen kann.
Anwendungsfall: Eine Bestellung aufgeben. Akteur: der Kunde. Vorbedingung: Der Kunde ist angemeldet.
Hauptablauf:
- Der Kunde öffnet den Warenkorb.
- Das System zeigt die Produkte, die Summe und die Lieferung: 0,00 € ab 50 € einschließlich, sonst 4,90 €.
- Der Kunde wählt eine Adresse.
- Der Kunde drückt „Bestellen“.
- Das System legt die Bestellung als „neu“ an und zeigt die Zahlung.
- Der Kunde bezahlt. Das System markiert die Bestellung als „bezahlt“ und schickt eine Bestätigung.
Alternativabläufe:
- 2a. Der Warenkorb ist leer: Das System erlaubt keine Bestellung und sagt, warum.
- 2b. Ein Produkt hat mehr als 10 Stück: Das System nennt das Maximum und macht nicht weiter.
- 4a. Der Kunde hat einen Gutscheincode eingegeben, den er schon verwendet hat: Das System lehnt den Code ab, die Summe bleibt ohne Rabatt, und der Kunde macht bei Schritt 4 weiter.
- 6a. Die Zahlung wird abgelehnt: Die Bestellung bleibt „neu“, und der Kunde kann es noch einmal versuchen.
Den Hauptablauf schreibt jeder auf. Der Wert liegt in den alternativen. Jeder von ihnen ist eine Regel, die der Entwickler bauen und der Tester prüfen muss.
Genauer, für Neugierige
Das Format hier ist nah an dem von Alistair Cockburn in „Writing Effective Use Cases“: ein Hauptszenario mit Erfolg und Erweiterungen, nach Schritten nummeriert. UML kennt auch ein Anwendungsfalldiagramm: ein Strichmännchen für den Akteur und ein Oval für den Anwendungsfall. Es zeigt, welche Anwendungsfälle es gibt, aber nicht, was in ihnen passiert. Der Text oben sagt mehr.
Probier es aus
Lies den Anwendungsfall
Die Idee
Der Zustandsautomat
Eine Bestellung hat ein Leben: Sie ist neu, dann bezahlt, dann versandt, dann zugestellt. Jede solche Lage ist ein Zustand, und der Wechsel von einem zum anderen, bei einem Ereignis, ist ein Übergang. Zusammen sind sie ein Zustandsautomat (state machine).
Als Tabelle sieht der Automat der Bestellung so aus:
| Von | Ereignis und Bedingung | Nach |
|---|---|---|
| Neu | der Kunde bezahlt | Bezahlt |
| Neu | der Kunde storniert | Storniert |
| Bezahlt | das Lager übergibt das Paket dem Paketdienst | Versandt |
| Versandt | der Paketdienst stellt zu | Zugestellt |
| Zugestellt | der Kunde beantragt eine Rückgabe, innerhalb von 14 Tagen nach Erhalt | Zurückgegeben |
Die Tabelle zeigt auch, was nicht erlaubt ist. Jedes Paar „von → nach“, das fehlt, ist verboten. Eine versandte Bestellung wird nicht storniert. Eine zugestellte wird nicht neu.
Das ist ihre Stärke. Im Text klingt „Stornierung ist vor dem Versand erlaubt“ klar. In der Tabelle siehst du sofort, ob jeder Fall „vor dem Versand“ eine eigene Zeile hat.
Übung
Welche Zeile fehlt?
1. Der fehlende Übergang. Vergleiche die Tabelle der Übergänge mit den Regeln des Shops.
Die Idee
Die Entscheidungstabelle
Eine Entscheidungstabelle hat eine Zeile für jede Bedingung und jede Aktion und eine Spalte für jede Kombination. Die Rabattregel vom Anfang, nachdem der Inhaber gesagt hat, dass bei zwei geltenden Rabatten der größere gewinnt:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| Der Code ist gültig | ja | ja | ja | ja | nein | nein | nein | nein |
| Das Produkt ist reduziert | ja | ja | nein | nein | ja | ja | nein | nein |
| Der Kunde ist Stammkunde | ja | nein | ja | nein | ja | nein | ja | nein |
| Rabatt | ? | 0 % | ? | 10 % | 5 % | ? | 5 % | 0 % |
Die Tabelle tut zwei Dinge. Erstens ist sie eine Anforderung, die sich nur auf eine Weise lesen lässt: Jeder Fall hat genau eine Antwort. Zweitens zeigt sie die Lücken im Text. Spalte 3 ist genau die Stelle, an der Entwickler und Tester uneins waren. Die Frage an den Inhaber („10 oder 15 %?“) kommt aus der leeren Zelle, nicht aus einer Eingebung.
Genauer, für Neugierige
Entscheidungstabellen sind auch ein Testentwurfsverfahren (ISTQB CTFL, Black-Box-Verfahren). Dort ist jede Spalte ein Testfall, und Spalten mit demselben Ergebnis werden mit „–“ (egal) zusammengefasst: Zum Beispiel sind die Spalten 5 und 7 „kein Code, Stammkunde → 5 %“, ob reduziert oder nicht. Das Modul „Testentwurfsverfahren“ setzt hier an. In einer Anforderung bleibt die Tabelle vollständig, damit kein Fall übrig bleibt, über den niemand nachgedacht hat.
Übung
Modelle als Anforderungen
1. Fülle die Tabelle aus. Die drei leeren Zellen der Rabatttabelle, und wie viele Spalten es gibt.
Test