-
Ursprüngliche Adresse: Warum Fehler nicht behoben werden
Autor: Alan Page, Director of Excellence in Test Engineering bei Microsoft, Co-Autor des Buches How We Test Software at Microsoft (auf Chinesisch übersetzt als „Microsofts Software-Test-Methode“).
Übersetzung: Lu Yueli, Lu Mengyan, Wang Hong
In letzter Zeit treffe ich immer mehr Leute, die überrascht sind, dass wir ein fehlerhaftes Produkt herausbringen würden. Was mich überraschte, war, dass viele dieser Leute Softwaretester waren und ich dachte, sie wüssten bereits davon. Ich empfehle Ihnen, zuerst den früheren (aber hervorragenden) Artikel von Eric Sink zu lesen. Ich bin mir nicht sicher, wie viel ich noch zu diesem Thema beitragen kann, aber ich möchte es versuchen.
Viele Fehler sind es nicht wert, behoben zu werden. „Sind Sie ein Tester?“, werden Sie mich anschreien, „Ich kann es noch einmal wiederholen (falls nötig): Viele Fehler sind es nicht wert, behoben zu werden.“ „Lassen Sie mich Ihnen sagen, warum. In den meisten Fällen erfordert die Behebung eines Fehlers eine Änderung des Codes. Und die Änderung des Codes erfordert eine Investition von Ressourcen (Zeit) und bringt Risiken mit sich. Das ist scheiße, aber es ist wahr. Manchmal, wenn das Risiko und die Investition weit gehen.“ überwiegen den Wert der Behebung der Fehler, daher werden wir sie nicht beheben.
Unsere Entscheidung darüber, ob ein Fehler behoben wird, basiert nicht auf dem „Gefühl“ und sollte dies auch nicht sein. Ich verwende gerne das Konzept des „Benutzerschmerzes“, um mir bei der Entscheidungsfindung zu helfen. Ich verwende drei Schlüsselfaktoren, um „Benutzerschmerzen“ zu berücksichtigen und zu identifizieren:
1. Schweregrad – Welche Auswirkungen wird dieser Fehler haben – führt er zum Absturz des gesamten Programms? Gehen dadurch die Informationen des Benutzers verloren? Oder ist es nicht so ernst? Gibt es eine einfachere Lösung? Oder ist es nur ein irrelevantes Thema?
2. Häufigkeit – Tritt dieses Problem bei Benutzern häufig auf? Ist es Teil des Hauptarbeitsablaufs des Programms? Oder ist es in einer Funktion versteckt, die nicht häufig verwendet wird? Kleinere Probleme, die in den am häufigsten verwendeten Teilen des Programms bestehen, müssen wahrscheinlich behoben werden, während einige große Probleme, die in den weniger häufig verwendeten Teilen des Programms bestehen, möglicherweise beiseite gelegt werden.
3. Auswirkungen auf die Kunden – Wenn Sie Ihre Hausaufgaben gut gemacht haben, sollten Sie bereits wissen, wer Ihre Kunden sind und wie viele (oder wie viele Sie hoffen) Benutzer es in jeder Ihrer Kundengruppen geben wird. Dann müssen Sie beurteilen, ob dieses Problem alle Benutzer oder nur einige Personen betrifft. Wenn Sie verfolgen können, wie Kunden Ihr Produkt nutzen, können Sie genauere Daten erhalten.
Die oben genannten drei Faktoren bilden eine Formel. Weisen Sie jedem der oben genannten Faktoren einen Wertebereich zu und führen Sie einige Berechnungen durch. Sie können Gewichte basierend auf Ihren Anwendungs- und Marktfaktoren direkt addieren, multiplizieren oder addieren. Beispielsweise müssen wir nur eine Addition durchführen und jedem Fehler einen numerischen Bereich von 10 Punkten zuweisen.
Fehler Nr. 1: Beispielsweise handelt es sich um einen Fehler, der das Programm zum Absturz bringt (10 Punkte), er existiert in einem Großteil des Programms (10 Punkte) und betrifft 80 % der Kunden (8 Punkte), also verursacht dieser Fehler „Benutzerschmerz“ „Die Lautstärke beträgt 28 Punkte und wir wetten, dass wir das Problem beheben werden.“
Fehler Nr. 2: Es handelt sich lediglich um einen Anordnungsfehler (2 Punkte), er erscheint im sekundären Fenster (2 Punkte) und der Teil des Programms, in dem sich der Fehler befindet, wird nur in älteren Versionen verwendet (2 Punkte). Daher beträgt der „Benutzerschmerz“-Wert dieses Fehlers 6 Punkte und wir werden ihn wahrscheinlich nicht beheben.
Leider sind viele Situationen nicht so einfach wie oben beschrieben. Fehler Nr. 3 ist ein Datenverlustproblem (10 Punkte), das in einem Großteil einer Anwendung auftritt, aber nur unter bestimmten Umständen fehlschlägt (5 Punkte) (die Daten sind übrigens subjektiv). Kundenrecherchen belegen, dass es selten genutzt wird (2 Punkte). Daher beträgt der „Benutzerschmerz“-Wert 17 Punkte. Dies sind mehrdeutige Daten, die geändert werden können oder nicht. Einerseits lohnt sich die für die Behebung erforderliche Investition möglicherweise nicht, aber solange das Problem verstanden wird und keine blinden Flecken vorhanden sind, ist das Ignorieren des Fehlers wahrscheinlich der richtige Ansatz.
Andererseits muss man es gegen andere Fehler im System abwägen. Wir wenden hier den „Broken Window“-Effekt an. Wenn die Anwendung zu viele solcher Fehler mit mittlerem Schwellenwert enthält, wird die Qualität des Produkts (oder zumindest die Wahrnehmung der Qualität) stark beeinträchtigt. Wenn Sie jeden Fehler im System betrachten, sollten Sie auch andere (bekannte) Fehler im System berücksichtigen und diese nutzen, um zu analysieren und zu entscheiden, welche Fehler behoben werden müssen und welche es nicht wert sind, behoben zu werden.
Es ist in der Tat eine sehr schlechte Sache, Fehler in offiziell veröffentlichter Software zu haben – aber basierend auf unseren vorhandenen Entwicklungstools und Entwicklungssprachen haben wir noch keine vernünftigere Lösung gefunden.
Auffüllen:
Während ich dies schreibe, glaube ich, dass mir ein vierter Faktor in der Formel fehlt: das Veröffentlichungsdatum. Dieser Faktor spielt auch eine Schlüsselrolle bei der Entscheidung, einen Fehler zu beheben bzw. nicht zu beheben, wenn das Veröffentlichungsdatum näher rückt. Allerdings bin ich mir nicht sicher, ob es sich um den vierten Faktor handelt und auch nicht, wie hoch der Schwellenwert für den „Benutzerschmerz“ ist, der erforderlich ist, um einen Fehler kurz vor der Veröffentlichung zu beheben.