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:
- Neu: Der Tester schreibt ihn.
- Offen: In der Triage nimmt das Team ihn als Fehler an und gibt ihm eine Priorität.
- In Arbeit: Der Entwickler findet die Ursache und behebt sie.
- Behoben: Die Korrektur ist in der Version zum Testen.
- Verifiziert: Der Bestätigungstest besteht, und die Regressionstests drum herum auch.
- 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.
Offen: Die Triage nimmt ihn als Fehler an und gibt ihm eine PrioritätIn Arbeit: Der Entwickler findet die Ursache und behebt sieGeschlossenBehoben: Die Korrektur ist in der Version zum TestenNeu: Der Tester schreibt den BerichtVerifiziert: Der Bestätigungstest besteht, und die Regressionstests auch
Die Priorität wird in der Triage vergeben, bevor jemand mit der Arbeit beginnt. „Verifiziert“ heißt Bestätigungstest und Regression, nicht das Wort des Entwicklers.
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?
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.
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
- 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.
Der Musterbericht
- Titel
- Die Lieferung ist bei einer Bestellung von 30,00 € kostenlos
- Schritte zum Reproduzieren
- Angenommen ein Warenkorb von 30,00 €
- Wenn ich bestelle
- Erwartet
- die Lieferung beträgt 4,90 €
- Tatsächlich
- die Lieferung ist kostenlos
- Schweregrad
- hoch. Die Bestellung geht durch, und der Kunde ist zufrieden, aber der Shop verliert 4,90 € bei jeder Bestellung zwischen 5 € und 50 €, und das sind die meisten. Nichts ist stehen geblieben, also ist es nicht kritisch, aber der Schaden ist groß und wächst mit jeder Stunde.
- Priorität
- hoch. Das Geld geht schon heute verloren. Es wird sofort behoben, ohne auf die nächste geplante Freigabe zu warten.
Der Fehler zeigt sich nur zwischen 5 € und 50 €: Unter 5 € berechnen sowohl das richtige System als auch das mit dem Fehler 4,90 €, und ab 50 € berechnet keines etwas. Deshalb reproduziert der Bericht mit 3,00 € nichts. Der gute Bericht hat zwei Schritte, und die Erwartung ist die Zahl aus der Regel, 4,90 €. „Die Bestellung wird angenommen“ stimmt bei beiden Systemen und zeigt den Unterschied nicht.
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.
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
- 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.
Der Musterbericht
- Titel
- Die kostenpflichtige Lieferung kostet 4,99 € statt 4,90 €
- Schritte zum Reproduzieren
- Angenommen ein Warenkorb von 20,00 €
- Wenn ich bestelle
- Erwartet
- die Lieferung beträgt 4,90 €
- Tatsächlich
- die Lieferung beträgt 4,99 €
- Schweregrad
- niedrig. Der Kunde zahlt 9 Cent mehr. Die Bestellung geht durch, und nichts geht verloren: Der Schaden ist klein.
- Priorität
- mittel. Wenig Schaden, aber der Preis entspricht nicht den beworbenen 4,90 €: Kunden beschweren sich, und für den Verbraucherschutz ist das ein falscher Preis. Es wird in der nächsten Freigabe behoben, und manche Teams würden es sofort ausliefern.
Bei 60 € ist die Lieferung in beiden Systemen kostenlos, also zeigt sich der Fehler nicht. Du brauchst einen Betrag unter 50 €. Der Schweregrad ist niedrig, weil es 9 Cent sind. Die Priorität ist Ermessen: Der beworbene Preis ist 4,90 €, und manche Teams würden es sofort beheben. Deshalb wird auch „hoch“ akzeptiert.
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.
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
- 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.
Der Musterbericht
- Titel
- Der Warenkorb nimmt ein 11. Stück eines Produkts an
- Schritte zum Reproduzieren
- Angenommen ein Warenkorb mit 10 Stück des Produkts
- Wenn ich 1 Stück hinzufüge
- Erwartet
- das Hinzufügen wird abgelehnt
- Tatsächlich
- das Hinzufügen wird angenommen
- Schweregrad
- niedrig. Der Kunde nimmt ein Stück mehr als das Limit. Das Limit schützt den Bestand bei einer Aktion, aber ein Stück verbraucht ihn nicht, und Summe und Zahlung stimmen.
- Priorität
- niedrig. Es passiert selten: nur wenn jemand genau 11 will. Es kommt mit den anderen kleinen Korrekturen in den Plan, es sei denn, eine Aktion steht bevor.
Bei 9 Stück und 1 weiterem wird der Warenkorb 10, und das richtige System erlaubt das ebenfalls. Der Fehler liegt bei 11. Das ist das klassische Beispiel für niedrigen Schweregrad und niedrige Priorität: ein echter Fehler, der warten kann, es sei denn, eine Aktion steht bevor.
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.
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
- 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.
Der Musterbericht
- Titel
- Der Warenkorb wird geleert, wenn das Hinzufügen das Limit von 10 Stück überschreitet
- Schritte zum Reproduzieren
- Angenommen ein Warenkorb mit 8 Stück des Produkts
- Wenn ich 3 Stück hinzufüge
- Erwartet
- der Warenkorb enthält 8 Stück des Produkts
- Tatsächlich
- der Warenkorb enthält 0 Stück des Produkts
- Schweregrad
- mittel. Die Ablehnung ist richtig, aber der Kunde verliert die Stücke, die schon im Warenkorb waren, und muss sie neu suchen. Es geht kein Geld verloren, und Bestellen ist weiter möglich, also ist es nicht hoch.
- Priorität
- hoch. Es trifft genau die Kunden, die viel kaufen, und genau bei einer Aktion, wenn das Limit am häufigsten erreicht wird. Viele geben lieber auf, als den Warenkorb neu zu füllen.
Die Ablehnung ist in beiden Systemen richtig, also zeigt „das Hinzufügen wird abgelehnt“ den Unterschied nicht. Der Unterschied liegt in den Stücken, die bleiben: 8 gegen 0. „Angenommen ein leerer Warenkorb“ vor „ein Warenkorb mit 8 Stück des Produkts“ ist ein überflüssiger Schritt: Der zweite überschreibt den ersten. Die Priorität ist hoch oder mittel, weil es die Kunden trifft, die am meisten kaufen.
Test
Teste dich
Verwandte Lektionen
Abschnitt „Verwandte Lektionen“- Baut auf: Warum Programme versagen · Teststufen · Testarten · Der Plan und risikobasiertes Testen
- Geht weiter in: Tests in der CI · Gutscheincodes: von der Anfrage bis zur Freigabe
- Aufgaben zum Thema: Stufen, Arten und Prozess