要件テストは手動テストの重要な段階であり、この段階での不備は将来の高額なエラーを引き起こす可能性があります。
問題の歴史:
開発の初期段階では、製品の要件が文書（技術仕様書、仕様書）として固定されます。これらの不適切または不完全な形式は、実装とテストの段階で多くの問題を引き起こします。
問題:
要件が不完全、曖昧、または矛盾していることがよくあります。これにより解釈の相違や製品の品質が低下します。テスターはこのような点を事前に特定する必要があります。
解決策:
要件の手動テストには以下が含まれます。
主な特徴:
「要件がテスト可能である」とは何を意味しますか？
テスト可能な要件とは、製品でそれが満たされているかどうかを正確に言える要件のことです。抽象的な表現、一般的なフレーズ、不明確なパラメータは許可されません。
要件が作成者だけに理解される場合、それらは質が高いと見なすことができますか？
いいえ。質の高い要件は、すべてのチームメンバー（開発者、テスター、アナリスト、ビジネス）によって明確に理解されなければなりません。
テスターの義務に要件を補足または修正することが含まれますか？
いいえ、テスターは問題を特定し、責任のある人に報告しますが、自分で要件を書き直してはいけません。
テスターは要件を受け取り、完全性と一貫性を確認せず、曖昧な表現に注意を払わなかった。その結果、開発者たちはこれらの要件を異なって解釈し、リリース時に発覚した未考慮のシナリオが発生した。
利点:
欠点:
要件を理解する段階で、テスターはビジネスアナリストのための質問を作成し、議論のある点を明確にし、ネガティブシナリオを追加する手助けをした。これにより、多くの解釈の相違を回避し、リリース時のバグの数を大幅に減少させることができた。
利点:
欠点: