Zum Inhalt
wannacode

Fehler und der Fehlerbericht

Kurz gesagt: Ein Fehlerbericht ist ein Brief an jemanden, der den Fehler nicht gesehen hat. Er muss ihn beim ersten Mal wiederholen können: kurze Schritte, das erwartete Ergebnis aus der Regel und das tatsächliche aus dem System. Der Schweregrad sagt, wie viel Schaden der Fehler anrichtet, die Priorität, wie bald er behoben wird; beides ist Ermessen und unterscheidet sich oft.

Problem

„Die Lieferung funktioniert nicht“

Der Tester schreibt in den Fehler-Tracker: „Die Lieferung funktioniert nicht. Dringend!“ Der Entwickler probiert einen Warenkorb von 30 € und sieht 4,90 €. Probiert 70 € und sieht 0,00 €. Alles in Ordnung. Er schließt den Bericht als „nicht reproduzierbar“.

Eine Woche später beschwert sich ein Kunde, dass er bei einer Bestellung von genau 50,00 € Lieferkosten gezahlt hat. Der Tester hat es als Erster gesehen. Aber sein Bericht nannte weder den Betrag noch was er erwartet noch was er bekommen hatte.

Die Idee

Ein Bericht ist ein Brief an jemanden, der nicht dabei war

Ein Fehlerbericht hat eine Aufgabe: Jemand anderes wiederholt den Fehler beim ersten Mal und versteht, warum es ein Fehler ist. Ein guter Bericht hat also:

  • einen Titel, der den Fehler benennt: „Die Lieferung kostet 4,90 € bei einer Bestellung von genau 50,00 €“, nicht „Die Lieferung funktioniert nicht“;
  • Schritte: der kürzeste Weg zum Fehler, mit den genauen Daten. Nicht einen Schritt zu viel;
  • erwartet: was die Regel sagt. Kostenlose Lieferung;
  • tatsächlich: was das System getan hat. 4,90 €;
  • Umgebung: Version, Browser, Gerät, wenn sie eine Rolle spielen;
  • Schweregrad und Priorität (die nächsten Karten);
  • einen Link zur Anforderung und zum Testfall, der ihn gefangen hat.

Eines enthält ein Bericht nicht: wer schuld ist. Der Fehler steckt im Produkt, nicht in der Person.

Genauer, für Neugierige

Der CTFL v4.0.1 nennt in Abschnitt 5.5 den typischen Inhalt eines Berichts: eine eindeutige Kennung, einen Titel mit kurzer Zusammenfassung, Datum, Autor und Organisation, das Testobjekt und die Umgebung, den Kontext (Testfall, Aktivität, Verfahren), eine Beschreibung der Fehlerwirkung, die Reproduktion und Behebung ermöglicht, mit Schritten, Logs und Screenshots, das erwartete und das tatsächliche Ergebnis, Schweregrad, Priorität, Status und Verweise. Der Lehrplan nennt auch seine Ziele: Informationen für die Korrektur, ein Weg, die Qualität des Produkts zu verfolgen, und Ideen zur Verbesserung des Prozesses.

Die Idee

Das Leben eines Fehlers

Ein Bericht endet nicht, wenn er geschrieben ist. Er durchläuft mehrere Zustände:

  1. Neu: Der Tester schreibt ihn.
  2. Offen: In der Triage nimmt das Team ihn als Fehler an und gibt ihm eine Priorität.
  3. In Arbeit: Der Entwickler findet die Ursache und behebt sie.
  4. Behoben: Die Korrektur ist in der Version zum Testen.
  5. Verifiziert: Der Bestätigungstest besteht, und die Regressionstests drum herum auch.
  6. Geschlossen.

Die Umwege sind genauso wichtig. Abgelehnt: kein Fehler, das System tut, was die Regel sagt (dann ist vielleicht die Regel falsch, und das ist eine Frage an den Analysten). Duplikat: Er ist schon gemeldet. Zurückgestellt: Es ist ein Fehler, aber er wird jetzt nicht behoben. Wieder geöffnet: Der Bestätigungstest schlägt wieder fehl.

Genauer, für Neugierige

Die Namen der Zustände unterscheiden sich zwischen Teams und Werkzeugen (Jira, Azure DevOps, GitHub Issues). Der CTFL schreibt keine bestimmten Namen vor: Wichtig ist, dass der Fehlerprozess vereinbart ist und alle wissen, was jeder Zustand bedeutet und wer ihn ändert.

Probier es aus

