時々、私のQAチームはバグを報告しますが、私も彼らもそれらを再現する方法について何の考えも持っていません。これにより、非常に長くてイライラするデバッグセッションが発生し、結果が得られない場合もあります。

私のソフトウェアは専有のハードウェアと強く結びついているので、バグは一度に多くの方向から発生する可能性があります。

「ボタンを押したときにソフトウェアがクラッシュした」以上のことを期待するべきでしょうか、それとも自分で何が起こったのかを理解する必要がありますか？

編集：

私の同僚の1人は、おそらくここではすべての開発者であるため、結果には少しバイアスがかかる可能性があると指摘しました

QAは常にバグをできるだけ簡単に再現できるようにして、バグの説明に実行した手順を含める必要があります。

ただし、バグを簡単に再現できない場合でも、適切なタイトル/見出しと、バグの原因となった動作の詳細な説明を含めて、バグデータベースに入力する必要があります。バグの説明には、バグを再現できないことを明記する必要があります（おそらく「5回試したが、1回発生した」というコメントが付いている）。このようにして、誰かが同じバグを見つけた場合、彼らはバグデータベースにその発見を追加することができます。また、できるだけ多くの情報を得ることができるため、問題を追跡する時間を節約するのに重要です。

また、情報をフィルタリングすることもできます。さまざまなシステムには、コードの1つの領域（たとえば）にすべてリンクしていることがわかっているバグがたくさんある可能性があります-QAが何も報告しない場合（再現できないため） ）その後、この情報はあなたに届きません。

QA部門が探索的テストを実行しすぎているようです（つまり、テスト計画が不十分です）。

探索的テストは適切であり、問​​題領域を特定しますが、そこから特定のバグを明らかにするために実行可能なテストケース（テスト計画）を定義する必要があります。

正しい再現が必要な理由はいくつかあります（良いだけでなく、必要です）。

1. 原因をデバッグ/追跡できるように再現する必要があります。
2. 完了したら、QAで修正を確認できる必要があります。
3. さらなるテストに合格するには、以前のバグの回帰を行う必要があります。
4. 既知のバグは、露出が小さすぎる場合や再現が非常に可能性が低い場合は破棄できます。

それで、SteveCzettyが指摘するように：再現なしとして閉じて、作業に戻ります。

バグを一貫して再現できない場合、QAはそれが修正されたかどうかをどのようにして知るのでしょうか？

はい、あなたは彼らにもっと期待するべきです。彼らは言うことができるはずです：

1.プログラムの新しいインスタンスを開始しました
2.ボタンAを押した
3.フォーム＃1の[テスト名]フィールドに「テストテキスト」を入力しました
4.ボタンBを押した
5.プログラムがこのメッセージでクラッシュしたことを確認しました（添付のスクリーンショットを参照）。

彼らが言うすべてが「墜落した」なら、彼らはあまり良くありません。上記の手順が100％再現可能ではない場合でも、パターンが検出されると、これらのクラッシュの十分に大きなサンプルが原因を絞り込むのに役立つ可能性があります。

私のアドバイスは、それらのバグを読んで古き良き考えを与えることです。潜在的な原因がわからない場合は、とりあえず忘れてください。

QAは、どのようにしてそれが起こったのかわからなくても、見つけたすべての問題を文書化する必要があります。問題を試して再現するのはQAの仕事ですが、現実的には、これが常に可能であるとは限りません。場合によっては、過去10分間に行った処理とは何の関係もありません。1日前に何かが無効な状態になり、最後の10ステップの1つが原因でそれが明らかになりました。

これらの「1000分の1」のバグがある場合、QAはそれらを少し再現する必要があります。成功しない場合は、バグを文書化してから、もう少し試してください。

彼らがバグをかなり早い段階で入力する必要がある理由は、プログラマーがQAよりもはるかによくコードを知っており、すぐに問題を知っている可能性があるためです。彼らがリファクタリングしたコードである可能性があります。彼らが半分実装した機能を忘れてしまったのかもしれません。彼らには分からないかもしれませんが、テスターがコード化した人に明らかな問題を再現しようとして数時間を浪費するのは意味がありません。テスターはいつでもバグにいつでも詳細を追加できます。

バグにはできるだけ多くの情報を含める必要があります。テスターが問題の原因について覚えていることは何でも、苦痛な詳細に書き留めるべきです。クラッシュログ、データベーススナップショット、または関連するスクリーンショットも添付する必要があります。

バグが再現されない場合は、すばらしいです。データベースに登録しても問題ありません。プログラムがリリースされ、ユーザーが後で同様のバグを報告した場合、彼らの経験をレポートの内容と比較し、類似点を探すことができます。

私の経験では、最もジューシーなバグは、以下のテスト計画では見つかりません。時々、月と星を整列させて厄介なバグを引き起こすために、物事を数週間煮込む必要があります。QAが探偵の仕事をして、いくつかの考えられる原因を見つけることができる場合は、彼らに背中を軽くたたいてください。しかし、何が起こったのか誰が知っているのでしょうか？

