再現しないバグをどうするか？

テスト中にエラーが発生するテスターがいますが（これまでのところ）、すぐに頻繁に報告します。私たち（開発者）は、テスターが問題を再現しようとしておらず、（尋ねられたときに）問題を再現する方法を見つけることができないことを後で発見します。

今、これらはまだバグです、私はそれらを無視したくありません。しかし、再現手順がないと、ちょっと行き詰まります。スタックトレースがある場合もあります（ただし、これはコンパクトなフレームワークであり、行番号がないため、しばしば有用ではありません）。しかし、ある場合、スタックトレースを取得してコードをクラックし、推測を開始できますが、テスト可能な「修正」にはつながりません。

このようなシナリオでは何をしますか？

コンテキストのないバグはバグではなく、まぐれです。問題はあなたのコードかもしれないし、サードパーティのライブラリかもしれないし、ハードウェアかもしれないし、太陽放射が原因で単一ビットがそれ自身で反転するかもしれない。少なくともある程度の規則性を持って再現できない場合（「Xを10回または20回実行するたびに」でも）、テスターが「どこかで問題が発生しました-修正してください」と言うのはあまり良くありません。 。

テスターに​​何かが壊れるまで入力を生成するだけではないことをテスターに​​説明する必要があるかもしれません。もしそうなら、あなたは彼を乱数ジェネレータに置き換えることができます。彼の仕事の一部は、バグを特定することであり、バグの生成方法を特定する必要があります。

最終的には、開発者もテスターもバグを再現できない場合、バグをクローズする必要がありますが、そのようにマークする必要があります。

ただし、そのポイントに到達するまでにかかる時間は議論の余地があります。

一部の人々は、それがすぐに再現可能でなければ、すぐに閉じられるべきだと主張するでしょう。

私は通常、問題の発信者からより多くの情報を取得しようと努めています。元のレポートで忘れていたものがあるかもしれません。必要な手順について話し合うと、欠落している情報が明らかになることがよくあります。

最後の考え-「非再現」として修正されたという意味ではありません。実際の問題がある場合、遅かれ早かれそれ自体が明らかになり、問題を最終的に再現できるときに役立つすべての情報が手に入ります。

さらにいくつかの提案：

1. 製品コードにロギング（キーロガーだけでなく：}）を追加します。「再現なし」のバグは吸血鬼かもしれませんが、予想外の方法で使用されるダーティシステム（つまり、顧客のコンピューターなど）でのみ発生するメモリまたは状態の破損である可能性があります。ロギングまたはトレース情報は、テスターが吸虫を見つけたときに何が間違っていたのかを把握するのに役立ちます。

2. データベース内の残りの「再現性のない」バグ（またはバグ追跡に使用するもの）をスキャンします。多くの場合、吸虫は製品の1つの領域に集まっています。1つのコンポーネントに障害があるように見える場合、コードでコンポーネントのフレーク性を確認し、そのコンポーネントにログを追加します-またはその両方です。

3. 30分ほどかけて、テスターのテストを見てください。彼らのアプローチは、何がうまくいかなかったのかをあなたに教えてくれるかもしれません（例えば、「おもしろい-そのようにダイアログに到達できるとは知りませんでした」）。また、意図せずにダイアログまたは構成ステップをスキップすることもあります。時間をかけて投資する価値はあります。

私は大規模な商用コードでQAを行っていますが、この刺激的なシナリオは頻繁に発生します。通常、これは、サポートするすべてのプラットフォームでバイナリを構築するための厳格な手順がないことを示しています。そのため、開発者が独自のコード（デバッグと修正のために行う必要がある）をビルドし、同じビルド手順に従わない場合、システム依存のバグが魔法のように消える（または表示される）可能性があります。もちろん、これらは通常、バグデータベース内の「works for me」で閉じられ、その問題が次に実行されたときに失敗した場合は、バグを再度開くことができます。バグがシステムに依存していると思われるときはいつでも、さまざまなプラットフォームでテストし、どのような状況でバグが発生するかを報告しようとします。破損したデータがクラッシュを引き起こすのに十分な大きさである場合、多くの場合、メモリ破損の問題が発生します。一部のプラットフォーム（ハードウェアとOSの組み合わせ）は、実際の破損の原因により近い場所でクラッシュする可能性があり、これはデバッグする必要のある貧しい人にとって非常に価値があります。

