テスト計画書について　ー　全体テスト計画を語る夕べ　－

２０１９年１月３１日（木）１９時に開催しました「全体テスト計画を語る夕べ」の原稿の一部をリライトしたものです。
（２０時１５分～２０時３０分までの原稿です。当日はこの部分の解説をほとんどせずに飛ばして語ったために、ほとんど使っていません。）

目次

１．はじめに
２．全体テスト計画書とは
３．全体テスト計画書の位置づけ
４．ISO/IEC/IEEE 29119 のテスト計画書
５．現場で使われているテスト計画書
６．全体テスト計画書の内容
７．個別テスト計画書の内容
８．テスト計画を分かりやすく言い直すと
９．補足： SIer の全体テスト計画書の位置づけ
１０．ここまでのまとめ

１．はじめに

前の記事

「困ったテスト計画書」を語る夕べ（番外編）

「困ったテスト計画書」が作成される背景

この２本の記事の続きです。

対象者

前の記事にも書いていますが、対象者は全体テスト計画を策定する立場の人です。中堅～ベテランの人を対象にしています。

本記事の内容

話の流れからすると、次はテスト計画の立て方の話をするのが自然だと思うのですが、その前に全体テスト計画書の目次を確認します。全体テスト計画書の位置づけと目次を取り上げ、確認します。

２．全体テスト計画書とは

高橋寿一さんと湯本剛さんが書かれた「現場の仕事がバリバリ進む ソフトウェアテスト手法」（通称、バリ本）には、全体テスト計画書（バリ本には、マスターテストプランと書いてあります）は、次のような事柄が明らかになっているものとしています。

マスターテストプラン

・大まかなテスト範囲
・大まかなテストの仕方・分担
・大まかなテストのスケジュール
・バグ管理やテストケース管理などのテスト管理のインフラになるところのやり方
・テストリリースや変更管理の通知方法など開発とのインタフェースの取り方
・計画上のリスク

「現場の仕事がバリバリ進む ソフトウェアテスト手法」より引用

寿一さんと湯本さんが考える全体テスト計画書は、一言で表現すると「大まかな」ものですね。とにかく大まかなもの。

テストには静的テストとしてレビューを含める考えがあります。ある組織では、Ｗモデルを標準にしていたので、レビューもテストも区別せずに、全体テスト計画書を作成していました。

Ｗモデルを採用していない場合、全体テスト計画書に書かれているテストは動的テストをメインにしているようです。レビューが入っている計画書を見た記憶がありません。レビューとテストの両方を入れた計画書を品質管理計画書と呼んでいる組織を見たことがあります。

当日の語る夕べに参加された複数の方から、静的解析ツールに関する情報を全体テスト計画書に入れているという発言がありました。

この記事の全体テスト計画は、動的テストのみ取り上げていますが、記事を読んで現場に適用するとき、静的テストを含めてもよいと思います。

３．全体テスト計画書の位置づけ

全体テスト計画書は、各テストレベルの計画書や各テストタイプの計画書の上位文書になり、プロジェクト計画書の下位文書になります。

余談ですが、語る夕べ当日の内容をツイートを見ますと、「怪文書」と呟いている人が複数いて、僕がちゃんと発音できなくて申し訳ないなぁと。

例になりますが、全体テスト計画書の位置づけは次のような感じです。

プロジェクト計画書
　└─全体テスト計画書
　　　　├─単体テスト計画書
　　　　├─結合テスト計画書
　　　　└─システムテスト計画書
　　　　　　　├─性能テスト計画書
　　　　　　　├─移行リハーサル計画書
　　　　　　　└─運用テスト計画書

上記の例では、性能テスト計画書をシステムテスト計画書の下位文書として位置づけていますが、全体テスト計画書の下位文書としても問題はありません。

全体テスト計画書はプロジェクト計画書の下位文書になり、個別テスト計画書の上位文書になります。詳細部分は個別テスト計画で書く前提なので、全体テスト計画は「大まか」でもいいんですね。