多くのバグは、修正方法を理解するまで再現できません。これは、修正する必要がないという意味ではありません。昨年、まだ再現方法がわからないバグを修正しました。正確なタイミングの送信エラーと、スタック上の特定のメモリ位置にある非常に特定のガベージデータの奇妙な組み合わせが必要です。残念ながら、私たちの顧客の1人は、常にその状態に入るのに十分「幸運」です。

したがって、可能な場合は必ず再現性ステップをQAに含めることをQAに奨励してください。場合によっては、ログを追加する場所を知るのに役立ちます。時にはそれが何がバグを引き起こしていないのかを伝えるだけですが、バグレポートは常に役に立ちます。

QAに、可能な場合はバグを再現する手順を含める必要がある場合、答えは「はい」です。もしあなたが彼らが再現できるバグだけを記録するべきだと言うなら、絶対にそうではありません。バグはバグであり、満月の真夜中にのみ発生するか、またはそれを見るたびに発生します。一部のバグは非決定的です（古典的な例は初期化されていない変数であり、取得される値は半ランダムです）。これは、それらを記録、調査、および可能であれば修正すべきではないという意味ではありません。

再現性のないバグの優先度は一般的に低くなりますが、確実に記録する必要があります。

IMO、そうすべきです。QAは、再現手順を提供できない場合、その仕事をしていません。再現できないものを再現しようとする時間を無駄にせず、単に「再現できない」と閉じて次に進んでください。

あなたの時間はそれよりはるかに貴重です。

バグレポートには以下を含める必要があります：

• 再現する手順
• 実際の行動
• 予想される動作

例えば：

• （を使用してDELETE * FROM tSuppliers）データベースからすべてのサプライヤーを削除し、サプライヤーダイアログを開いて、サプライヤードロップダウンリストをクリックしました。
• リストには次のメッセージが含まれていました：GUPOS ERROR #0000000: SOMETHING WENT WRONG!。メッセージをクリックすると、アプリが画面とタスクマネージャーから消えました。
• 空のリスト、または（できれば）「サプライヤが見つかりません」などのメッセージが表示されることを期待していました。空のリストまたはメッセージをクリックしても何も起こりません。アプリは明らかに、いかなる状況でも警告なしに消えてはいけません。

だから、はい-再現する手順が含まれているはずです。これを含める必要性を感じていないという事実は、障害を特定するのではなく、「ソフトウェアを壊す」ことが自分の仕事だと考えていることを示しているように思われます。

QAは、入力された手順に基づいてバグを再現できるはずです。開発者がアプリケーションとデバッグログで詳細を確認できるように、一生懸命試しても再現できない場合は、タイムスタンプの詳細と同じくらいバグを入力する必要があります。

ここでお金が危機に瀕している。チームメンバーが、（うまくいけば）高給の開発者に負担をかける、明確に定義されていない、成功率の低いタスクを作成できるのはなぜですか？

これは、序列、階層、傲慢さ、私たち対彼ら、またはそのような何かをつつくことについてではありません。これは、製品に付加価値を与える活動に投資することです。

問題が製品の価値に悪影響を及ぼし、測定可能な程度に影響を与えることがわかった場合は、調査、再現、および修正する必要があります。製品の欠陥パイプラインを修正して、ノイズを除去します。

あなたのQAチームは

彼らに行って、プロのテスターが頭の中で直接印刷しなければならないドキュメントを読むように彼らに伝えます（私はかつてテスターでしたが、今でも頭の中にいます）：バグを効果的に報告する方法。

特に、「自分を表示する方法を表示する」セクションを紹介してください。

これはインターネットの時代です。これは世界的なコミュニケーションの時代です。これは、ボタンを押すだけで自分のソフトウェアをロシアの誰かに送ることができる時代であり、彼は私と同じくらい簡単にそれについてのコメントを送ることができます。しかし、彼が私のプログラムに問題を抱えている場合、彼はそれが失敗している間、私がそのプログラムの前に立つことはできません。「見せて」はできればいいのですが、できないこともよくあります。

直接会うことができないプログラマにバグを報告する必要がある場合、この演習の目的は、問題を再現できるようにすることです。プログラマーがプログラムの独自のコピーを実行し、同じことをプログラムに実行し、同じように失敗させるようにします。彼らが目の前で起こっている問題を見ることができれば、彼らはそれに対処することができます...

「バグは一度に多くの方向から来る可能性がある」と不満を言うように彼らが怒鳴り始めたら、彼らがあなたが以前考えていたよりもさらに多く吸うことを彼らに伝えてください。テスト容易性は他のプロジェクト機能の中で評価する必要がある機能であり、この機能を正しくするために努力を払う必要があることを伝えます。

• プロのテスターが集中している場合に得られるテスト容易性の改善は、まるで魔法のようです。私自身、数か月前にそのことを学びました。私たちのチームと協力するQAエンジニアは、アプリケーションの一部のコンポーネント用に開発するための少数のテスト容易性リクエストをくれました。彼が尋ねたことは私にはほとんど意味がありませんでしたが、私は彼が専門家としてよりよく知っていると仮定して、彼にそれを与えました。私が終わって間もなく、彼はテストの労力を桁違いに減らすツールを思いつきました。彼のほとんどは、私が実装したこれらの不可解な要求に基づいていると言いました。