誰かが問題を見つけたときに、正確で詳細な再現手順が必要なのはまったく問題ありません。ただし、そのようにテスト計画を作成すると、次の問題が発生する危険があります。
1)不注意な盲目- 私は、人々が詳細な手順テスト スクリプトを実行し、忠実に実行し、すべてのステップを細心の注意を払って記録し、目の前にある明白なエラーを完全に見逃しているのを見てきました。「台本になかった」からです。彼らの注意は、すべての面倒なテスト手順に集中していたため、目の前の問題を文字通り見ることができませんでした。
2) 非常に詳細で非常に具体的なパスから一歩外れたバグをすべて見逃してしまいます。顧客があなたの製品を手にしたとき、彼らは詳細なテスト計画に従わないでしょう。彼らはさまざまな方法でアプリ内を移動します。彼らは考えを変えるでしょう。それらの名前は、あなたが考えていた、または可能だと思っていたよりも長く、または短くなります。彼らはトランザクションの途中でそれを放棄します。彼らはさまよいます。彼らは一つの道に固執しません。そして、誰かがテストを繰り返すたびに、それらのバグを再び見逃すことになります。
3) 「誰でもこれに従うことができる」テスト スクリプトを作成するために、信じられないほど長い時間を費やすことになります。信じてください、私はこれを完成させるために何年も費やしましたが、それは人間には不可能です. さらに悪いことに、これをしようとして浪費する時間は、他の方法ではるかに有益に費やされる可能性があるため、製品は悪化します.
4) 何度も繰り返すことになり、すべてを読まないとテストのポイントを理解するのが難しくなります。テストをすばやくスキャンして、見逃した可能性のあるユースケースを確認するのは簡単ではありません。
テスト計画を広く保ち、テストを行う人々が判断できるようにします。テストする必要がある特定の使用シナリオ、またはターゲット ユーザー グループがどのように動作するかについての情報がある場合は、これをテスト計画と共にテスターに提供します。ユースケースの形。特定の事項にチェックを入れる必要がある場合は、チェックリストの使用を検討してください。(詳細については、Cem Kaner の優れたプレゼンテーション
www.kaner.com/pdfs/ValueOfChecklists.pdfを参照してください)。
または、テスト計画を短い探索的チャーターとして記述します。たとえば、次のようなガイダンスを提供できます。「コールセンターのユーザーは、マウスが接続されていないワークステーションを使用します。キーボード ショートカットのみを使用してすべてのアクティビティを完了できることを確認して、顧客に代わってチケットを上げるプロセスを調べてください。」これは、「フィールド 1 にタブで移動します。「回線品質に関する苦情」と入力します。フィールド 2 にタブで移動します。ドロップダウン メニューから [電話] を選択します。フィールドにタブで移動します」と言うよりも、テスターが欠陥を見つける可能性がはるかに高くなります。 68.」