Was tun mit Fehlern, die nicht repro?

Ich habe einen Tester, bei dem beim Testen ein Fehler auftritt (soweit in Ordnung), aber er meldet ihn dann häufig sofort. Wir (die Entwickler) stellen dann später fest, dass der Tester nicht versucht hat, das Problem zu reproduzieren, und (wenn er gefragt wird) keinen Weg finden kann, um es wieder in Gang zu bringen.

Nun, das sind immer noch Fehler, ich möchte sie nicht ignorieren. Aber ohne Repro-Schritte stecke ich irgendwie fest. Manchmal gibt es einen Stack-Trace (obwohl dies häufig nicht sinnvoll ist, da dies ein kompaktes Framework ist und keine Zeilennummern vorhanden sind). Aber wenn es einen gibt, kann ich den Stack-Trace nehmen und den Code aufbrechen und anfangen zu raten, aber das führt nicht zu testbaren "Fixes".

Was machen Sie in solchen Szenarien?

Ein Fehler ohne Kontext ist kein Fehler, sondern ein Zufall. Das Problem könnte Ihr Code sein, es könnte eine Bibliothek von Drittanbietern sein, es könnte die Hardware sein oder es könnte Sonneneinstrahlung sein, die ein einzelnes Bit veranlasst, sich von selbst umzudrehen. Wenn Sie es nicht mit einer gewissen Regelmäßigkeit reproduzieren können (auch wenn es nur "alle 10 oder 20 Mal passiert, wenn ich X mache"), ist es nicht viel besser, als wenn Ihr Tester Ihnen sagt: "Irgendetwas ist irgendwie schiefgegangen - beheben Sie es." .

Möglicherweise müssen Sie Ihrem Tester erklären, dass es seine Aufgabe ist, nicht nur Input zu generieren, bis etwas kaputt geht. Wenn es so wäre, könnten Sie ihn durch einen Zufallsgenerator ersetzen. Ein Teil seiner Aufgabe ist es, Fehler zu identifizieren, was die Identifizierung der Art und Weise, wie sie produziert werden, mit sich bringt.

Letztendlich, wenn weder der Entwickler noch der Tester den Fehler reproduzieren können, sollte er geschlossen, aber als solcher gekennzeichnet werden.

Es ist jedoch umstritten, wie lange Sie brauchen, um an diesen Punkt zu gelangen.

Einige Leute würden argumentieren, wenn es nicht sofort reproduzierbar ist, dann sollte es sofort geschlossen werden.

Normalerweise bemühe ich mich, mehr Informationen vom Urheber des Problems zu erhalten. Möglicherweise haben sie im Originalbericht etwas vergessen. Ein Gespräch über die erforderlichen Schritte kann häufig die fehlenden Informationen preisgeben.

Ein letzter Gedanke - geschlossen als "no-repro" bedeutet nicht behoben. Wenn es ein echtes Problem gibt, wird es sich früher oder später zeigen. Wenn Sie alle Informationen haben, die Sie benötigen, können Sie das Problem endgültig reproduzieren.

Noch ein paar Vorschläge:

1. Fügen Sie Ihrem Produktcode die Protokollierung (und nicht nur einen Keylogger:}) hinzu. "No repro" -Fehler können Fehler sein, aber sie können Speicher- oder Statusverfälschungen sein, die nur auf einem unsauberen System auftreten, das auf unerwartete Weise verwendet wird (z. B. wie ein Kundencomputer). Durch Protokollieren oder Aufzeichnen von Informationen können Sie herausfinden, was möglicherweise falsch war, als der Tester den Zufall fand.

2. Scannen Sie den Rest der "no repro" -Fehler in der Datenbank (oder was auch immer Sie für die Fehlerverfolgung verwenden). Oft verklumpen die Egel in einem Bereich des Produkts. Wenn es so aussieht, als ob eine Komponente fehlerhaft ist, überprüfen Sie die Komponente im Code auf mögliche Fehler, fügen Sie dieser Komponente zusätzliche Protokollierung hinzu - oder beides.

