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

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

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

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

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

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

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

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

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

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

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

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

を明確に記載する

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

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

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

テスト計画書に参考資料を明示する本当の理由

1.参考資料を記載することのメリット
私は、自分がテスト計画書を作成する時はもちろんですが、部下の作成したテスト計画書をレビューするときにも、参考資料の記載有無については必ずチェックしています。

チェックする理由のひとつは、何を根拠にテスト計画を立てているのか、テスト計画内容の妥当性評価のためです。

しかし、参考資料を記載する本当の理由はチェックのためではなく、他にあります。

それは、参考資料を明記することで、計画書の承認者に対して、

「この程度の概要資料を基に計画を立てているので、詳細資料が出てくれば、計画変更が発生する可能性が高いですよ。」

とか

「ここまで、詳細な資料の内容を確認したうえでの計画ですので、計画の精度は高いですよ。」

といったことをアピールするためです。

アピールすることで、例えば、当初のテスト計画を変更しなければならなくなった時などの交渉がスムーズに進みます。

「テスト計画時に参考にしていた資料に変更が入ったので、計画も変更します。」
といった具合です。

つまり、参考資料を記載することでテスト計画変更時に、明確な根拠を示しやすくなります。

2.参考資料の具体例
・○○画面仕様書 ver.1.01
→バージョンの記載まですることがポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

意外と知らない?テスト計画書に記載すべき9つの項目

これから書く項目がテスト計画時に定義されていなかった(検討されていなかった)ために、炎上してしまったプロジェクトをよく見かけました。

「何で定義しなかったの?」と担当PLに聞きましたが、「定義が必要だと思っていなかった。。」といった答えが返ってきたので、意外と重要だと気付かれていない項目もあるかもしれない。と思い、まとめてみることにしました。

※以下結合テスト、システムテストの機能テストフェーズのテスト計画書に記載することを前提にしています。

1.テストの種類と目的
大体のテスト計画書には「どのようなテストをするか」は記載されているのですが、「何を目的としたテストなのか」を明記していないテスト計画書をたまに見かけます。

大切なのは、目的を明確化し、ステークホルダー間で「今回のテストは大体このような内容のテストをするのだな」という認識をあわせる事です。

2.参考資料
今回のテスト計画を立てるにあたって、どのような資料を参考にしたのかを記載します。

例えば、外部仕様書や画面遷移図などが該当します。

参考資料を記載することで、「どの程度の資料を基に立てられた計画なのか」を示すことができます。
テスト計画書を見る人も、「RFPと画面遷移図から立てた計画だから、概算のテスト計画だろう」といった具合に計画の精度を予測することができるようになります。

3.テストの範囲
今回ご紹介している項目の中でも、かなり重要な項目です。
これが明確に記載出来ていないことで、炎上しているプロジェクトを良く見かけます。

テスト計画書を作成したテスト担当者は明確に記載しているつもりでも、開発側や、PMと認識がズレていたことで、「その範囲までテストが必要とは思っていなかった。。」とか「テスト計画書のレビューの時には何も指摘はなかった。」など大きな問題に発展するケースもあります。

4.テストの粒度
この項目も、先程のテスト範囲と並んでかなりの重要項目です。

テスト範囲同様、認識の違いが発生しやすく、また認識相違による手戻りはテスト工数へ大きな影響が生じます。

5.テスト対象環境
テスト計画時に確定していることが少ないため、後回しにされやすく、そのままテスト開始間際まで忘れられてしまうことが多い項目です。

テスト工程直前になって、「サーバに接続出来ない」とか「実機が足りない」といったことも、この項目を明記していなかったことで発生しやすいトラブル内容です。

ここからの項目は、必ずテスト計画工程で定義しなければならないといった項目ではないのですが、失敗プロジェクトでは最後まで定義せずに進めていることが多々あるため、テスト計画時に明確化することをお勧めします。

6.テスト実施者入力項目
テストケースを実施する際に実施者が記入する項目の定義です。

テスト開始前まで決まっていなかったり、テスト開始後に「そういえば、この項目もいるかもしれない」となりがちです。

テスト実施後に、「あのテストは、どの環境で実施しましたか?」と聞かれた時に回答に困らないように、記載が必要な項目は事前に決めて合意を取っておきましょう。

7.テスト判定項目
テスト実施時の判定に使う項目の定義です。
例えば「OK」や「NG」などの定義はわかりやすいですが、「保留」という判定結果を使用しているときなどは、認識に相違が発生しないように定義を共有することが必要です。

8.BTS(バグトラッキングシステム)で使用する項目
後々に障害(バグ)分析する際に使用するための項目を定義します。
テスト開始前までに定義しておかなければ後で変更ができないため、最初に「BTSで入力する、この項目はこういった分析で使用します」といったところを見せ、他に分析したい内容がないかを確認しておきましょう。

9.進捗管理指標
テストの進捗分析に使用する項目を定義します。
これも、先程のBTS項目と同様に事前に他に分析したい内容がないかを確認しておきましょう。

ここまではどのような項目が必要かという説明をしましたが、次回は具体的に私が使用してきた項目例をご紹介します。