[テストマネジメント虎の巻]第六回：計画編その4　～計画の文書化～

これは2011年06月にHPのマーケティングサイトのブログへ投稿したものを転載しています。

----

皆さんこんにちは。前回までは計画のなかで考えるべきことを４つ説明しました。今回は計画の文書化について解説することにします。

いよいよ計画書にする

テスト計画書とは、前回までの本連載の計画編で解説してきたことを文書にしたものです。計画書のひな型としてはIEEE829（アイ･トリプル･イーと読みます）というテストのドキュメント標準が一般的です。最新バージョンはIEEE829-2008という2008年にリリースされたものになります。1つ前のバージョンの1998年度版であれば、筆者が高橋寿一さんと共著した「現場の仕事がバリバリ進むソフトウェアテスト手法」にて目次となる章ごとの詳細な書き方を解説していますので参考にしてもらえればと思います。

図1　IEEE829-2008のテスト計画書の目次

（2017年01月28日　追記）現在、テスト計画書の世界標準は、ISO/IEC/IEEE29119-Part3（2013年リリース）になります。Part3のテスト計画書についてはいつか書きたいと思いますが、とりあえず本ブログの一番下にに目次だけ掲載しておきます。

目次だけをみると、「こんなにたくさんのことを書かなければならないのか」とゲンナリするかもしれません。しかし、これはテスト業界の標準テンプレートであり、これまでの世界中の多くのプロジェクトの成功パターンが凝縮されています。つまり、テストを本当に最初から全部考えるとなると、これだけ多くのことを考慮しなければならないということです。考慮すべきことを考慮しないで仕事を進めると、後で手戻りが発生し、逆に工数が余計にかかってしまいます。これまでの計画編で決めることを思い出してください。ほとんどの内容は埋まっていきます。(図2)

図2　IEEE829-1998とテスト計画に関し連載で触れた内容

ただし、このままドキュメントにするのは大変だと思うのももっともです。大規模なプロジェクトで計画策定にたっぷり時間が取れる場合はまだしも、小規模なプロジェクトで計画も数日しか取れない場合などは、言われたとおりに文書化すると大変な工数がかかってしまうでしょう。その様な問題を回避する工夫が必要となってきます。

計画書を書く際に工夫すべき2つのこと

連載の三回目（テスト計画編その1）でも触れたように、テスト計画で重要なのは文書を作ることではなく、「テストする範囲」「テストする環境」「テストをやる方法」の3つを決めることであり、文書に残すのは、決めたことをプロジェクトマネージャやプロジェクトメンバーなど開発プロジェクトに関わる人たちにわかってもらえるようにするためです。なので、綺麗な計画書が最初に完成する必要はありません。

テスト計画書を書く際に工夫すべきことのひとつとして「フローズンスポットとホットスポットの識別」と「必要な時期に必要な部分だけ作る」の2つがあります。つまり、テスト計画を1つの文書として最初につくるのではなく、「どのプロジェクトでも同じ」文書と、「本プロジェクト特有」の文書を分けて作ります。同じになる部分をフローズンスポットと呼び、特有になる部分を「ホットスポット」と呼びます。

また、もうひとつの工夫すべき点は、ホットスポットは「あらかじめ決めておかなければいけない部分」と「状況がわかってきてから追記していく部分」を分けて文書にすることです。実は、これはテスト計画をドキュメントにする際だけにとどまらず、計画や設計と呼ばれる創造的な作業には総じて言えることです。

図3　IEEE829-1998と計画書を書く際に工夫が必要な２つのことテスト計画に関し連載で触れた内容

以下に、フローズンスポットとホットスポットに分けてもう少し具体的に書いてみたいと思います。

フローズンスポットとなる文書

フローズンスポットとは、分析の結果、相互作用や変化がなく固定化しており、今後の変更が起こらないと思われる「固定部分」のことを指します。メンバ間、顧客、上層部で共有すべき原則や組織で統一した基本的作業が該当します。

テスト計画で言えば、過去のプロジェクトから流用できることや組織共通の認識として認知されていることであり、例として以下のものがあげられます。

･標準的なテストプロセス

･テストケース管理の方法

･欠陥追跡の方法

･構成管理の方法

･見積もりに使う基礎データの計測方法

･用語

これらは、標準書のような形式で文書化します。そうしておけばプロジェクトごとに計画書を書くたびにそれらの記述をする必要が無くなります。ただし、標準書の類は、常に使っていないとすぐに形がい化します。その内容の教育を行ったり、活用のガイドを作るなどの方法で、プロジェクトのたびに改まった説明が無くても共通の認識を持ってその標準を使って仕事ができるようにしておくことが重要です。

ホットスポットとなる文書

ホットスポットとは、分析の結果、新たな要求の発生が予想されその変更に対し柔軟に対処できるようにした「可変部分」のことを指します。テスト計画に関することで言えば、組織の標準をそのまま使うわけにはいかないプロジェクト特有の部分であり、最初から全てが分かっていると言うよりもプロジェクトが進むにつれ見えてくるものが該当します。

テスト計画で言えば、必ずプロジェクト毎に作らなければならないものになります。ただし、前述したようにプロジェクトが進むにつれ見えてくるものであるため、必要な時期に必要な部分を作るのが得策と言えるでしょう。

なるべく早く決めたほうがよいこととしては、早期のタイミングで、メンバ・顧客・経営者と合意しておくべきことと、次の作業をするために決めておかなければならないことの2種類があり、例として以下のものがあげられます。

＜早期のタイミングで合意が必要なこと＞

･テストの目的

･テストのやり方（開発のどのタイミングでテストをやるかなど）

･見積もり

＜次の作業に直結すること＞

･テスト分析作業に必要なタスクやスケジュール

ギリギリまで変更が入ること前提にしておくこととは、計画をたてる段階で明確に出来ないことか、もしくは仕様変更やメンバ移動などによる変更が入ると思われることであり、例として以下のものがあげられます。

＜すぐに明確にできないこと＞

･テスト対象範囲

＜変更が入って来ると思われること＞

･テスト実施スケジュール

ホットスポットの部分は、プロジェクト毎に内容が異なるので標準書の様にはできませんが、テンプレート化して記載に手間取らないようにするなどの工夫は必要でしょう。また変更が入ることを前提としたほうがよいため、変更を容易にする工夫は必須となります。例えばデータベースで情報を管理し、変更時の影響範囲をすぐに調べられるようにしたり、バージョン管理を導入したりすることが考えられます。また、公式な文書を作成する必要がある場合は、データベースの内容をベースに報告書を自動生成するプログラムを作るなどの方法が考えられます。

今回はテスト計画の最終回として、計画の文書化について説明しました。計画は文書を書くことではなく、中身を十分に考えてどうすればよいか決めることであると書いてきましたがですが、文書を作ることも、コミュニケーションのために避けては通れません。ただ、文書を作ること自身が労力を要する作業であるため、工夫をしないと本来の仕事の時間を圧迫してしまうので意識して対処することが必要になります。

次回は、「テストの見積もり」についての説明をしたいと思います。

---参考までに29119Part3のテスト計画書の目次---

（2017年01月28日　追記）目次を列挙して改めてこれは解説しないと誤解を生むな！って思いました。例えば、test item。これはテストアイテムと訳すようにしないといけないです。テスト項目と訳すと、日本の多くの組織はテストケースのことを指すので全く違うものになってしまいます。テストアイテムはテスト対象の明細です。他にもテストサブプロセスという新しい用語があったりするので。なるべく早くこの件を書くように頑張ります！