【ソフトウェアテスト】テスト計画書を書くことの難しさ

これまでいわゆる「テスト仕様書」を書いたことはあったけれども、その上位文書とも言える「テスト計画書」を設計？することになり、頭を抱えている。

※このエントリーは「テスト計画書」の書き方をレクチャーするような内容ではありませんので、ご注意ください！ほぼ愚痴です！

テスト仕様書は、「システムにおける機能や非機能に対して、確認したいモノがあるので確認できるような手順を期待値とともに書く」という感じだが、テスト計画書の場合、その「目的」や「どのような確認方法を取るか」を調べておかなくてはいけない。

テスト計画書とはなにか

JSTQBというソフトウェアテストの技術者資格の教本によると、テスト計画書とは以下の構成で成り立つドキュメントのことだ。

テスト計画識別番号
はじめに
テストアイテム
テスト対象機能
テスト非対象機能
アプローチ
テストアイテムの合否判定基準
中止／再開基準
テスト成果物
テストのタスク
環境要件
責任範囲
要員計画とトレーニング計画
スケジュール
リスクと対策
承認

ものすごい物量が必要なドキュメントだというのがわかる。これらはシステムに関わる部分すべてが対象になるので、確認すべき範囲も広い。もちろん小規模なシステムであれば別だけど、テスト計画書なんてわざわざ作るくらいなので、中規模・大規模なシステムであることが前提だと思う（小規模だろうがテスト計画書書きますよ、という場合はすみません）

今のプロジェクト内で作ろうとしているテスト計画書も上記のような構成になっている。おそらくIEEE829に準拠しているのだろう。内容的には以下のような感じだ。

テストアイテム：テストを実施する対象や要素といったものを一覧化する
テスト対象機能：読んで字のごとく、システムにおいてテストの対象となる機能を明記する
テスト非対象機能：これも同様に、システムにおいてテスト範囲外となる機能などを明記する。例えば既存機能に追加するシステムで、既存部分すべてを網羅する必要がない場合などに記述する。※もちろん無影響確認などで網羅するケースもあるので一概には言えない
アプローチ：テスト目的や実際のテスト戦略（テスト手段）などの一覧
合否判断：これも読んで字のごとく、テスト結果についてどういった場合に可とするかといった判断基準を記載する
中止／再開基準：テストを中断せざるを得ない状態になった場合の判断基準や、再開するための基準を記載する。
成果物：テストを実施した結果にどのような成果物が必要かを明記する。
タスク：テスを実施するための準備などを記述する。
環境要件：テストを実施するための環境整備に関する記述。
責任範囲：テストに関わる関係者（たとえばプロマネ、プロジェクトリーダーが誰かとか）を記載する。
要員計画とトレーニング計画：テストに必要な人員や、テスト準備・実施するに当たっての必要なスキルを身につけるためのトレーニング計画などを記載する。
スケジュール：いつからいつまでにテストを準備し、実行するかといったスケジュールを記載する。
リスクと対策：テストに関わるリスク（範囲の広い言葉だ...）と対策について記述する。
承認：テスト計画の承認者の明記。

正直ゼロベースからテスト計画書を書け、と言われたらなにも出来ないまま終わる。なので今は他のプロジェクトで作られたテスト計画書を参考に作っている。参考に～とは言いつつシステムが違えば検証箇所も当然異なるので、「書きっぷり」を参考にするということくらいしか出来ないのが悩ましい。

テスト計画書の難しさ

「いや、お前が簡単にできることなんてない」と言われたら、ハイ、その通りですと返すしかないんだけれどもテスト計画書はそれを差し引いても難しい。というのはシステム全体を把握していることが最低条件であるからだ。ITaと呼ばれるシステム内結合とITbと呼ばれるシステム外結合があるけれども、システム外に当たる部分もきちんと把握していないと、このドキュメントは書き出せない。

取捨選択することの難しさというか...これは必要、これは不要といった判断はある程度なにかにつけ把握していることが前提で、漠然としている状態で要不要の判断なんて下せる訳がない。なのでいけないとわかってはいるものの、ほかプロジェクトのテスト計画書を見つつ、「これはそのまま流用できそうだ」という箇所をコピペで作りながら体裁を整えている。これは危険な香りがプンプンする。レビューで根拠を聞かれても「コピペで作ったので」とは言えないので詰まるパターンだ...

要件定義書や基本設計書を眺めても基本は業務システム中心で、基盤系の設計書はなかなか確認が出来てないのも要因だ（せっかくあるのだから読みなさい）。

テスト計画書を書いたことがある人は、どうやって書けたのか教えて欲しいくらい。当然立場も経験も状況も何もかも違う状態なので、「こうやって書くのが正しい」というのを今のプロジェクトのテスト計画書に当てはめるのは難しいのだろうが。ソフトウェアテストPRESSを買ってきて、読んではいるもののピンポイントでこれ！というわけではないのでなかなか書きあぐねている...

次回、同じテーマでエントリーを書くのであれば「どのように（無理やり）テスト計画書を書き上げたか」で書こうと思う。