3. Nehmen Sie sich ungefähr eine halbe Stunde Zeit und sehen Sie sich Ihren Test an. Ihr Ansatz kann Ihnen eine Vorstellung davon geben, was schief gelaufen ist (z. B. "interessant - ich wusste nicht, dass Sie auf diese Weise zu diesem Dialog gelangen können"). Möglicherweise überspringen sie auch unbeabsichtigt einen Dialog- oder Konfigurationsschritt. Es lohnt sich die Zeit zu investieren, um ein bisschen in den Kopf zu kommen.

Ich mache QA für einen großen kommerziellen Code, dieses irritierende Szenario taucht viel zu oft auf. Normalerweise deutet dies darauf hin, dass auf allen von uns unterstützten Plattformen keine gekapselten Prozeduren zum Erstellen der Binärdatei vorhanden sind. Wenn der Entwickler also seinen eigenen Code erstellt (den er zum Debuggen und Reparieren ausführen muss) und nicht denselben Erstellungsprozeduren wie im Brief folgt, besteht die Möglichkeit, dass systemabhängige Fehler auf magische Weise verschwinden (oder auftreten). . Natürlich werden diese Dinge normalerweise mit "Funktioniert für mich" in der Fehlerdatenbank geschlossen. Wenn sie beim nächsten Ausführen des Problems fehlschlagen, kann der Fehler erneut geöffnet werden. Wann immer ich vermute, dass ein Fehler systemabhängig ist, versuche ich, ihn auf verschiedenen Plattformen zu testen und zu melden, unter welchen Bedingungen er auftritt. Häufig tritt ein Speicherbeschädigungsproblem auf, wenn die beschädigten Daten groß genug sind, um einen Absturz zu verursachen. Einige Plattformen (Hardware- und Betriebssystemkombinationen) stürzen möglicherweise näher an der eigentlichen Ursache der Beschädigung ab, und dies kann für den armen Kerl, der das Problem beheben muss, sehr wertvoll sein.

Der Tester muss einen Mehrwert schaffen, der über die bloße Meldung eines Systemfehlers hinausgeht. Ich verbringe viel Zeit damit, Fehlalarme auszusortieren. Möglicherweise war die betreffende Plattform überlastet oder das Netzwerk hatte einen Defekt. Und ja, manchmal kann man etwas bekommen, das wirklich von zufälligen Timing-Ereignissen betroffen ist. Hardwarefehler können oft wie Protobeispiele sein: Wenn zwei Datenanforderungen mit genau der gleichen Taktperiode zurückkommen und die Hardwarelogik zur Behandlung des potenziellen Konflikts fehlerhaft ist. dann wird der Fehler nur zeitweise angezeigt. Ebenso kann es bei der parallelen Verarbeitung zu Fehlern kommen, die nur einmal in einem blauen Mond auftreten, und deren statistische Unwägbarkeit macht das Debuggen zu einem Albtraum.

Außerdem wird unser Code in der Regel mehrmals täglich aktualisiert. Das Aufspüren einer genauen Versionsnummer des Quellcodes, wenn er nach Süden ging, kann eine sehr nützliche Information für das Debuggen sein. Der Tester sollte nicht in einer kontroversen Beziehung zu den Debuggern und Entwicklern stehen, er ist als Teil eines Teams da, um die Qualität des Produkts zu verbessern.

Es gibt zwei Arten von Fehlern, die nicht reproduzierbar sind:

1) Diejenigen, die ein Tester (oder Benutzer) einmal gesehen hat, aber entweder nicht in der Lage war oder nicht versucht hat, zu reproduzieren.

In diesen Situationen sollten Sie:

• Überprüfen Sie ganz kurz die grundlegenden Abläufe, bei denen sich herausgestellt hat, dass der Defekt nicht reproduzierbar ist.

• Sprechen Sie mit dem Tester / Benutzer, um festzustellen, ob andere Informationen hilfreich sind.

• Vergleichen Sie sie mit anderen Fehlern, um festzustellen, ob Sie über genügend Informationen verfügen, um sie anhand mehrerer Instanzen zu untersuchen. Sie werden vielleicht feststellen, dass dieses eine Problem nicht genügend Informationen enthält, um weiterzumachen. In Verbindung mit einer Reihe anderer Probleme könnte es jedoch auf etwas hindeuten, das es wert ist, untersucht zu werden.

• Wenn Sie immer noch nicht genug haben, um fortzufahren, müssen Sie dem Benutzer / Tester erklären, dass Sie nicht genug Informationen haben. Erklären Sie ihnen höflich, wie genug Informationen aussehen und warum sie benötigt werden.