Ordne den Weg

Ordne die Zustände des Fehlers vom Bericht bis zum Schließen.

  1. Offen: Die Triage nimmt ihn als Fehler an und gibt ihm eine Priorität
  2. In Arbeit: Der Entwickler findet die Ursache und behebt sie
  3. Geschlossen
  4. Behoben: Die Korrektur ist in der Version zum Testen
  5. Neu: Der Tester schreibt den Bericht
  6. Verifiziert: Der Bestätigungstest besteht, und die Regressionstests auch

Die Idee

Schweregrad und Priorität sind nicht dasselbe

Die beiden werden ständig verwechselt:

  • Der Schweregrad ist, wie viel Schaden der Fehler anrichtet: beim Kunden, beim Geld, bei den Daten. Meist schlägt ihn der Tester vor, weil er den Schaden gesehen hat. Skala: kritisch, hoch, mittel, niedrig.
  • Die Priorität ist, wie bald er behoben wird. Das Geschäft oder der Product Owner entscheidet sie, weil sie vom Plan, von den Kunden, von der Werbung abhängt. Skala: hoch, mittel, niedrig.

Oft unterscheiden sie sich. Ein Rechtschreibfehler im Namen des Shops richtet wenig Schaden an, wird aber heute behoben. Ein falscher Jahresbericht richtet viel Schaden an, hat aber 10 Monate bis zum nächsten Lauf.

Beides ist Ermessen, keine Tatsache. Zwei gute Tester können einen anderen Schweregrad vergeben, und das ist normal. Wichtig ist, dass du sagen kannst, warum.

Probier es aus

Schweregrad oder Priorität?

1. Im Namen des Shops auf der Startseite steht ein Rechtschreibfehler.
2. Der Jahresbericht der Buchhaltung gibt eine falsche Summe der Rabatte aus. Er läuft einmal im Jahr, das nächste Mal in 10 Monaten.
3. Niemand kann mit Karte bezahlen.
4. Der Hinweis im Telefonfeld auf der deutschen Seite steht immer noch auf Englisch.

Probier es aus

Der erste Bericht

In den Aufgaben unten stimmt der Shop nicht ganz. Jeder hat einen versteckten Fehler, absichtlich in ein sonst richtiges System eingebaut. Im Modul über Gherkin heißt eine solche Version mit einem Fehler Mutant: Deine Szenarien haben ihn gefangen, wenn sie an ihm fehlgeschlagen sind. Hier ist der Fehler schon gefangen. Du weißt ungefähr, wo er ist. Deine Aufgabe ist der Bericht.

So funktioniert die Aufgabe:

  • Du baust die Schritte aus dem Schrittvokabular der Funktionalität und tippst die Werte;
  • Ausprobieren führt deine Schritte auf dem System mit dem Fehler aus und zeigt, was es liefert;
  • du wählst erwartet (was die Regel sagt) und tatsächlich (was du gesehen hast);
  • du vergibst einen Schweregrad und eine Priorität.

Die Prüfung führt deine Schritte auf dem System mit dem Fehler aus (der Fehler muss sich dort zeigen) und auf dem richtigen (dort darf er sich nicht zeigen). Der Titel wird nur teilweise geprüft: Er darf nicht leer oder „funktioniert nicht“ sein. Schweregrad und Priorität werden mit dem Musterbericht verglichen, den du nach deinem Versuch siehst.

Finde einen Betrag, bei dem sich der Fehler zeigt, und schreibe den Bericht.

Der gefangene Fehler: Kostenlose Lieferung

bei Bestellungen deutlich unter 50 €

Die Regel: Die Lieferung ist ab einer Bestellung von 50 € (einschließlich) kostenlos, sonst kostet sie 4,90 €. Ein leerer Warenkorb kann nicht bestellt werden.

Schritte zum Reproduzieren

  1. Noch keine Schritte. Füge sie aus dem Vokabular unten hinzu.

Die Schritte stammen aus dem Vokabular der Funktionalität, wie in den Szenarien. Die Werte stehen im Schritt selbst: den Betrag wie 50,00.

Erwartet (was laut Regel passieren soll)
Tatsächlich (was im System mit dem Fehler passiert)
Schweregrad (wie viel Schaden der Fehler anrichtet)
Priorität (wie schnell er behoben werden soll)

Die Idee

Wie du die kürzesten Schritte findest

