回答

質問の歴史:

ソフトウェアの複雑さが増すにつれて、バグの一部はテストケースや仕様の枠を超えて初めて発見されることがある—しばしばこれらのバグは実際のユーザーにとって最も重要なものである。このような欠陥を見つけるために、テスト担当者は特別な技術を使用し、標準的なテストと自身の経験を組み合わせる。

問題:

コンポーネント間の相互作用、明白でない状況の不適切な処理、または要求の欠如に関連する隠れたバグは、最も発見および記録が難しい。しばしば、テスト担当者は「要件に記載されていない」問題を文書化するべきかどうか確信を持てない。

解決策:

探索的テスト法、ペアテスト、類似の製品への経験を使用する。このようなバグは常に最大限に詳細に文書化してください: ステップ、観察、なぜそれが欠陥だと考えるのか、関連する要求や受け入れられた論理へのリンク。

重要な特徴:

• 自発性と批判的思考が必要。
• なぜこれが欠陥であるのかを論じることが重要。
• 場合によっては、アナリストやPOとの議論に参加する必要がある。

陷りやすい質問。

要求に記載されていないバグを文書化せず無視してもよいですか？

いいえ、正確な要求へのリンクがなくても常に報告してください、さもないと重要な問題がクライアントに届くことになります。

ユーザーの不便さはバグそれとも改善（フィーチャーリクエスト）ですか？

動作が明らかに論理的でない、混乱を引き起こす、またはリスクを引き起こす場合はバグとして記録し、そうでなければ改善として記録してください。

テスト担当者は明白でないバグごとにチームに相談するべきですか？

議論の余地のあるケースについては、アナリストや開発者と事前に話し合うことが推奨され、意味のないチケットを避けることができます。

一般的な誤りとアンチパターン

• 要求に文書化されていないユーザーにとって明白な欠陥を無視すること。
• 隠れたバグの文書化が弱いまたは不完全であること。
• バグ報告に対する論拠の欠如。

実生活の例

ネガティブケース

テスト担当者は、2つのウィンドウを同時に開くとシステムがハングすることに気づいたが、そのシナリオが要求とテストケースに記載されていなかったため、バグを記録しなかった。

利点:

• "余分な"バグを追加しなかったため、開発者の他のタスクのために余裕ができた。

欠点:

• システムは重大な脆弱性を伴ってリリースされ、クライアントに影響が出た。

ポジティブケース

テスト担当者は、ステップ（2つのウィンドウを開く、アクションのシーケンス）を説明し、スクリーンショットを添付し、なぜこれがバグだと考えるのかを説明してバグを文書化した（実際のユーザーがこの状況に遭遇する可能性があるため）。

利点:

• バグは迅速に修正され、最終ユーザーは問題に直面しなかった。

欠点:

• アナリストとのシナリオの議論に時間がかかった。