テスターは、システムに障害が発生したことを報告するだけでなく、付加価値を付ける必要があります。偽陽性の選別に多くの時間を費やしています。問題のプラットフォームが過負荷になっているか、ネットワークに不具合がある可能性があります。そして、はい、時々ランダムなタイミングイベントによって本当に影響を受けるものを得ることができます。ハードウェアのバグはしばしばプロトタイプの例のようになります：2つのデータ要求がまったく同じクロック周期で戻ってきて、潜在的な競合を処理するためのハードウェアロジックに欠陥がある場合、バグは断続的にしか現れません。同様に、並列処理では、慎重に設計してソリューションが高速になったプロセッサに依存しないように制約しない限り、ブルームーンで1回しか発生しないバグが発生する可能性があり、その統計的不確実性によりデバッグが悪夢になります。

また、通常は毎日何回もコードが更新されており、ソースコードのリビジョン番号を正確に追跡することで、デバッグ作業に役立つ情報を得ることができます。テスターはデバッガーや開発者と敵対関係にあるべきではなく、製品の品質を改善するチームの一員としてそこにいます。

再現性のない2種類のバグがあります。

1）テスター（またはユーザー）が一度見たものの、再現することができなかったか、再現を試みなかったもの。

これらの状況では、次のことを行う必要があります。

• 欠陥を示した基本的なアクションコースを非常に簡単にチェックして、再現性がないことを確認します。

• テスター/ユーザーに相談して、役立つその他の情報があるかどうかを確認します。

• 複数のインスタンスに基づいてそれらを調べるのに十分な情報があるかどうかを確認するために、関連する可能性のある他の欠陥と相互参照します。この1つの問題では、続行するのに十分な情報が得られないことがありますが、他の多くの問題と組み合わせると、調査する価値のない何かが提案されます。

• それでもまだ十分ではない場合は、十分な情報がないことをユーザー/テスターに​​説明する必要があります。十分な情報がどのように見えるか、なぜ必要なのかを丁寧に説明します。

2）それらを確実に再現できないが、欠陥が存在することを示唆する十分な証拠（繰り返し発生に関して）がある場合、これらは開発者の問題であり、開発者-テスターに​​よってサポートされていることがわかります/ユーザー-調査する必要があります。

これは遅くて痛みを伴う可能性があります。コードを歩いて、ログを追加し、データを見て、テスター/ユーザーと詳細に話す必要がありますが、それがある可能性があることを示唆する十分な証拠がある場合所有権を取得し、修正するために必要なことをすべて行う必要がある問題です。

これは比較的頻繁に発生するように聞こえます-これは私が疑問に思う、それはほとんどのバグが本当に再現するのが難しいからだろうか、それとも彼がしようとしていない他の理由のためですか？彼が問題を再現しようとしていない理由を知っていますか？それは彼があなたにとってどれほど重要かを知らないからでしょうか？それとも、彼には他のプレッシャーがあるのでしょうか？たとえば、割り当てられたテストをすぐに通過して、壁にバグを投げてもらいたいだけのテストマネージャーですか？それとも、彼はそれについてどうやって行くのか分からないのでしょうか？

私は、より良いロギングに取り組むことが優先事項であることを他の人に同意します。それまでの間、テスターのスキル/自信の欠如が問題であると思われる場合、バグ分離に関するDanny Faughtのこの記事が本当に気に入っています。

問題が管理者のプレッシャーによるものであることが判明した場合、特にテスターとプログラマーが別のマネージャーに報告し、マネージャーが別のチームを「手助け」する傾向がない場合、それはクラックするのが難しいので、あなたは私の同情を持っています。

通常、再現性はありませんが、テストまたは反復のバッチが完了するまで開いたままにしておきます。

その時点までに複製されていない場合は閉じられますが、再度遭遇した場合は再度開くことができます。

このテスターのワークステーションにキーロガーを貼り付けてください！

さて、最初のタスクは再現可能なテストシステムを用意することです。テスターには明確に定義されたプロセスが必要です。可能な場合は自動です。

次の3つの条件があります。

• 同じバイナリ
• 同じ手順
• 同じ機械

上記の3つの条件で散発的にバグが発生する場合は、さらに隔離を開始します。システムスタックの各レベルとその構成を検討してください。

メモリ管理エラーを検出する1つの方法は、複数のコンパイラーを備えた複数のOSでプログラムを実行することです。Valgrindも役立ちます。

ただし、通常、並列システムは再現性のないバグを引き起こす可能性があります。バッファサイズと処理速度、非同期io、データベースロック、可変メモリ書き込みインターリーブなど。これらはすべて問題を引き起こす可能性があります。などなど。

まず第一に、あなたは厳密なテスト手順を持っている必要があります（しかし、私の会社ではあなたが説明したことが頻繁に起こることを理解しています）。

バグの重大度に応じて、ある程度の時間を費やすか、（より良い）再現手順が提供されるまで無視することができます。