Du hast den Fehler nach 12 Schritten gesehen: hinzufügen, entfernen, die Menge ändern, einen Code eingeben, den Code entfernen. Der Entwickler soll nicht alle durchgehen müssen. Bevor du schreibst, grenze ein:

  • Entferne einen Schritt und probiere es noch einmal. Ist der Fehler noch da? Dann wird der Schritt nicht gebraucht;
  • ändere jeweils einen Wert. Bei 30 € ist der Fehler da, bei 3 € nicht: Er steckt also im Warenkorbwert, und du weißt ungefähr, wo die Grenze liegt;
  • schreibe die genauen Daten auf. Nicht „irgendein Betrag“, sondern 30,00 €. Nicht „ein paar Stück“, sondern 8 und dann 3.

Das ist auch der Unterschied zwischen „bei mir läuft es“ und „beim ersten Mal behoben“.

Übung

Fehlerberichte

1. Die Liefergebühr. Der Fehler steckt im Preis der kostenpflichtigen Lieferung.

Schreibe einen Bericht, nach dem der Fehler beim ersten Mal behoben wird.

Der gefangene Fehler: Kostenlose Lieferung

im Preis der kostenpflichtigen Lieferung

Die Regel: Die Lieferung ist ab einer Bestellung von 50 € (einschließlich) kostenlos, sonst kostet sie 4,90 €. Ein leerer Warenkorb kann nicht bestellt werden.

Schritte zum Reproduzieren

  1. Noch keine Schritte. Füge sie aus dem Vokabular unten hinzu.

Die Schritte stammen aus dem Vokabular der Funktionalität, wie in den Szenarien. Die Werte stehen im Schritt selbst: den Betrag wie 50,00.

Erwartet (was laut Regel passieren soll)
Tatsächlich (was im System mit dem Fehler passiert)
Schweregrad (wie viel Schaden der Fehler anrichtet)
Priorität (wie schnell er behoben werden soll)

2. Das elfte Stück. Der Fehler liegt an der oberen Grenze des Warenkorbs.

Schreibe einen Bericht, nach dem der Fehler beim ersten Mal behoben wird.

Der gefangene Fehler: Höchstens 10 Stück eines Produkts

wenn der Warenkorb die obere Grenze überschreitet

Die Regel: Im Warenkorb können höchstens 10 Stück eines Produkts liegen. Was darüber hinausgeht, wird mit einer Meldung abgelehnt, und der Warenkorb bleibt, wie er ist. Hinzugefügt wird mindestens 1 Stück.

Schritte zum Reproduzieren

  1. Noch keine Schritte. Füge sie aus dem Vokabular unten hinzu.

Die Schritte stammen aus dem Vokabular der Funktionalität, wie in den Szenarien. Die Werte stehen im Schritt selbst: den Betrag wie 50,00.

Erwartet (was laut Regel passieren soll)
Tatsächlich (was im System mit dem Fehler passiert)
Schweregrad (wie viel Schaden der Fehler anrichtet)
Priorität (wie schnell er behoben werden soll)

3. Die Ablehnung, die leert. Der Fehler steckt darin, was nach einer Ablehnung im Warenkorb bleibt.

Schreibe einen Bericht, nach dem der Fehler beim ersten Mal behoben wird.

Der gefangene Fehler: Höchstens 10 Stück eines Produkts

darin, was nach einer Ablehnung im Warenkorb bleibt

Die Regel: Im Warenkorb können höchstens 10 Stück eines Produkts liegen. Was darüber hinausgeht, wird mit einer Meldung abgelehnt, und der Warenkorb bleibt, wie er ist. Hinzugefügt wird mindestens 1 Stück.

Schritte zum Reproduzieren

  1. Noch keine Schritte. Füge sie aus dem Vokabular unten hinzu.

Die Schritte stammen aus dem Vokabular der Funktionalität, wie in den Szenarien. Die Werte stehen im Schritt selbst: den Betrag wie 50,00.

Erwartet (was laut Regel passieren soll)
Tatsächlich (was im System mit dem Fehler passiert)
Schweregrad (wie viel Schaden der Fehler anrichtet)
Priorität (wie schnell er behoben werden soll)

Test

Teste dich

1. Was muss die Person, die den Bericht liest, können?
2. Wer legt die Priorität fest?
3. „Erwartet“ im Bericht kommt aus …
4. Der Entwickler lehnt den Bericht mit „bei mir läuft es“ ab. Was fehlte höchstwahrscheinlich?
5. Warum ist die Grundursache eines Fehlers wichtig, wenn er behoben ist?

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