Warum früh
Kurz gesagt: Ein Fehler in einer Anforderung kostet ein Wort, wenn er beim Lesen gefunden wird, und eine Woche Arbeit, wenn er nach dem Start gefunden wird. Statisches Testen (Reviews und statische Analyse) sucht Fehler, ohne das Programm auszuführen. Es findet den Fehler selbst, während dynamisches Testen die Fehlerwirkung sieht. Die beiden ersetzen sich nicht, sie ergänzen sich.
Problem
Ein Wort, fünfmal
Erinnere dich an die Anforderung „kostenlose Lieferung über 50 €“, als der Inhaber „ab 50 € einschließlich“ wollte. Der Fehler ist ein Wort. Verfolgen wir, wie viel er kostet, je nachdem, wann du ihn findest.
- Beim Lesen der Anforderung: Die Analystin fragt „und bei genau 50,00 €?“. Die Korrektur ist ein Wort. Fünf Minuten.
- Im Gespräch über die Story: Das Beispiel „50,00 € → kostenlos“ kommt dazu. Weitere fünf Minuten.
- Beim Testen des fertigen Programms: Der Entwickler korrigiert den Code, der Tester testet noch einmal, das Release verschiebt sich um einen Tag.
- Nach dem Start: Kunden haben 4,90 € bezahlt, die sie nicht schuldeten. Geld wird erstattet, eine E-Mail geht raus, die Korrektur ist dringend, und manche vertrauen dem Shop nicht mehr.
Der Fehler ist derselbe. Die Arbeit, die darauf aufbaut, wächst mit jedem Schritt.
Die Idee
Die Kosten eines Fehlers nach Phase
Je später ein Fehler gefunden wird, desto mehr muss mit ihm korrigiert werden. Die Anforderung ist schon Code geworden, der Code Tests, die Tests ein Bericht, und das Programm nimmt Bestellungen an. Das nennt man die Kosten eines Fehlers nach Phase.
| Wann er gefunden wird | Was neu gemacht werden muss |
|---|---|
| beim Lesen der Anforderung | das Wort im Dokument |
| im Gespräch über die Kriterien | das Wort und ein Beispiel |
| beim Testen des fertigen Programms | der Code, die Tests, ein neues Release |
| nach dem Start | alles davon, dazu das Geld, die Kunden und das Vertrauen |
Deshalb beginnt das Testen früh. Nicht, wenn es ein Programm gibt, sondern wenn es den ersten Satz gibt. Es ist auch eines der sieben Prinzipien: Frühes Testen spart Zeit und Geld.
Genauer, für Neugierige
ISTQB CTFL v4.0.1 sagt im Kapitel über statisches Testen, dass früh gefundene Fehler oft viel billiger zu beheben sind als spät im Lebenszyklus gefundene. Derselbe Gedanke steckt hinter dem Wort Shift-left, dem du später im Kurs begegnest.
Genaue Faktoren werden oft zitiert: „10-mal im Code, 100-mal nach dem Start“. Sei vorsichtig damit. Sie stammen aus Studien von vor Jahrzehnten (die bekannteste wird mit Barry Boehm verbunden), und ihre Zahlen sind umstritten. Zum Beispiel verfolgt Laurent Bossavit in „The Leprechauns of Software Engineering“, woher sie kommen und wie wenige Daten dahinterstehen. Die Richtung ist die Erfahrung jedes Teams. Der genaue Faktor hängt vom Projekt ab.
Die Idee
Statisch und dynamisch
Es gibt zwei Wege, Fehler zu suchen.
- Dynamisches Testen: Du führst das Programm aus und beobachtest, was es tut. Der Tester legt 50,00 € in den Warenkorb und sieht 4,90 €. Das ist eine Fehlerwirkung (failure). Dann muss jemand den Fehler finden, der sie verursacht.
- Statisches Testen: Du prüfst ein Arbeitsergebnis, ohne es auszuführen. Du liest die Anforderung, das Modell, den Code oder die Tests, und du findest den Fehler selbst, direkt.
Statisches Testen hat zwei Formen. Ein Review: Menschen lesen und kommentieren. Statische Analyse: Ein Werkzeug liest den Code oder das Modell und sucht nach bekannten Problemen, zum Beispiel einer Variablen, die nie benutzt wird, oder Code, den das Programm nie erreichen kann.
Manches findet man nur statisch: einen Fehler in einer Anforderung, bevor es Code gibt; zwei Anforderungen, die einander widersprechen; Code, der funktioniert, den aber niemand warten kann. Anderes findet man nur dynamisch: eine langsame Seite bei 500 Kunden oder zwei Systeme, die einander nicht verstehen. Deshalb ergänzen sich die beiden.
Genauer, für Neugierige
CTFL v4.0.1 (Kapitel 3) nennt die Unterschiede: Statisches Testen findet Fehler direkt, während dynamisches Testen Fehlerwirkungen auslöst, von denen aus man den Fehler zurückverfolgt. Statisches Testen lässt sich auch auf Arbeitsergebnisse anwenden, die sich nicht ausführen lassen (Dokumente, Modelle), und kann Eigenschaften finden, die nicht von der Ausführung abhängen, etwa die Wartbarkeit. Dynamisches Testen kann Dinge finden, die sich erst beim Ausführen zeigen, etwa die Leistung.
Statische Analyse läuft meistens automatisch bei jeder Änderung des Codes. Der Compiler, der sagt „diese Variable ist nicht initialisiert“, ist schon so ein Werkzeug.
Probier es aus
Statisch oder dynamisch?
Die Idee
Was geprüft wird
Fast alles, was man lesen und verstehen kann:
- Anforderungen, Stories und Akzeptanzkriterien;
- Modelle: Prozesse, Zustandsautomaten, Entscheidungstabellen;
- Code;
- Testfälle und Szenarien;
- Pläne, Verträge, Benutzerhandbücher.
Eine Anforderung zu prüfen, ist etwas Besonderes. Es ist sowohl Verifizierung (ist sie richtig geschrieben, eindeutig, prüfbar) als auch Validierung (ist das der Bedarf). Liest der Inhaber „über 50 €“ und sagt „nein, ich wollte ab 50 €“, ist das Validierung. Fragt der Tester „und bei genau 50,00 €?“, ist das Verifizierung.
Auch ein Review hat eine Grenze. Es vergleicht das Arbeitsergebnis mit dem, was die Menschen wissen. Kann niemand sagen, was das System tun muss, hat das Review nichts, womit es vergleichen kann. Dann ist die erste Aufgabe das Gespräch, nicht das Lesen.
Probier es aus
Prüfe die Kriterien
Die Kriterien für das Stornieren einer Bestellung, vor Beginn der Arbeit. Markiere die Probleme und wähle die Art jedes einzelnen.
Klicke auf die Wörter, die ein Problem sind; noch einmal, um die Markierung zu entfernen. Mit den Pfeiltasten geht es von Wort zu Wort.
Die Probleme im Text
- „jederzeit“ widersprüchlich: K-2 sagt, dass eine versandte Bestellung nicht storniert werden kann. Beides kann für dieselbe versandte Bestellung nicht stimmen. Der Entwickler baut das eine, der Tester prüft das andere.
- „kann nicht storniert werden“ widersprüchlich: Sie widerspricht K-1. Die Regel des Shops lautet „eine bezahlte Bestellung kann vor dem Versand storniert werden“, also wird K-1 korrigiert: „bis sie versandt ist“.
- „schnell“ nicht prüfbar: In wie vielen Tagen? Ohne Zahl kann kein Test fehlschlagen. Zum Beispiel: „innerhalb von 14 Tagen nach der Stornierung“.
Zwei Minuten Lesen hätten den Fehler aus der Lektion „Akzeptanzkriterien“ verhindert: eine Bestellung zu stornieren, die schon beim Paketdienst ist. Korrigiert: „K-1. Der Kunde kann seine Bestellung stornieren, solange sie nicht versandt ist.“ K-2 bleibt. „K-3. Wird eine bezahlte Bestellung storniert, wird das Geld innerhalb von 14 Tagen erstattet.“
Die Idee
Frühe Rückmeldung
Es gibt einen noch einfacheren Weg, den Fehler „über 50 €“ früh zu finden: dem Inhaber etwas zeigen. Ein Beispiel, einen Prototyp des Warenkorbs, eine Tabelle der Lieferkosten für 49,99, 50,00 und 50,01 €. Er schaut darauf und sagt „das hier ist falsch“.
Häufige Rückmeldung der Interessengruppen schützt vor dem teuersten Fehler: einem Produkt, das richtig gebaut ist, aber nicht das, das gebraucht wurde. Je seltener du fragst, desto mehr Arbeit geht in die falsche Richtung, bevor es jemand merkt.
Deshalb sind Reviews nicht nur für QA. Der Inhaber, das Lager und die Buchhaltung lesen die Anforderungen, die sie betreffen. Sie sehen Dinge, die du nicht sehen kannst.
Genauer, für Neugierige
CTFL v4.0.1 nennt das frühe und häufige Feedback der Interessengruppen (Abschnitt 3.2). Es hilft, dass Anforderungen gleich verstanden werden und Probleme früh sichtbar sind. Ohne es riskiert das Team, ein Produkt zu bauen, das den Bedarf nicht deckt, und das erst bei der Abnahme zu erfahren.
Übung
Was es kostet
1. Der Weg des Fehlers. Bring die Momente, in denen der Fehler „über 50 €“ gefunden werden kann, vom billigsten zum teuersten in die Reihenfolge.
Bring die Stellen, an denen der Fehler gefunden werden kann, vom billigsten zum teuersten in die Reihenfolge.
Nach dem Start: eine Beschwerde eines Kunden, der 4,90 € gezahlt hatIm Code-Review: „> 50“ ist nicht „ab 50 einschließlich“Beim Lesen der Anforderung: „und bei genau 50,00 €?“Im Gespräch über die Kriterien: Beispiel „50,00 € → kostenlos“Beim Testen des fertigen Programms: ein Warenkorb von 50,00 €
Jede Zeile trägt alles aus der vorigen mit sich. In der ersten steckt der Fehler nur im Text. In der letzten steckt er im Code, in den Tests, in den Bestellungen und in den E-Mails der Kunden.
Test