0. 要約

テスト計画では、プロジェクト全体の各テスト工程のタイミングや方法を計画します。
アプリケーション、開発者、お客様（企画）の特徴によって最適な方法は異なるため、それらの情報を収集したうえで、計画を建てる必要があります。そのため、情報収集をしたうえで草稿を作成し、他者レビューで抜け漏れをなくすことが重要です。さらに、ソフトウェア開発では、想定していなかった技術的な問題や仕様の矛盾、技術以外のトラブル（例、開発メンバーの休職）が発生し、状況が変化することがあります。そのため、継続的な計画の見直しを行うことが重要です。

1. 作成例

図書館の蔵書検索システムをイメージして、テスト計画の例を作成してみました。是非、参考にしてみてください!

2. テスト計画とは

• テスト方針やテスト戦略の明示
• 成果物に求められる品質基準の設定
• 品質基準を満たすための具体的なテスト方法の明示
• チームメンバーやその他のステークホルダー間の認識共有

ISTQBが示したガイダンスを基に、私の考えを加えたものです。（ISTQB 原文）

3. 計画作成手順

1. 情報収集
2. 草稿作成
3. レビュー
4. 更新

情報収集

まずは、製品やプロジェクト、stakeholderに関する情報を集めます。
ここで一から情報を集めるというよりは、それ以前の聞き取りや要件定義、設計の情報を再度整理し、不足や更新された情報があれば、それを埋めます。

アプリやプロジェクト毎に求められているものは違うため、この段階でプロジェクトの特徴を明らかにすることが、最適なテスト計画の作成や開発工程全体に寄与します

以下、主な情報の例です。
まずは重要な情報を抑え、不足している箇所はその後の工程で都度収集・反映すると時間をかけすぎずに済みます。

• ステークホルダー
• お客様（ビジネスの目的や目標、システムへの要望、システム開発やITへの知識等）
• ユーザー（目的、年齢、国籍、社員/一般ユーザー等）
• 開発者（技術、知識、経験等）
• 業界（文化や特徴、対応が必要な法律等）
• 製品（機能の重要度、applicationの種類、外部連携の有無等）
• プロジェクトの制約（人員、納期、予算等）

草稿作成

必要な情報が集まり次第、下書きを作成します。任意のテンプレートを用意し、整理した情報を基に各項目を埋めていきます。テンプレートはネット、AI、他のプロジェクト、どれでも大丈夫です（もちろん冒頭で私が配布したものでも）。書いていくうちにあまり筆が進まなかったり、逆に書きたいことがあふれる項目が出てきます。埋まらない部分は削除、あふれている場所はさらに見出しや項目を増やすことで、プロジェクトに最適なテスト計画へとなっていきます。

ここではとにかく書き始めることが重要で、どんどん自己 及び 他者レビューをしていきましょう。開発者やお客様毎に見え方も異なるため、一人じゃ気づけないことがたくさんあるはずです。

レビュー

草稿が作成でき次第、自己レビュー 及び 他者レビューをしていきます。他者レビューは以下の順番で行うことがおすすめです。

• お客様
• チーム全体
• チームリーダー
• 自分より開発経験とQA経験が豊富な人

最初は自分より経験や知識が豊富、またはプロジェクト全体が見えている人に、基本的な情報の抜け漏れや誤り、各工程の目的を対象にレビューをしていただくことをお勧めします。基本的な部分は影響範囲が大きく、細部まで検討した状態で前提がひっくり返ることを避けるためです。
基本的な部分が固まったら、具体的な手法やデータ、を決めていきます。

お客様とは、テスト計画全体と、特に受入テストの具体的な進め方やテスト環境（テストデータや外部システム等）について相談をすることになると思います。
お客様によって、システムや開発への理解度や知識が異なるため、情報の粒度や説明方法はその時にあった方法でお伝えすることが重要になります。

更新

開発メンバーやお客様のレビューを通過すると、プロジェクトに最適化されたテスト計画が出来上がります。

しかし、この段階でも、

• 一部機能の仕様が未確定
• 担当者は仮決めで進捗次第では他担当者に回す

といった状況はよくあります。そのため、未確定部分は保留として扱い、
まずは初稿として前に進めることをお勧めします。
但し、情報が得られ次第、更新は行ってください。

また、テスト計画で網羅できなかった部分は、都度別の資料で補うようにしてください。
例えば、実装初期段階で単体テストの認識を揃えると思いますが、それはwiki等に書くようにし、テスト計画には書かないようにしてください。（以下例）

対象

Serviceフォルダ、Helperフォルダ内のメソッドを対象とする
単体テストが入っていない場合はその理由をTODOコメントで記載すること

環境

～～～

4. テスト計画に必要な項目

5. よくある失敗

1. 実態との乖離が大きい or 不明瞭で実現できない

私が以前テスト計画を作成した際、全てのテスト工程で「カバレッジ100%を基本とする」としました。しかし、実際に進めてみると、システムテストでは全く時間が足りず、単体テストでは、そもそもどこまでが100%カバレッジなんだ、という疑問にぶつかりました。

もし今立てるのであれば、優先度を目安とします（例、P1のテストケースは必ず通すこと）。そのうえで、テストケース作成の認識を揃えるために、テスト技法の紹介とカバレッジについて言及します。

そのため、テスト計画者はできるだけ実際に進めることを思い浮かべることが必要で、一方、レビュアーは、計画に書かれていることは具体的に何をどうすることを指すのか、を思い浮かべることが必要です。

2. 計画を参照しない

例えば、テスト計画では、「単体テストは実装フェーズで行うこととし、目的はビジネスロジックの品質を担保すること」とします。しかし、いざ実装してみると時間が足りず、少しでも時間を捻出しようと単体テストは任意とする、方針に変更し、その後のシステムテストでもバグは発生しませんでした。

そもそも複雑な機能ではなかったからよし、ともとれますが、個人的にはプロジェクトが計画から外れ始めている合図だと思います。計画は絶対ではないですし、柔軟性を持つことは開発において不可欠です。

しかし、ただ柔軟性を持たせるよりも、計画を認識したうえで例外として扱う、または計画を修正する方が、最終的には良いシステムができるように思います。

3. リスク対策を言及しない

遅れが出た際にはリソースを追加するだけが対策ではありません。今まではWebだったけど、初めてモバイルで開発する、お客さんの繁忙期は質問の回答に時間がかかる、こともリスクで、それらは進め方を工夫すれば、リソースをかけずに対処することができます。

そんなことは特に文書に書かなくてもわかる、と思うかもしれませんが、テスト計画の目的の一つは認識共有です。もしかしたら、Webとモバイルの違いをそれほど大きく受け止めておらず、いつも通りでバッファを計算する人がいるかもしれません。

6. まとめ

• プロジェクトの状況に基づいて方針を策定し、認識を揃えたうえで安心してプロジェクトを進めることが目的です。
• 最適なテスト計画は、プロジェクトによって異なります。
• 情報収集→記載→レビューを続けることで、プロジェクトに最適なテスト計画を作成することができます。