当日もこのように説明し、スライドにも投影していたのですが、次のようなツイートもあり、誤解されないように説明するって難しいなぁと、今更ながら思っています。

４．ISO/IEC/IEEE 29119 のテスト計画書

全体テスト計画書、個別テスト計画書のようにスコープや詳細度を分けてテスト計画書を書きますが、テスト計画書の構成は同じです。

当日の説明が悪くて、次のようなツイートもありましたが、全体テスト計画書と個別テスト計画書の構成は区別していません。にしさんが言うように再帰的だと思います。

初めに、 ISO/IEC/IEEE 29119 Part3 に挙げられているテスト計画書の構成を確認します。組織標準として、テーラリングせずにそのまま使っている組織もあるようです。

1.概観

2.文書情報
　2.1.概観
　2.2.文書番号
　2.3.発行組織
　2.4.承認の権限
　2.5.変更履歴

3.はじめに
　3.1.適用範囲
　3.2.参考文献
　3.3.用語集

4.テストの背景
　4.1.プロジェクト／テストサブプロセス
　4.2.テストアイテム
　4.3.適用範囲
　4.4.前提と制約
　4.5.利害関係者

5.コミュニケーションライン

6.リスク管理表
　6.1.プロダクトリスク
　6.2.プロジェクトリスク

7.テスト戦略
　7.1.テストサブプロセス
　7.2.テスト成果物
　7.3.テスト設計技術
　7.4.テスト完了基準
　7.5.収集されるメトリックス
　7.6.テストデータ要求事項
　7.7.テスト環境要求事項
　7.8.再テスト及び回帰テスト
　7.9.テスト中止・再開基準
　7.10.組織的テスト戦略からの逸脱

8.テスト活動及び見積り

9.スタッフ
　9.1.役割，活動，責任
　9.2.雇用ニーズ
　9.3.教育ニーズ

10.スケジュール

このまま使っているところはありますが、多くの組織では準拠という形で使っているでしょう。いや、どちらかというと、まだ IEEE829 を準拠にしている組織の方が多いかもしれませんね。

５．現場で使われているテスト計画書

現場では様々なテスト計画書が書かれています。次に挙げるテスト計画書の目次は記述量が多いケースだと思ってください。

0.文書情報
　0.1.表紙
　0.2.文書番号
　0.3.作成者
　0.4.承認者
　0.5.目次
　0.6.改訂履歴

1.概要
　1.1.本書の目的
　1.2.本書の範囲
　1.3.本書の位置付け
　1.4.本書の更新タイミング
　1.5.参考資料
　1.6.用語

2.背景
　2.1.プロジェクト概要
　2.2.ステークホルダー
　2.3.前提条件・制約事項

3.テスト対象
　3.1.テスト対象
　3.2.テスト範囲

4.リスク
　4.1.プロジェクトリスク
　4.2.プロダクトリスク（品質リスク）

5.テスト方針
　5.1.テスト目的
　5.2.テスト方針
　5.3.変更部分のテスト方針

6.テスト概要
　6.1.テストの種類と内容
　6.2.テストの流れ、順序

7.テスト基準
　7.1.開始基準、終了基準
　7.2.中止基準、再開基準

8.テスト環境
　8.1.テスト環境一覧
　8.2.テスト環境詳細
　8.3.テスト作業環境

9.テストツール

10.テストデータ
　10.1.テストデータ作成・入手方針
　10.2.マスキング方針

11.テスト体制
　11.1.体制
　11.2.役割
　11.3.要員調達
　11.4.要員教育

12.テスト管理方針
　12.1.進捗管理
　12.2.コミュニケーション管理
　12.3.仕様変更管理
　12.4.問題・課題管理
　12.5.リスク管理
　12.6.品質管理
　12.7.不具合管理
　12.8.構成管理
　12.9.リリース管理
　12.10.エビデンス管理
　12.11.借用物管理

13.テスト成果物
　13.1.テスト成果物
　13.2.テスト成果物の作成方針
　13.3.作成担当者

