テスト計画書にテスト範囲を書く時に気を付けたいこと

1.テスト範囲はどこまで記載するか
テスト範囲の認識がズレていたことで失敗したプロジェクトを数多く見てきました。

なぜ、認識がズレるのでしょうか?

それは、曖昧な記述のまま進めてしまうからです。
例えば、会員登録機能のテストをする場合、

悪い例)
テスト対象機能:
・会員登録機能

良い例)
テスト対象機能:
・会員登録機能

テスト対象画面:
・会員情報入力画面
・会員情報入力内容確認画面
・会員登録完了画面

テスト概要
・新規登録
・既存会員情報変更
・会員退会

いかがでしょうか。
悪い例では、会員登録機能が何処までの範囲かが不明確ですが、良い例の方は会員登録機能の確認範囲は「会員情報入力画面」「会員情報入力内容確認画面」「会員登録完了画面」であり、「新規登録」「既存会員情報変更」「会員退会」処理を確認することが明確です。

この様に記載することで、「会員登録機能はユーザ側の画面だけてなくて、管理者画面側もテストして欲しい」など、認識のズレを事前に解消することができます。

悪い例では、計画書記載者は会員登録機能は「ユーザ側の画面だけがテスト範囲」と思っていて、計画書承認者は「管理者画面も範囲に含まれている」と思ったまま進んでしまい、後で問題となるのです。

2.テスト範囲の具体例
・対象機能
・対象画面
・テスト概要

を明確に記載する

例)会員登録機能の場合
テスト対象機能:
・会員登録機能

テスト対象画面:
・会員情報入力画面
・会員情報入力内容確認画面
・会員登録完了画面

テスト概要:
・新規登録
・既存会員情報変更
・会員退会

広告

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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