テスト目的を記載すべき、たった1つの理由

1.なぜ、テスト目的を記載しなければならないのか
テストの目的が明確化されていなかったことで問題を事前にキャッチすることができた、あるWEBアプリのテストプロジェクトの実例をご紹介します。

私が参画したそのプロジェクトは、アプリの規模に比べるとテストケースの件数が多かったため、私は、「何か変だな」と思いテスト計画書を確認しました。

しかし、テスト計画書にテスト範囲などは記載されているのですが、肝心の計画しているテストの種類や目的が記載されていませんでした。

そこで前任のテスト担当者に「思ったよりテストケースの件数が多いけど、このテストの目的は何かな?」と確認したところ、「う〜ん。。PMに言われたので作りました。」という返答でした。

そこで、再度PMに今回のテストプロジェクトで目指している品質目標を確認し、その目標を達成するための「テストの種類」「テスト目的」を整理し直したことで、もともと作成していたテストケースの半分以上は不要なテストケースでした。

さらに、不足していたテストにも気付くことができ大事に至る前に対処することができたのです。

つまり、テスト目的を明確にすることで、テストの効率化効果的なテストを実施することができました。

2.テスト目的の具体例
私はいつも4種類のテストでプロダクトの品質目標を達成するようにテスト目的を設定しています。
目的と書いていますが、私が記載するときは、テスト目的とテスト概要の中間くらいの粒度で記載するように注意しています。

目的だけですと、抽象的すぎてイメージが伝わらないことがたるためです。

※結合テスト・システムテストでの例です。

■テストの種類例
・表示テスト
UI上に表示される文言やリンク遷移など、静的表示項目に対するテスト。

・入力テスト
バリデーションチェックなど、ユーザ入力項目に対するテスト。

・機能テスト
組み合わせ条件での動作など、条件分岐に対するテスト。

・シナリオテスト
ユースケースなど、実運用に対するテスト。

■テスト目的例
・表示テスト
→文言内容、リンク遷移先が仕様書と相違ないことを確認する。
また、使用想定ユーザが違和感なく使用できるUIであることも確認する。

・入力テスト
→異常系処理においてシステムが異常(システムエラーなど)にならないことを確認する。

・機能テスト
→既存機能箇所については、正常代表値で確認、異常系処理については、全条件で確認する。

・シナリオテスト
→ユースケースを通して、既存Verのレスポンス速度に比べ20%の速度改善が満たされていることを確認する。

上記目的は、プロダクトの品質目標によって変わるものです。

テスト目的の策定でお悩みの方は、お気軽にコメント欄でご連絡ください。

可能な限りお答えいたします。