14.テスト見積り
　14.1.テストボリューム
　14.2.工数

15.マスタースケジュール
　15.1.マスタースケジュール
　15.2.詳細スケジュール
　15.3.タスク構成、WBS 

16.関連システムとの調整事項

17.未決事項

なお、全体テスト計画書をプロジェクト計画書の下位文書とする場合、プロジェクト計画書で記載されている項目は省くことが多いです。たとえば、「2.1.プロジェクト概要」は書かないと決めている組織は多いです。

また、個別テスト計画書で書く内容は省くか、記述レベルを落とします。たとえば、「15.2.詳細スケジュール」や、「15.3.タスク構成」は個別テスト計画書には書きますが、全体テスト計画書には書きません。

たくさんの項目が挙がっていますが、実際の全体テスト計画書は必要な項目だけになっています。

語る夕べの当日、参加者から「全体テスト計画の項目の中で一番重要だと思うものは何ですか」と聞かれたとき、僕はテストの流れを議論したかったというのもあり、「テストの流れです」と答えました。しかし、よく考えてみればテストの流れよりもテスト方針の方が大切です。発言を訂正します。

余談ですが、今の僕の仕事では、テスト計画書を書く仕事は少なくなっていて、テスト計画書をレビューする立場であることが多いので、この目次をチェックリストとして使うことが多いです。

６．全体テスト計画書の内容

テスト計画書の構成は、全体テスト計画書であっても、個別テスト計画書であっても、それほど変わりませんが、記述内容は変わります。

JSTQB Advanced Level シラバス 日本語版には次のように記述内容について書かれています。参考までに確認します。

マスターテスト計画の代表的な内容には次のようなものがある。

- テストするアイテムおよびテストしないアイテム
- テストする品質特性およびテストしない品質特性
- テストスケジュールおよび予算（プロジェクトまたは運用予算と整合しなければならない）
- テスト実行サイクルおよびソフトウェアリリース計画との関連
- テストを行う人々や部署と他の人々や部署との関連性と提出書類
- 記述している各レベルで、どのテストアイテムが範囲内でどれが範囲外かを示す定義
- それぞれのテストレベルに対する個別の開始基準、継続（中止／再開）基準、終了基準、およびテストレベル間の関連性
- テストプロジェクトリスク
- テスト活動の全体的な管理
- 各テストレベルを実行する責任の所在
- 各テストレベルにおける入力と出力

「Advanced Level シラバス 日本語版　テストマネージャ　Version 2012.J03」より引用

７．個別テスト計画の内容

JSTQB Advanced Level シラバス 日本語版には、個別テスト計画（レベルテスト計画）について書かれていますが、リスト形式ではないので、参考までにまとめてみます。

・テストレベル、または、テストタイプで実行する特定の活動を記述する
・全体テスト計画書に書かれていない詳細情報を提供する
・全体テスト計画書を書いておらず、例えばシステムテスト計画書だけ書く
　場合、システムテスト計画書に全体テスト計画書に記述すべき内容を
　含める

８．テスト計画を分かりやすく言い直すと

これまでテスト計画書の具体的な項目を示すことで、テスト計画のイメージをもってもらいました。しかし、具体的な項目にしたことで、項目数が増えてしまい、混乱してしまった人もいるでしょう。そこで、抽象度を挙げて説明してみます。

「ソフトウェアテスト293の鉄則」の著者の一人である James Bach は次のように言っています。

Test Plan = Test Strategy + Test Logistics

Test Strategy は、どの範囲をテストするのか、どこを重点的にテストするのか、目的をどのように達成するのか等を記したものです。

Test Logistics は、Test Strategy を実現するために、資材をどのように調達するか、要員をどのように調達するのか、それぞれのテストはどのくらいのボリュームがあるのか、それぞれのテストを誰に任せるのか、何時から何時までテストするのか等を記したものです。実行計画とも言えます。

現場で使われているテスト計画書の項目を見ると、前半は Test Strategy に関係する項目が、後半は Test Logistics に関係する項目が並んでいます。