2) Diejenigen, bei denen sie nicht zuverlässig reproduziert werden können. Es gibt jedoch genügend Anhaltspunkte (in Bezug auf wiederholte Vorkommen), um darauf hinzuweisen, dass der Defekt vorliegt. Ich sehe dann eher, dass es sich um Entwicklerprobleme handelt und dass der Entwickler vom Tester unterstützt wird / user - muss untersuchen.

Dies ist wahrscheinlich langsam und schmerzhaft. Sie müssen wahrscheinlich den Code durchgehen, mehr Protokollierung hinzufügen, die Daten überprüfen und mit den Testern / Benutzern ausführlich sprechen, aber wenn es genügend Beweise gibt, die darauf hindeuten, dass dies wahrscheinlich ist ist ein Problem, bei dem Sie die Verantwortung übernehmen und alles tun müssen, um es zu beheben.

Es hört sich so an, als ob dies relativ häufig vorkommt - was mich wundert, liegt es daran, dass die meisten Fehler wirklich schwer zu reproduzieren sind, oder aus einem anderen Grund, den er nicht versucht? Wissen Sie, warum er nicht versucht, das Problem zu reproduzieren? Ist es, weil er nicht weiß, wie wichtig es für Sie ist? Oder ist es vielleicht so, dass er anderen Druck ausgesetzt ist - ein Testmanager, der nur möchte, dass er die zugewiesenen Tests schnell durchläuft und die Insekten zum Beispiel über die Mauer wirft? Oder ist er sich einfach nicht sicher, wie er vorgehen soll?

Ich stimme anderen zu, dass die Arbeit an einer besseren Protokollierung Priorität hat. Wenn Sie in der Zwischenzeit den Verdacht haben, dass ein Mangel an Testerfähigkeiten / -vertrauen ein Problem sein könnte, dann gefällt mir dieser Artikel von Danny Faught über die Fehlerisolierung sehr gut - Sie könnten ihn zunächst darauf hinweisen.

Wenn sich herausstellt, dass das Problem auf den Druck des Managements zurückzuführen ist, haben Sie mein Mitgefühl, denn das ist schwer zu knacken, insbesondere wenn Tester und Programmierer an verschiedene Manager berichten und die Manager nicht bereit sind, einem anderen Team zu "helfen".

Normalerweise stelle ich fest, dass es nicht reproduzierbar ist, lasse es jedoch offen, bis diese Test- oder Iterationsreihe abgeschlossen ist.

Wenn es zu diesem Zeitpunkt noch nicht reproduziert wurde, wird es geschlossen, kann aber wieder geöffnet werden, wenn es erneut auftritt.

Kleben Sie einen Keylogger auf die Workstation dieses Testers!

Nun, die erste Aufgabe ist es, ein reproduzierbares Testsystem zu haben. Ihr Tester muss einen genau definierten Prozess haben - wenn möglich automatisch.

Haben Sie diese drei Bedingungen:

• Gleiche Binärdatei
• Gleiche Schritte
• Gleiche Maschine

Wenn der Fehler unter den oben genannten 3 Bedingungen sporadisch auftritt, beginnen Sie, ihn weiter zu isolieren. Betrachten Sie jede Ebene des Systemstapels und seine Konfiguration.

Eine Möglichkeit zum Erkennen von Speicherverwaltungsfehlern besteht darin, das Programm auf mehreren Betriebssystemen mit mehreren Compilern auszuführen. Valgrind kann auch helfen.

Typischerweise können parallele Systeme jedoch Non-Repro-Bugs auslösen. Dinge wie Puffergrößen und Verarbeitungsgeschwindigkeiten, Asynchronisierung, Datenbanksperren, variable Speicherschreibverschachtelungen; All dies kann zu Problemen führen. Und so weiter und so fort.

Zunächst sollten Sie ein strenges Testverfahren durchführen (aber ich verstehe Sie, in meinem Unternehmen passiert das, was Sie beschrieben haben, häufig).

Abhängig von der Schwere des Fehlers können Sie etwas Zeit darauf verwenden oder es (besser) ignorieren, bis Repro-Schritte bereitgestellt werden.