QAは再現可能なシナリオを見つける必要がありますか？
私のQAチームがバグを報告することがありますが、私も彼らもそれらを再現する方法について何の考えも持っていません。これにより、非常に長くてイライラするデバッグセッションが発生し、結果が得られない場合もあります。
私のソフトウェアは専有のハードウェアと深く結びついているので、バグは一度に多くの方向から発生する可能性があります。
「ボタンを押したときにソフトウェアがクラッシュした」以上のことを期待するべきでしょうか、それとも何が起こったのかを理解する必要がありますか？
編集：
私の同僚の1人は、おそらくここではすべての開発者であるため、結果には少しバイアスがかかる可能性があると指摘しました
QAは常に、バグをできるだけ簡単に再現できるようにして、バグの説明に実行した手順を含める必要があります。
ただし、バグを簡単に再現できない場合でも、適切なタイトル/見出しと、バグの原因となった動作の詳細な説明を含めて、バグデータベースに入力する必要があります。バグの説明には、バグを再現できないことを明記する必要があります（おそらく「5回試したが、1回発生した」というコメントが付いている）。このようにして、誰かが同じバグを見つけた場合、彼らはバグデータベースにその発見を追加することができます。また、できるだけ多くの情報を得ることができるため、問題を追跡する時間を節約するのに重要です。
また、情報をフィルタリングすることもできます-さまざまなシステムで、コードの1つの領域（たとえば）にすべてリンクしていることがわかっている多くのバグがある可能性があります-QAが何も報告しない場合（再現できないため） ）その後、この情報はあなたに届きません。
QA部門が探索的テストを過剰に実行しているようです（つまり、テスト計画が不十分です）。
探索的テストは適切であり、問題領域を特定しますが、そこから、特定のバグを明らかにするために実行可能な再現可能なテストケース（つまり、テスト計画）を定義する必要があります。
正しい再現が必要な理由はいくつかあります（良いだけでなく、必要です）。
- 原因をデバッグ/追跡できるように再現する必要があります。
- 完了したら、QAで修正を確認できる必要があります。
- さらなるテストに合格するには、以前のバグのリグレッションを行う必要があります。
- 既知のバグは、露出が小さすぎる場合や再現が非常に可能性が低い場合は破棄できます。
それで、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に、可能な場合はバグを再現する手順を含める必要がある場合、答えは「はい」です。もし彼らが再現できるバグだけを記録すべきだとしたら、絶対にそうではありません。バグはバグであり、満月の真夜中にのみ発生するか、またはそれを見るたびに発生します。一部のバグは非決定的であり（古典的な例は初期化されていない変数であり、取得される値は半ランダムです）、それはそれらが記録、調査、および可能であれば修正されるべきではないという意味ではありません。
再現性のないバグの優先度は一般的に低くなりますが、確実に記録する必要があります。
バグレポートには以下を含める必要があります：
- 再現する手順
- 実際の行動
- 予想される動作
例えば。：
- データベースからすべてのサプライヤーを削除し（
DELETE * FROM tSuppliersを使用）、サプライヤーダイアログを開き、サプライヤードロップダウンリストをクリックしました。 - リストには次のメッセージが含まれています：
GUPOS ERROR #0000000: SOMETHING WENT WRONG!。メッセージをクリックすると、アプリが画面とタスクマネージャーから消えました。 - 空のリストか、（できれば）「サプライヤが見つかりません」などのメッセージが表示されることを期待していました。空のリストまたはメッセージをクリックしても何も起こりません。アプリは明らかに、いかなる状況でも警告なしに消えてはいけません。
だから、はい-再現する手順が含まれているはずです。これを含める必要性を感じていないという事実は、障害を特定するのではなく、「ソフトウェアを壊す」ことが自分の仕事だと考えていることを示しているように思われます。
IMO、そうすべきです。 QAが再現手順を提供できない場合、QAは仕事をしていません。再現できないものを再現しようとする時間を無駄にせず、単に「再現できない」と閉じて次に進んでください。
あなたの時間はそれよりはるかに貴重です。
お金はここで危機に瀕しています。なぜチームメンバーは、（うまくいけば）高給の開発者に負担をかける、明確に定義されていない、成功率の低いタスクを作成できるはずですか？
これは、序列、階層、傲慢さ、私たち対彼ら、またはそのような何かをつつくことについてではありません。これは、製品に付加価値を与える活動に投資することです。
問題が製品の価値に悪影響を及ぼし、測定可能な程度に影響を与えることがわかった場合は、調査、再現、および修正する必要があります。製品の欠陥パイプラインを修正して、ノイズを除去します。
QAは、入力された手順に基づいてバグを再現できるはずです。懸命に努力しても再現できない場合は、開発者がアプリケーションとデバッグログで詳細を確認できるように、タイムスタンプと同じくらい詳細にバグを入力する必要があります。