Antwort

Hintergrund:

Mit zunehmender Komplexität der Software wurde festgestellt, dass viele Bugs nur außerhalb von Testfällen oder Spezifikationen entdeckt werden – oft sind diese Bugs für die realen Benutzer am kritischsten. Um solche Defekte zu finden, verwenden Tester spezielle Techniken und kombinieren standardisierte Tests mit ihrer eigenen Erfahrung.

Problem:

Versteckte Bugs, die mit der Interaktion von Komponenten, der fehlerhaften Handhabung nicht offensichtlicher Situationen oder fehlenden Anforderungen zusammenhängen, sind am schwierigsten zu erkennen und zu dokumentieren. Oft sind sich Tester unsicher, ob sie ein gefundenes Problem dokumentieren sollten, wenn es "nicht im Pflichtenheft steht".

Lösung:

Es werden Methoden der explorativen Tests, Paar-Tests und Erfahrungen mit ähnlichen Produkten verwendet. Dokumentieren Sie solche Bugs immer so detailliert wie möglich: Schritte, Beobachtungen, warum Sie diese als Defekt ansehen, Verweise auf verwandte Anforderungen oder akzeptierte Logik.

Schlüsselfunktionen:

Notwendigkeit für Initiative und kritisches Denken.
Es ist wichtig zu argumentieren, warum es sich um einen Defekt handelt.
In einigen Fällen ist es notwendig, sich mit Analysten/PO auszutauschen.

Fragen mit einem Haken.

Kann man Bugs, die nicht in den Anforderungen beschrieben sind, ignorieren oder nicht dokumentieren?

Nein, immer berichten, auch wenn es keinen genauen Verweis auf die Anforderung gibt, sonst gelangen kritische Probleme zum Kunden.

Ist eine Benutzerunfreundlichkeit ein Bug oder eine Verbesserung (Feature Request)?

Wenn das Verhalten eindeutig unlogisch ist, Verwirrung oder Risiken verursacht, als Bug dokumentieren, andernfalls als Verbesserung.

Sollte sich der Tester bei jedem nicht offensichtlichen Bug mit dem Team beraten?

Es wird empfohlen, den strittigen Fall zunächst mit einem Analysten oder Entwickler zu besprechen, um sinnlose Tickets zu vermeiden.

Typische Fehler und Anti-Patterns

Ignorieren von offensichtlichen Defekten für Benutzer, die nicht in den Anforderungen beschrieben sind.
Schwache/unvollständige Dokumentation von versteckten Bugs.
Fehlende Argumentation für den Bug-Report.

Beispiel aus dem Leben

Negativer Fall

Der Tester stellte fest, dass das System beim gleichzeitigen Öffnen von zwei Fenstern abstürzt, dokumentierte den Bug jedoch nicht, da dieses Szenario nicht in den Anforderungen und Testfällen beschrieben war.

Vorteile:

Er hat keinen "überflüssigen" Bug hinzugefügt, was den Entwicklern mehr Freiheit für andere Aufgaben gab.

Nachteile:

Das System wurde mit einer kritischen Schwachstelle veröffentlicht, die Kunden betroffen hat.

Positiver Fall

Der Tester dokumentierte den Bug mit einer Beschreibung des Schrittes (Öffnen von zwei Fenstern, Ablauf der Aktionen), fügte einen Screenshot bei und erklärte, warum er dies für einen Bug hält (ein echter Benutzer könnte in dieser Situation sein).