Zum Inhalt
wannacode

Warum Programme versagen

Kurz gesagt: Ein Mensch macht eine Fehlhandlung, sie hinterlässt einen Fehler in der Anforderung oder im Code, und ein Fehler, der ausgeführt wird, wird zu einem Ausfall, den der Kunde sieht. Testen sucht nach Ausfällen, kann aber nicht beweisen, dass es keine Fehler gibt.

Problem

Wer hat sich geirrt?

Der Shop startet den Gutscheincode „HERBST10“: 10 € Rabatt, einmal pro Kunde. Eine Woche später sieht die Buchhaltung einen Kunden, der ihn in drei Bestellungen genutzt hat. 30 € statt 10 €.

Der Entwickler sagt: „Ich habe es so gebaut, wie es dasteht.“ In der Anforderung steht „einmal pro Bestellung“. Die Analystin sagt: „So hat es mir der Inhaber gesagt.“ Der Inhaber ist sicher, dass er „pro Kunde“ gesagt hat.

Wer hat sich geirrt? Das ist die falsche Frage. Nützlicher ist zu sehen, dass es drei verschiedene Dinge sind, die nacheinander passieren.

Die Idee

Fehlhandlung, Fehler, Ausfall

  • Eine Fehlhandlung (error, mistake) ist eine menschliche Handlung: Jemand versteht, schreibt oder tut etwas falsch. Die Analystin schreibt „pro Bestellung“ auf.
  • Ein Fehler (defect, auch bug oder fault) ist ein Mangel in einem Arbeitsprodukt, den die Fehlhandlung hinterlassen hat. Der Fehler liegt hier in der Anforderung. Dann geht er in den Code über, weil der Entwickler das Geschriebene getreu umsetzt.
  • Ein Ausfall (failure) ist der Moment, in dem das System etwas anderes tut als erwartet, während es läuft. Der Kunde nutzt den Code dreimal.

Die Richtung ist immer diese: Fehlhandlung → Fehler → Ausfall. Der Kunde sieht nur den Ausfall. Das Testen beginnt bei ihm und geht rückwärts.

Nicht jeder Fehler wird zum Ausfall. Wenn niemand den Code ein zweites Mal ausprobiert, bleibt der Fehler unsichtbar bestehen.

Genauer, für Neugierige

So gibt es der Lehrplan ISTQB CTFL v4.0.1 an (Abschnitt 1.2.3, „Fehlhandlungen, Fehler, Ausfälle und Grundursachen“). Ein Ausfall kann auch durch Umgebungsbedingungen entstehen, ohne menschliche Fehlhandlung: Strahlung oder ein elektromagnetisches Feld können Firmware beschädigen. Im Shop ist das selten.

Im Beruf bedeutet das Wort „Bug“ alle drei, und deshalb werden Gespräche unklar. „Im Gutscheincode ist ein Bug“ kann der Ausfall sein, den der Kunde gesehen hat, oder die Codezeile, die ihn verursacht. In diesem Kurs heißt Fehler immer der Mangel im Arbeitsprodukt.

Die Idee

Die Grundursache

Warum hat sich die Analystin geirrt? Weil der Kunde es am Telefon gesagt hat und niemand es aufgeschrieben hat. Es gab auch kein Beispiel: „Maria bestellt heute mit dem Code und morgen wieder. Was passiert?“ Mit so einem Beispiel hätten „einmal pro Kunde“ und „einmal pro Bestellung“ laut ausgesprochen verschiedene Antworten gegeben.

Das ist die Grundursache (root cause): warum die Fehlhandlung überhaupt passiert ist. Die Anforderung und den Code zu korrigieren behebt diesen Fehler. Die Grundursache zu beheben (Anforderungen werden mit Beispielen geschrieben, und der Inhaber bestätigt sie) schützt auch vor den nächsten Fehlern derselben Art.

Das Ziel der Analyse ist nicht, einen Schuldigen zu finden. Das Ziel ist ein Prozess, der die Fehlhandlung kein zweites Mal zulässt.

Probier es aus

Bring die Kette in die Reihenfolge

Ordne von der Ursache bis zu dem, was die Buchhaltung sieht.

  1. Die Anforderung sagt „einmal pro Bestellung“
  2. Ein Kunde nutzt den Code in drei Bestellungen und bekommt drei Rabatte
  3. Der Kunde sagt am Telefon „der Code gilt einmal pro Kunde“, niemand schreibt es auf
  4. Die Analystin schreibt aus dem Gedächtnis „einmal pro Bestellung“

Probier es aus

Fehlhandlung, Fehler oder Ausfall?

1. In der Anforderung zur Rückgabe steht „innerhalb von 14 Tagen“, ohne zu sagen, ab wann.
2. Der Entwickler ist müde und schreibt „weise ab 11 Stück ab“ statt „über 10“.
3. Ein Kunde legt 11 Stück eines Produkts in den Warenkorb und bestellt.
4. Eine Bestellung, die schon versendet ist, lässt sich stornieren, weil im Code die Prüfung des Zustands fehlt. Bisher hat es niemand versucht.

Die Idee

Ein Testfall

Wie fängt man den Ausfall vor dem Kunden ab? Du bringst das System in einen bestimmten Zustand, tust etwas und vergleichst mit dem, was passieren soll. Aufgeschrieben ist das ein Testfall (test case):

Teil Für den Gutscheincode
Vorbedingungen Der Kunde hat „HERBST10“ bereits in einer bezahlten Bestellung genutzt.
Eingabe und Aktionen Eine neue Bestellung über 40 € mit demselben Code.
Erwartetes Ergebnis Der Code wird abgelehnt: „Dieser Code wurde bereits verwendet“. Die Summe bleibt 40 €.

Der wichtigste Teil ist das erwartete Ergebnis, und es kommt aus der Anforderung, nicht aus dem Programm. Wenn du es von dem abschreibst, was das Programm heute tut, bestätigt der Test auch dessen Fehler.

Im Modul über Szenarien wird derselbe Fall als „Angenommen … Wenn … Dann …“ geschrieben. Die Idee ist dieselbe: ein Anfang, eine Aktion, eine Erwartung.

Genauer, für Neugierige

Das ISTQB-Glossar definiert den Testfall als eine Menge von Vorbedingungen, Eingaben, Aktionen (wo zutreffend), erwarteten Ergebnissen und Nachbedingungen, entwickelt auf Grundlage einer Testbedingung. Eine Testbedingung ist das, was du prüfst („der Gutscheincode gilt einmal pro Kunde“), und die Testfälle sind die konkreten Beispiele dafür. Hier ist ein Testfall etwas, das auch ein Mensch ausführen kann. Die Tests im Code aus den anderen Kursen sind dieselbe Idee, für eine Maschine geschrieben.

Die Idee

Ein Test zeigt, er beweist nicht

Der Shop hat 200 Tests für den Warenkorb, und alle bestehen. Heißt das, der Warenkorb hat keine Fehler?

Nein. Es heißt, dass diese 200 Fälle funktionieren. Versuch, alle aufzuzählen: 10 Stück von jedem von 500 Produkten, mit Gutscheincode oder ohne, mit jeder Summe, mit jeder Liefermethode. Es sind mehr Kombinationen, als du in deinem Leben ausführen wirst.

Das ist das erste der sieben Testprinzipien (testing principles): Testen kann zeigen, dass Fehler vorhanden sind, aber nicht, dass keine da sind. Ein bestandener Test senkt die Wahrscheinlichkeit eines versteckten Fehlers. Er macht sie nicht zu null.

Die Idee

Sechs weitere Prinzipien, sechs Geschichten

2. Vollständiges Testen ist unmöglich. Nicht alle Kombinationen des Warenkorbs lassen sich ausführen. Also wählst du die wichtigsten: nach Risiko, nach Grenzen (49,99 €, 50,00 €), nach den Verfahren aus dem Modul „Testentwurfsverfahren“.

3. Frühes Testen spart Zeit und Geld. Die Frage „Und bei genau 50 €?“ in der Besprechung kostet eine Minute. Nach der Freigabe kostet sie eine Korrektur, einen neuen Test, eine neue Version und verärgerte Kunden.

4. Fehler häufen sich an einer Stelle. Die meisten Fehler im Shop liegen in den Gutscheincodes und in der Stornierung von Bestellungen: dort, wo es viele Regeln gibt. Dort testest du mehr.

5. Tests nutzen sich ab. Dieselben Tests, monatelang ausgeführt, fangen nur ab, was sie immer abgefangen haben. Die neuen Fehler sind woanders. Tests werden aktualisiert, und neue kommen dazu.

6. Testen ist kontextabhängig. Ein Shop und Krankenhaussoftware werden nicht gleich getestet. Schon die Website und die mobile App eines Shops haben verschiedene Risiken.

7. Trugschluss der Fehlerfreiheit. Ein System ohne bekannte Fehler kann trotzdem falsch sein: wenn es das Geschriebene tut und das Geschriebene nicht das Nötige ist. Hier hat die Verifizierung bestanden, und die Validierung wurde nie gemacht.

Genauer, für Neugierige

Die Prinzipien stammen aus ISTQB CTFL v4.0.1, Abschnitt 1.3. Auf Englisch: testing shows the presence, not the absence of defects; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out; testing is context dependent; absence-of-defects fallacy.

In älteren Lehrplänen hieß das fünfte „Pestizid-Paradoxon“ (pesticide paradox): wie Insekten, die sich an das Gift gewöhnen. Die Häufung von Fehlern (das vierte) ist ein Beispiel für das Pareto-Prinzip: Ein kleiner Teil der Module enthält einen großen Teil der Fehler.

Übung

Welches Prinzip?

1. Erkenne das Prinzip. Jede Geschichte stammt aus dem Shop. Welches der sieben Prinzipien beschreibt sie?

1. Der Shop testet den Warenkorb mit Chrome auf einem Computer. Die mobile App desselben Shops testet er mit Handys, einem schwachen Netz und einem Abbruch mitten in der Zahlung.
2. Sieben der zehn Fehler des letzten Jahres liegen in den Gutscheincodes. Die Testerin beginnt den neuen Zyklus dort.
3. Ein Satz von 40 Tests für die Lieferung ist seit einem Jahr grün. Im letzten Monat gab es drei Ausfälle bei der Lieferung an ein Büro, das die Tests nicht abdecken.
4. Die neue Zahlungsseite hat keinen einzigen bekannten Fehler. Die Kunden brechen trotzdem ab, weil sie vor der Zahlung eine Registrierung verlangt.
5. Die Frage „Und bei genau 50 €?“ wird in der Besprechung zur Anforderung gestellt. Die Korrektur dauert eine Minute statt einer Woche nach der Freigabe.

Test

Teste dich

1. Welche Richtung stimmt?
2. Alle 200 Tests bestehen. Was kannst du sagen?
3. Was gehört NICHT zu einem Testfall?
4. Ein Fehler in Code, der nie ausgeführt wird, ist…
5. Warum sucht man die Grundursache?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·