再現しないバグをどうするか？
テスト中にエラーが発生する（今のところ問題ありません）テスターがいますが、すぐに頻繁に報告します。その後、私たち（開発者）は、テスターが問題の再現を試みておらず、（要求された場合）問題を再度発生させる方法を見つけることができないことに後で気付きました。
これらはまだバグなので、無視したくありません。しかし、再現手順がないと、私はちょっと行き詰まっています。スタックトレースが存在する場合があります（ただし、これはコンパクトなフレームワークであり、行番号がないため、役に立ちません）。しかし、スタックトレースがある場合は、スタックトレースを取得してコードを解読し、推測を開始できますが、テスト可能な「修正」は行われません。
このようなシナリオでは何をしますか？
コンテキストのないバグはバグではなく、まぐれです。問題はあなたのコードかもしれません、それはサードパーティのライブラリかもしれません、それはハードウェアかもしれません、またはそれは単一のビットがそれ自身で反転する原因となる日射であるかもしれません。少なくともsomeの規則性でそれを再現できない場合（たとえ「Xを実行するのが10または20回に1回発生する」だけでも）、テスターが「どこかで何かを言っているのと同じです」どういうわけか間違っていました-修正してください。」.
何かが壊れるまで入力を生成するだけでは彼の仕事ではないことをテスターに説明する必要があるかもしれません。もしそうなら、あなたは彼を乱数ジェネレータに置き換えることができます。彼の仕事の一部は、バグを特定することです。バグの作成方法を特定する必要があります。
最終的に、開発者もテスターもバグを再現できない場合は、クローズする必要がありますが、そのようにマークします。
ただし、その時点までにどのくらい時間がかかるかは議論の余地があります。
一部の人々は、それがすぐに再現可能でなければ、すぐに閉じられるべきだと主張するでしょう。
私は通常、問題の発信者からより多くの情報を取得しようと努めています。元のレポートで忘れていた可能性があります。必要な手順について話し合うと、不足している情報が明らかになることがよくあります。
最後の1つの考え-「no-repro」としてクローズしない修正済みを意味します。実際の問題がある場合、遅かれ早かれそれが明らかになり、最終的に問題を再現できるときに役立つすべての情報が得られます。
さらにいくつかの提案：
ロギング（キーロガーだけではない：}）を製品コードに追加します。 「再現なし」のバグは欠陥である可能性がありますが、予期しない方法で使用されたダーティシステム（顧客のコンピューターなど）でのみ発生するメモリまたは状態の破損である可能性があります。ロギングまたはトレース情報は、テスターがまぐれを見つけたときに何がmayが間違っていたかを理解するのに役立ちます。
データベース内の残りの「再現不可」バグ（またはバグ追跡に使用するもの）をスキャンします。多くの場合、吸虫は製品の1つの領域に集まります。 1つのコンポーネントで障害が発生しているように見える場合は、コードでコンポーネントのフレークを確認し、そのコンポーネントに追加のロギングを追加するか、またはその両方を行います。
30分ほどかかり、テスターのテストを観察します。彼らのアプローチは、何がうまくいかなかったかのアイデアをあなたに与えるかもしれません（例えば、「興味深い-私はあなたがその方法でそのダイアログに到達できることを知りませんでした」）。また、意図せずにダイアログや設定手順をスキップする場合もあります。彼らの頭に少し入るのは時間の投資の価値があります。
私は大規模な商用コードでQAを行っていますが、この苛立たしいシナリオは頻繁に発生します。通常、これは、サポートするすべてのプラットフォームでバイナリをビルドするための鉄板の手順がないことを示しています。したがって、開発者が独自のコードをビルドし（デバッグと修正を行う必要がある）、同じビルド手順に従っていない場合、システムに依存するバグが魔法のように消える（または表示される）可能性があります。 。もちろん、これらは通常、バグデータベースの「work for me」でクローズされ、次にその問題が実行されたときに失敗した場合、バグを再び開くことができます。バグがシステムに依存していると思われる場合は常に、さまざまなプラットフォームでテストし、どのような状況で発生するかを報告します。多くの場合、破損したデータがクラッシュを引き起こすのに十分な大きさである場合、メモリ破損の問題が発生します。一部のプラットフォーム（ハードウェアとOSの組み合わせ）は、破損の実際の原因に近い場所でクラッシュする可能性があり、これは、デバッグする必要のある貧しい人にとって非常に貴重な場合があります。
テスターは、システムに障害が発生したことを報告するだけでなく、付加価値を付ける必要があります。私は多くの時間を偽陽性のスクリーニングに費やしています。おそらく、問題のプラットフォームが過負荷になっているか、ネットワークに問題があったのでしょう。そして、はい、時々ランダムなタイミングイベントによって本当に影響を受ける何かを得ることができます、ハードウェアのバグは、多くの場合、プロトタイプの例のようになります。その後、バグは断続的にしか表示されません。並列処理の場合と同様に、注意深く設計することでソリューションを制約して、どのプロセッサーが偶然に速くなるかを独立させない限り、ブルームーンで1回だけ発生するバグが発生する可能性があり、その統計的な問題によりデバッグは悪夢になります。
また、コードは通常毎日数回更新されており、南に移動したときの正確なソースコードリビジョン番号を追跡することは、デバッグ作業に非常に役立つ情報です。テスターは、デバッガーや開発者と敵対的な関係にあるべきではありません。彼は、製品の品質を向上させるためにチームの一部としてそこにいます。
再現できない2種類のバグがあります。
1）テスター（またはユーザー）が一度見たことがあるが、再現できなかったか、再現しようとしたことがない人。
これらの状況では、次のことを行う必要があります。
欠陥を示した基本的なアクションの流れを非常に簡単にチェックして、再現性がないことを確認します。
テスターまたはユーザーに話しかけて、役立つ他の情報があるかどうかを確認します。
複数のインスタンスに基づいて調査するのに十分な情報があるかどうかを確認するために関連している可能性のある他の欠陥とそれらを相互参照します。この1つの問題だけでは十分な情報が得られない場合がありますが、他の多くの問題と組み合わせると、調査する価値のある正しくないことが示唆される場合があります。
それでも先に進むのに十分でない場合は、十分な情報がないことをユーザーまたはテスターに説明する必要があります。十分な情報がどのようになり、なぜ必要なのかを丁寧に説明します。
2）確実に再現できないものの、欠陥が存在することを示唆する十分な証拠（繰り返し発生に関して）がある場合、これらは開発者の問題であり、開発者-テスターによってサポートされていることがわかります/ユーザー-調査する必要があります。
これは遅くて痛みを伴う可能性が高く、コードを調べてログを追加し、データを調べてテスター/ユーザーに詳細に話す必要がありますが、それがある可能性が高いことを示唆する十分な証拠がある場合あなたはそれの所有権を取得し、それを修正するために必要なことを何でもする必要がある問題です。
これは比較的頻繁に発生するようですが、これは、ほとんどのバグが本当に再現するのが難しいためなのでしょうか、それとも彼が試みていない他の理由によるのでしょうか？ なぜ彼が問題を再現しようとしていないのか知っていますか？それはあなたにとってそれがどれほど重要であるかを理解していないからですか？それとも、彼は他のプレッシャーを持っているのでしょうか-たとえば、割り当てられたテストをすぐに通過してバグを壁に投げつけたいだけのテストマネージャーですか？それとも、どうすればいいのかわからないのでは？
より良いロギングに取り組むことが優先事項であると私は他の人に同意します。それまでの間、テスターのスキルや自信の欠如が問題であると思われる場合は、私はこの記事を本当に気に入っています バグの分離に関するDanny Faught -最初に彼を指摘することができます。
問題が経営陣の圧力によるものであることが判明した場合-特にテスターとプログラマーが別のマネージャーに報告し、マネージャーが別のチームを「手助け」する傾向がない場合は、それはクラックするのが難しいので、私の同情があります。
このテスターのワークステーションにキーロガーを貼り付けてください！
さて、最初のタスクは再現可能なテストシステムを用意することです。あなたのテスターmustは明確に定義されたプロセスを持っています-可能であれば自動的に。
次の3つの条件があります。
- 同じバイナリ
- 同じ手順
- 同じ機械
上記の3つの条件でバグが散発的に発生する場合は、さらに分離を開始します。システムスタックの各レベルとその構成を検討します。
メモリ管理エラーを検出する1つの方法は、複数のコンパイラを備えた複数のOS上でプログラムを実行することです。 Valgrindも役立ちます。
ただし、通常、並列システムは非再現バグを引き起こす傾向があります。バッファサイズと処理速度、非同期io、データベースロック、可変メモリ書き込みインターリーブなど。これらすべてが問題を生成する可能性があります。などなど。
通常、再現性はありませんが、テストまたは反復のバッチが完了するまで開いたままにしておきます。
その時点までに再生されていない場合は閉じられますが、再び遭遇した場合は再び開くことができます。
まず、厳密なテスト手順を用意する必要があります（ただし、私の会社では、あなたが説明したことが頻繁に発生します）。
バグの重大度に応じて、ある程度の時間を費やすか、再現ステップが提供されるまで（より良い）無視することができます。