この説明で分かる人もいますが、Test Strategy だ、Test Logistis だと抽象度の高い用語を使って説明しているために、分からないと感じる人もいるかもしれません。

説明の仕方を変えてみます。

テスト計画で言いたいことは幾つもありますが、重要な部分の一つはスケジュールです。このスケジュールの正しさ度合いを他の項目で補っています。

スケジュールには、「このテスト」の、「この作業」を、「この期間」で実施します、という情報が載っています。

テスト計画書に書かれているスケジュールの妥当性を確認するには、
・このテストだけで十分なのか、他のテストは実施しなくてもよいのか
・作業に漏れはないか、準備に関わる作業は書かれているか
・この期間でテストは実施可能なのか、その根拠は何か
などが必要になります。

スケジュールに書かれているテストだけで十分だという説明をするためには、その根拠をテスト計画書の中に書かなくてはいけません。作業も期間も同様です。テストのボリュームを適切なロジックで見積もっているのか、そのボリュームを実施するために必要な要員が調達できるのか、等の根拠が欲しくなります。

また、数人のテストチームでは問題にならないことも、数十人、数百人という規模になると、テストチームの運営の仕方や、テストの管理の仕方も確認しなければ、期間内に完了するという確証が持てなくなります。

このように、テスト計画書というのは、スケジュールや工数見積りの根拠を示していると思ってもらえれば、少しは分かりやすいかもしれません。

９．補足： SIer の全体テスト計画書の位置づけ

補足というよりも蛇足のような気もしていますが、少しだけ書いておきます。当日の語る夕べでは、 SIer に所属している人が少なく、 SIer に所属していても全体テスト計画書を書いたことの無い人が大半だったため、この内容の理解が難しかったようです。

特に「全体テスト計画書を納品対象物にするのはなぜか」という本筋ではないところに引っかかる人が複数現れました。

このような背景から、本章は現在 SIer に所属している人向けだと思ってください。

SIer が全体テスト計画書を書くときに注意すべき事柄

発注者ではない受注者である SIer が全体テスト計画書を作成する場合には、一般にスコープと納品対象物に気を付けます。

スコープ

SIer が作成する全体テスト計画書は、自社が受注した範囲全体のテスト計画が書かれたものです。SIer からしますと、自社の受注範囲というのは当たり前のことなのですが、発注者の中にはプロジェクト全体のテスト計画だと勘違いすることがあります。

たとえば、３社に発注していて、１社が全体テスト計画書を書き、残り２社が書かない時に発注者の理解が誤ることがあります。発注者が勘違いしないように説明する必要があります。　　

納品対象物

RFP に書かれた納品対象物に、全体テスト計画書が入っていないことがあります。書かれていないと、納品対象物にしないと判断するプロジェクトが多いです。

納品対象物から外れていても、全体テスト計画は立てるべきです。ただし、レベルは落とすでしょう。納品対象物でない場合はラフなままにしますし、場合によっては、ホワイトボードで書いて記録したものでも構いません。

このように納品対象物でないことから、レベルを下げることのメリットは作成工数が削減できること、デメリットは計画変更のときに、記述量が少ないために書かれた内容の意図を思い出せないことがあります。

まぁ、納品対象物に入っていない文書を作るとなりますと、上司からは非難され部下からは文句を言われて、結果的に作れないということもありますので、そもそも問題がある、デメリットがあるという想定すらあり得ないのかもしれません。

なお、この記事では、発注者、受注者の区別はしませんので、テスト対象全体だと思ってください。

１０．ここまでのまとめ

全体テスト計画の立て方を議論する前に、テスト計画書の構成を確認しました。全体テスト計画書も個別テスト計画書も目次構成はほぼ同じになります。全体テスト計画書に記述すべき内容は、ドキュメント体系の位置づけによって相対的に変わります。

テスト計画書には何が書かれているのか分かりづらい人は、テスト戦略部分とテスト実行計画部分に分かれていると理解してもよいですし、スケジュールの妥当性を残りの項目で根拠を示していると理解してもよいです。