Wenn wir als Software-Tester:innen Software testen, dann machen wir dies immer mit dem Ziel, möglichst viele Fehler zu finden, die den Wert der Software mindern.
Dabei hilft es, uns immer wieder daran zu erinnern, dass „jede“ Software Fehler hat. Manche Fehler sind bekannt, andere wurden noch nicht entdeckt.
Aber der Grundsatz „jede Software hat Fehler” ist für uns als Software-Tester:in eigentlich der wichtigste Grundsatz für unsere tägliche Arbeit.
Werde jetzt in 6-12 Monaten Software-Tester!
Was ist ein Bug?
Was ist ein Bug?Als Bug oder Softwarefehler bezeichnet man gemeinhin eine Funktion in einer Software, die nicht so funktioniert, wie sie soll.
Eine andere Definition, aus der „Context Driven School” lautet: Ein Fehler mindert den Wert einer Software – für eine Person, für die diese Software oder diese Funktion wichtig ist.
Anhand einer guten Fehlerbeschreibung kann das beobachtete Fehlverhalten der Software verstanden und die Priorität der Fehlerbehebung bestimmt werden. Daher ist eine gute Fehlerbeschreibung wie eine gute Visitenkarte für jede:n Tester:in.
Als Adressaten der Fehlerbeschreibung müssen wir verschiedene Rollen berücksichtigen.
- Die Entwickler:in, welche die Korrektur umsetzen soll, möchte im Detail verstehen, was als falsch beurteilt wird und wie der Zustand hergestellt werden kann, in dem der Fehler auftritt.
- Die Projektleiter:in oder die Product Owner:in muss verstehen, wie kritisch der Fehler für den Betrieb der Software ist und welche Folgeprobleme er verursacht. Außerdem setzt sie den Fehler noch in den Kontext des Projekts und der anderen Aktivitäten, die noch umzusetzen sind.
Für alle, die den Fehler bearbeiten, ist es wichtig, zu wissen, in welcher Version der Software der Fehler beobachtet wurde. Es kann die produktive Version der Software sein, oder eine Version, die noch nicht in der Produktion ist, sondern sich erst noch im Test befindet. Weitere wichtige Information ist, das Wissen um die Fehlerschwere, und die Auftrittshäufigkeit.
Die Fehlerschwere
Mit der Fehlerschwere beschreiben wir den Schaden, den ein Fehler verursachen könnte, wenn er weiterhin bestehen bleibt. Hierfür werden Fehler in Kategorien zur Fehlerschwere (engl. severity) eingeteilt:
- Blocker
- Kritisch
- Hauptfehler
- Nebenfehler
- Trivialer Fehler
Wofür benötigen wir die Fehlerschwere?
In einem Satz und vereinfacht drückt die Fehlerschwere aus, wie „schlimm“ der Fehler ist. Die Fehlerschwere bildet das Produkt aus drei Informationen ab:
- Der Kritikalität des einzelnen Fehlers,
- der Auftrittswahrscheinlichkeit des Fehlers und
- der erwarteten Anzahl Transaktionen / Benutzer, die betroffen sind.
Zur Erläuterung:
Ein Fehler, der einen sehr großen Schaden verursacht, aber in der Produktion nie oder nur in 0.001 % der Fälle auftritt, ist wirkt auf den ersten Blick gar nicht so schlimm. Denkt ihr jetzt aber an Zahlungsverkehrsanbieter, der täglich 100 Mio. Transaktionen verarbeitet wie das SEPA Zahlungssystem für den Massenzahlungsverkehr, sieht das schon ganz anders aus. Hier wurden 2020 ca. 46 Milliarden Transaktionen verarbeitet, mit einem durchschnittlichen Betrag von ca. 780 € pro Transaktion.
Ein Fehler mit einer Eintrittswahrscheinlichkeit von 0,001 % kann in diesem System an jedem Tag, den er im System ist, einen Schaden von ca. 997.000 € verursachen oder anders es sind täglich ca. 1200 Zahlungen von dem Fehler betroffen.
(Quelle: SEPA Clearing Statistik 2020)
In jedem Unternehmen und Kontext werden diese Kategorien konkretisiert und beschrieben. Ein Beispiel für eine Kategorisierung der Fehlerschwere findet ihr hier
| Fehlerschwere | Beschreibung |
| Blocker | Die Software kann nicht genutzt werden, weil ihre Hauptfunktionalitäten für den Benutzer nicht nutzbar sind. Beispiel:
|
| Kritisch | Der Fehler verhindert die Nutzung einer wichtigen Funktionalität. |
| Hauptfehler | Der Fehler beeinträchtigt die Nutzung einer wichtigen Funktionalität, die Funktion kann aber über Umwege noch genutzt werden. Der Fehler verhindert die Nutzung einer unwichtigen Funktionalität. |
| Nebenfehler | Der Fehler beeinträchtigt die Nutzung einer unwichtigen Funktionalität, die Funktion kann aber über Umwege noch genutzt werden. |
| Trivialer Fehler | Schönheitsfehler oder Beeinträchtigung, die aber umgangen werden kann. |
(Die Beschreibung selbst wirft für den Tester auch wieder eigene Fragen auf, wie “Welche sind die Hauptfunktionen und was ist eine unwichtige Funktion”. Diese Fragen müssen jeweils im Kontext der zu bewertenden Software beantwortet werden und es gibt immer wichtigere und unwichtigere Funktionen. Für den Moment wollen wir es dabei belassen, dass Softwaretester:innen wissen müssen, dass es Funktionen gibt, die unterschiedlich wichtig für den Einsatz und Erfolg der Software sind.)
Die Auftrittshäufigkeit wird meist beschrieben und nicht fest einkategorisiert. Ein paar generelle Fragen helfen euch, dies zu beurteilen.
- Wie viele Kunden sind betroffen. (Alle / ein Großteil / ein paar / kaum einer)
- Wie viele Transaktionen können betroffen sein (100 % / 50 % / 1 %)
Für die Reparatur der Software sind alle Informationen nötig, die zu beschreiben, was ihr beobachtet habt und wie ihr den Zustand herstellen konntet. Eine gute Fehlerbeschreibung vereinfacht die nötigen Analysen und grenzt die zu analysierenden Bereiche in der Software ein.
Was muss in die Bugbeschreibung rein?
Was muss in die Bugbeschreibung rein?
Vorab noch ein Tipp: In jedem Bug Report soll nur genau ein Effekt beschrieben werden. Wenn ihr mehrere Beobachtungen habt, dann schreibt für jede Beobachtung einen eigenen Bug.
Mit den 6Ws könnt ihr die Beschreibung kurz zusammenfassen:
Wer hat Was mit Welcher Softwareversion beobachtet?
Welches Verhalten wurde erwartet?
Wie kann man Fehlverhalten nachstellen?
Welche Belege gibt es für das Fehlverhalten?
In eurem Projekt bietet es sich an, mit den Entwickler:innen zusammen eine Vorlage für einen Fehlerbericht zu vereinbaren, damit alle, die Fehler finden, diese auch so beschreiben, dass sie nachvollzogen und korrigiert werden können.
Der Fehlerlebenszyklus
Fehler durchlaufen von der Erfassung bis zur Behebung einen standardisierten Lebenszyklus. Das heißt, sie starten in einem definierten Zustand und enden in einem definierten Zustand. Dazwischen sind mehrere Übergänge erlaubt. Dieser Fehlerlebenszyklus hilft uns zu jeder Zeit zu wissen, wer als Nächstes etwas mit dem Fehler tun muss.
(In vielen Projekten verläuft der Lebenszyklus nicht rein linear, sondern es kann auch andere Zustandswechsel geben von z.B. von “testbar” nach “in Arbeit”, wenn die Fehlerkorrektur nicht ausreichend war.)
| Status | Beschreibung |
| Neu | Der Fehler wurde erfasst und kann beurteilt werden. |
| Offen | Der Fehler wurde beurteilt und soll bearbeitet werden. |
| In Arbeit | Der Fehler ist in der Bearbeitung. |
| Testbar | Der Fehler wurde vom Entwickler bearbeitet und als repariert markiert. Er kann nun mit einer neuen Version geprüft werden. |
| Geschlossen | Der Fehler wurde bearbeitet und behoben oder es ist kein Fehler und muss nicht weiter bearbeitet werden.v |
In den meisten Projekten werden die Fehler in einem System geführt und in diesem werden noch ein paar andere Daten erfasst und mitgeführt, um die Daten verwalten zu können und um automatische Auswertungen erstellen zu können. In der nachfolgenden Liste findet ihr einige Eigenschaften, die für einen Bug wichtig sind – je nachdem wie in eurem Kontext gearbeitet wird, kann die Menge der Eigenschaften hiervon abweichen. Fangt ihr aber bei null an und müsst in eurem Umfeld komplett neu beschreiben, was zu einem Bug alles an Informationen gehört, könnt ihr mit diesen Angaben sehr gut starten.
| Feld | Beschreibung |
| ID | Eindeutige Identifikation des Fehlers im System |
| Titel | Kurzer, eindeutiger Titel, der den Fehler möglichst konkret zusammenfasst. |
| Beschreibung | Vollständige Beschreibung der Schritte, die für die Nachstellung des Fehlers nötig sind. Schreibe hierfür die kompakteste Liste von Schritten, die nötig sind, um den Bug zu reproduzieren.
Gib die Daten, die für die Nachstellung des Fehlers genutzt wurden.
Andere Informationen, die relevant sein können:
|
| Status | Der Status eben, wie oben beschrieben. |
| Priorität | Priorität der Bearbeitung des Fehlers durch die Entwicklung. |
| Fehlerschwere | Die Fehlerschwere, wie oben beschrieben. |
| Anhänge | Screenshots, Logfiles und sonstige Informationen, die den Fehler genauer beschreiben. |
| Beziehungen | Testfälle, Anforderungen, User Storys, andere Fehler im Kontext |
| Gefunden in Version | Version und Buildnummer der Software, in welcher der Fehler beobachtet wurde. |
| Geschlossen in Version | Version und Buildnummer der Software, in welcher die Korrektur des Fehlers festgestellt wurde. |
| Gefunden am | Datum, an dem der Fehler erstellt wurde (wird meist automatisch erstellt). |
| Geschlossen am | Datum, an dem der Fehler geschlossen wurde (wird automatisch erstellt). |
Leseempfehlungen:
