Funktionale Bugs beziehen sich auf die Funktionalität einer Software. Beispiele: Ein Button sendet das Formular nicht ab, die Suche reagiert nicht auf die Benutzereingabe, die App stürzt ab. Jedes Mal, wenn du eine Aktion ausführst und die Website/App nicht so reagiert, wie du erwartet hast, könnte es sich um ein funktionales Problem handeln. Unsere begrenzten Informationen über die Produkte unserer Kunden und das Fehlen von Kenntnissen über deren Implementierungen machen es schwer zu bestimmen, ob ein beobachtetes Verhalten beabsichtigt oder tatsächlich ein Bug ist. Durch Bildung von fundierten Vermutungen auf der Grundlage von Erfahrung und Analyse des Produktverhaltens durch Tests verschiedener Szenarien kannst du zu einer Antwort gelangen.
Wie man feststellt, ob das Verhalten einer App ein funktionaler Bug ist:
Versuche herauszufinden, ob eine Funktion einer Software auf eine bestimmte Weise entworfen wurde und so funktionieren soll oder tatsächlich defekt ist. Teste sie alleine und in Kombination mit anderen Funktionen, um potenzielle Unterschiede festzustellen.
Denke darüber nach, was die Absichten des Kunden gewesen sein könnten und berücksichtige, dass das Produkt möglicherweise so funktioniert, wie es implementiert wurde.
Finde Beweise dafür, dass etwas nicht so funktioniert, wie es sollte. Begründe deine Behauptung.
Beispiel: Eine Funktion in einem Webshop funktioniert anders als in anderen Webshops, die du kennst. Das bedeutet nicht unbedingt, dass die Funktion defekt ist. Der Kunde kann sein Produkt so implementieren, wie er möchte.
Beispiel: Du behauptest, ein Formularfeld werde nicht validiert und dies sei ein Bug. Gibt es Hinweise darauf, dass beabsichtigt war, dass das Feld validiert wird? Belege deine Behauptung, indem du zeigst, dass das Feld in einigen Fällen validiert wird, in anderen jedoch nicht. Wenn du keine Beweise liefern kannst, handelt es sich um eine unbewiesene Behauptung.
Ein visuelles oder inhaltliches Problem wird zu einem funktionalen Problem, wenn es eine Funktion behindert, und sollte daher als funktionaler Bug gemeldet werden.
Etwas funktioniert in verschiedenen Szenarien und ohne offensichtliche Probleme immer gleich? Dann ist es wahrscheinlich beabsichtigt (kein Bug) und du schlägst nur eine Änderung vor (Usability-Vorschlag).
Einschätzung des Schweregrades
Bei der Bewertung des funktionalen Schweregrads eines Bugs müssen mehrere Faktoren berücksichtigt werden: die funktionale Auswirkung des Problems, das Ausmaß des Problems, ob Workarounds vorhanden sind oder ob es sich um einen Showstopper handelt, ob es potenzielle und beträchtliche Umsatzverluste gibt und ob du diesen Bug mit anderen Bugs desselben Schweregrades vergleichen kannst.
Ein direkter Ansatz besteht darin, die funktionale Auswirkung des Bugs zu betrachten. Überlege, wie schwerwiegend es ist, wenn eine Funktion nicht verfügbar ist. Zweitrangige Funktionen werden Benutzer nicht daran hindern, ihr Ziel zu verfolgen, im Gegensatz zur Unterbrechung der Hauptfunktion. Frage dich, wie relevant eine bestimmte Funktion im Kontext des gesamten Produkts ist.
Die Frage, wie viele Personen, Produkte oder Elemente von einem funktionalen Problem betroffen sind, ist ein bestimmender Faktor für das Ausmaß des Problems. Funktioniert beispielsweise die Schaltfläche "In den Warenkorb legen" nicht auf allen Produktseiten eines Webshops oder nur auf bestimmten? Ist eine kleine Gruppe von Benutzern von dem Problem betroffen oder alle?
Überlege, ob du dein Ziel über einen alternativen Weg oder Option erreichen kannst oder ob eine Funktion weiterhin nicht verfügbar ist. Wenn du intuitiv und problemlos eine Übergangslösung für einen Bug, ermöglicht dieser sogenannte Workaround immer noch das Erreichen deines Ziels. Ein Bug mit einem Workaround erhält einen niedrigeren Schweregrad als ein äquivalenter Bug ohne Workaround. Schließlich handelt es sich bei einem Showstopper um einen Bug ohne Workaround für die blockierte Hauptfunktionalität.
Die Einschätzung eines potenziellen Umsatzverlusts ist ein sekundärer Ansatz, da du oft nur annehmen kannst, wie Benutzer auf einen Bug reagieren könnten. Berücksichtige dennoch, wie hoch ein potenzieller Verlust ist. Es macht einen großen Unterschied, ob der Preis eines Produkts um ein paar Cent oder Hunderte von Dollar abweicht.
Letztendlich kannst du deinen Bug auch mit denjenigen vergleichen, die derselbe Teamleiter bereits in diesem Test genehmigt hat, um herauszufinden, ob dein Schweregrad angemessen ist.
Wir haben drei Schweregrade für funktionale Bugs:
LOW:
Minimale Auswirkungen auf die Nutzung des Produkts.
Das Produkt zeigt ein unbeabsichtigtes Verhalten, aber die allgemeine Nutzung ist nicht betroffen.
Wenige Benutzer, Produkte oder Elemente sind betroffen.
Eine Funktion/Funktionalität ist defekt oder nicht verfügbar, aber ein einfacher Workaround löst das Problem.
HIGH:
Schwerwiegende Auswirkungen auf die Nutzung des Produkts, aber die Hauptfunktionalität ist intakt.
Eine große Anzahl von Benutzern, Produkten oder Elementen ist betroffen.
Eine nicht triviale Funktionalität ist defekt oder nicht verfügbar, und es gibt keinen Workaround.
Wichtige Funktionen sind defekt oder nicht verfügbar, aber es gibt einen Workaround (daher kein Showstopper).
CRITICAL:
Der Bug verhindert die Kernfunktionalität der App oder Website.
Ein Showstopper hindert den Benutzer daran, einen Hauptprozess fortzusetzen, z. B. den Bestellvorgang.
Der Bug führt zu einem potenziellen und beträchtlichen Umsatzverlust für das Unternehmen, welches die App oder Website betreibt.
Allgemeine Bewertungen
Wir haben eine Liste von Fällen mit festgelegten Schweregraden erstellt. Das oben beschriebene Bewertungsschema gilt nicht für diese Fälle. Da die Liste im Laufe der Zeit aktualisiert wird, überprüfe sie bitte regelmäßig.
Edge Case Bugs
Edge Case Bugs (zu Deutsch "Grenzfall-Bugs") treten auf, wenn eine Funktion auf eine unübliche Weise verwendet wird. Es funktioniert jedoch korrekt, wenn sie mit typischen Daten und typischen Benutzeraktionen verwendet wird. Hier sind einige Beispiele:
Sofortige Aktionen wie das Minimieren einer App nach dem Klicken auf eine Schaltfläche.
Wiederholtes Ausführen derselben Aktion, z. B. Öffnen und Schließen von Menüs.
Jeder Bug, der nur nach einer ungewöhnlichen Abfolge von Aktionen auftritt.
Jeder Fall muss einzeln bewertet werden. Edge Case Bugs, die relevant für unsere Kunden sind, werden als Low-Bugs weitergeleitet. Irrelevante Fälle, was die meisten Edge Case Bugs ausmachen, werden abgelehnt.
Erzwungene Bugs
Das Erzwingen eines Bugs durch untypisches Verhalten oder besondere Bedingungen ist im Allgemeinen out of Scope, da solche Bugs für unsere Kunden nicht relevant sind. Untypisches Verhalten spiegelt nicht das normale Benutzerverhalten wider. Beispiele für untypisches Verhalten oder besondere Bedingungen:
Tippen auf mehrere Elemente gleichzeitig.
Zufälliges Drücken von Tasten.
Schnelles Klicken auf eine Schaltfläche mehrmals hintereinander.
Verkleinern des Browser-Fensters auf untypische Größen.
Voller RAM oder interner Speicher führt zu unerwartetem Verhalten.
Verwendung von inoffiziellen, Beta- oder modifizierten Betriebssystemversionen.