誰かにテストを依頼する前に、テストの要件を満たしていることを確認してください。少なくとも次のものが必要です。
仕様: アプリケーションが何をすべきかについての信頼できる情報源。これは、アプリが何をすべきかについてのあらゆる質問に正確に答えることができる専門家である可能性がありますが、より多くのことが書き留められ、より正式に定義されているほど良い.
時間: テストには時間がかかります。本番稼働の 30 分前にアプリケーションをテスターに引き渡し、価値のある結果を期待することはできません。ウォーターフォール開発を行っている場合、最後のテストには多くの時間が必要になります。他の多くの開発モデルでは、テストを開発と並行して実行できるため、多くの時間を節約できますが、使用するモデルに関係なく、テストはテストしないよりも多くの時間を必要とします。
この 2 つがなければ、品質保証は単なる夢物語です。
これらが満たされ、誰かをテストするように訓練しようとしている場合は、テストに関する私の集中コースを次に示します。
基本的に、アプリケーションをテストするということは、次の 2 つのことを確認しようとしていることを意味します。
プログラムは、本来あるべきことを実行します。
プログラムは、本来すべきでないことを行いません。
それが私が使っている基本的な考え方です。そこから構築して、私は行動の観点から物事に取り組み、検証しようとします:
- 期待される前提条件を備えた期待されるアクションは、期待される効果を生み出します。
- 予想外の前提条件を伴う予想されるアクションは、効果がないか、適切に処理されます。
- 予期しないアクションが影響を与えないか、適切に処理されます。
- 予期しない影響は発生しません。
項目 1 は仕様から直接引用されています。プログラムが本来の動作を確実に実行するようにします。
項目 2 と 3 は、テストの技術の出番です。どのような予期しないアクションと前提条件を実行できますか? 間違ったパスワードを入力しようとする可能性があります。セキュリティで保護されていると思われるページの URL を直接入力してみることもできます。奇妙な Unicode 文字をテキスト フィールドに貼り付けることができました。SQL または JavaScript コードをテキスト フィールドに入力することもできます。
項目 4 はテストの無限の無人地帯であり、完全なテストを不可能にする部分です。(2 と 3 も無限ですが、考えるほど憂鬱ではありません。)だからといって、それを無視しているわけではありません。あなたはいつも異常なことに目を光らせています。また、ひらめきがひらめき、思いがけない効果をもたらす方法を思いつくこともあります。私は管理者です。」技術的な知識とブラック ボックスの内部をのぞくことが、そのようなシナリオを考え出すのに役立ちます。
テストについてはまだまだ言いたいことがたくさんありますが、私が考えることができる最低限のものは次のとおりです。技術的な要件と問題へのアプローチです。