大塚先輩：

さて、さっそく見ていくことにしようか。

中山君：

はい、よろしくお願いします。（⁠ドキドキ）

大塚先輩：

まず最初に…、表紙を付けたのはいいね。最初の計画書に表紙を付ける人はあまりいないんだ。よく気づいたね。

中山君：

今までの計画書を参考にしました。

大塚先輩：

で、中身なんだが…これはずいぶんと薄いね……

中山君：

（あれれ、何か足りなかったのかな…）

てっきり、すんなりとOKがもらえると思っていた中山君はうろたえました。

大塚先輩：

中山君、この計画書には何を書けばいいと思う？

中山君：

何を書けばいいって……。スケジュールは重要ですよね。スケジュールが無い計画書って見たことありません。

大塚先輩：

スケジュールは重要だよね。他には？

中山君：

体制図も入れました。でも、それだけじゃ計画書として不十分なんですか？

大塚先輩：

そう。確かに中山君が書いたものも計画書と言うこともあるけれども、この内容だけでは、うちで仕事をするには不十分なんだ。

中山君：

でも…。たくさん書いても計画って結局使わないですよね？　無駄じゃないですか。

大塚先輩：

無駄にするかどうかはリーダの腕次第だ。そう思わないかい？ 立派な計画書に見せるために、意味のない情報を羅列している計画書ならば、俺も無駄だと思う。でもそうじゃないよね。

目的は何？

大塚先輩：

まず聞こう。今回のテストの目的はなんだと思う？

中山君：

テストの目的ですか？ バグを見つけるためではないんですか？

大塚先輩：

テストにはいろんな目的がある。目的が変われば、テスト設計の方針やテストケースも変わってくる。

中山君：

え？　そうなんですか？

テストの目的

テストの目的はおおむね3種類に分けることができます。

バグを見つけるためのテストケースと、品質を保証するためのテストは異なります。どんな目的でテストをするのかを把握していないと、どんな種類のテストをすればよいのか決められなくなります。

テストの定義とテストの範囲

大塚先輩：

次に、どんなテストをするつもりなんだい？

中山君：

えっ？　普通のテストですけど…。特別何か変わったテストをするつもりはありません。

大塚先輩：

コンポーネントテストなの？ システムテストなの？

中山君：

システムテストです。

大塚先輩：

じゃぁ、システムテストの定義は？

中山君：

みんながやっているテストと同じことを今回もやろうとしています。新しめのテクニックとか使うつもりはありません。

大塚先輩：

…質問を変えよう。どの範囲をテストしようと思っている？

中山君：

範囲ですか？ 仕様書に書かれている範囲をテストしようと思っています。

大塚先輩：

仕様書に書かれていたら、全部やるのかな？

中山君：

全部はできません……。 何となくわかってきました。そういうことなんですね。

テストの定義

テストレベルやテストそのものについての定義を計画書に記述するかどうかは、プロジェクトによって異なります。所属している会社やプロジェクトでテストプロセスなどの標準が定義されていれば書かなくてもいいかもしれません。

しかしながら、多くのパートナー企業と一緒にテストをする場合には、意識をあわせるために定義を記述するべきです。まだ経験が少ない場合、テストの定義を意識することはないかもしれませんが、ほとんどの場合その認識は人や企業により異なります。しっかりと意識を合わせることは非常に大切なことです。

テストの範囲

行うべきテストの定義が決まったら、テストの範囲を決める必要があります。テストする機能とテストしない機能を明らかにしなければいけません。また、ソフトウェアとハードウェアの範囲、他システムとの範囲など決めておかなければならないところはたくさんあります。仕様書に書かれていないような範囲もありえますので、これもしっかりと決めておきましょう。

計画書を読ませるターゲット

大塚先輩：

ところで、この計画書を読んでもらう相手は誰なの？

中山君：

大塚先輩です。

大塚先輩：

そうじゃなくて、誰のために書いたの？

中山君：

特に決めていません。強いて言えば、みんなのためになります。

大塚先輩：

みんなって誰になる？

中山君：

プロジェクトのメンバー全員です。

大塚先輩：

プロジェクトのメンバーだけでいいの？

中山君：

えっ？ プロジェクト以外のメンバーがいるんですか？

計画書のターゲット

よほど特殊な事情がない限り、プロジェクトの成果物となる文書は誰かに見せるために書きます。このテスト計画書も同じです。誰かに見てもらうために書いています。この文書がお客様に提出する計画書なのか、それとも自社の管理のために使用する計画書なのかによって、記述内容は変わります。自社向けならば、細かいコストの話が入ってきますし、参画メンバのスキルによってはトレーニング計画も必要になります。

誰のために作成するのかを意識して、必要となる記述内容を考えましょう。

テスト環境とは？

大塚先輩：

ところで、このテストどこでやるんだ？

中山君：

お客様が指定された場所だと思いますが。

大塚先輩：

そうじゃなくて、ソフトウェアが実装されている環境だよ。テスト環境のこと。

中山君：

テスト環境？ あまり意識していなかったんですけど…。

大塚先輩：

環境が特殊だと、その準備にいろいろと手間がかかるだろう。事前にどのような環境なのか整理しておかないと計画の精度が落ちるよ。

中山君：

えっ？ ただテストするだけなのに、そんなことまで考えるんですか？

テスト環境

テスト計画時には、どのような環境でテストをするのかを把握しておく必要があります。サーバのスペックや実行環境などを調査し記述します。ネットワークなどの情報も押さえておきます。場合によっては、機器の台数やソフトウェアのライセンス数など細かいレベルで情報を押さえます。なぜなら物理的な台数によって"同時にテストできる人員数"が変わったりするからです。それ以外にも多様な影響が考えられます。

テストの体制とスケジュール

大塚先輩：

スケジュールにちゃんとテスト設計が入っているのはいいね。テスト計画、テスト実施、テスト報告だけで終わらせる人が多いんだ。

中山君：

ありがとうございます。

大塚先輩：

だけど、その仕事を誰がやるのか決めている？

中山君：

朝ミーティングの時にでも決めようと思っています。

大塚先輩：

朝ミーティング？

中山君：

はい。事前に仕事を割り当てても、結局できないこと多いので無駄だと思っています。

大塚先輩：

事前に決めた方がよいこともあるんだ。たとえば、中山君はリーダの仕事だけだと思っているの？

中山君：

はい、今回のプロジェクトではリーダとして管理作業を中心にやろうと思っています。

大塚先輩：

この体制でそれは難しいんじゃないか？ このチームの人員数から中山君にも実作業をやってもらうことになる。

中山君：

つまり兼任ということですか？

大塚先輩：

その通りだ。リーダーとプレイヤー、両方を行うことになる。こうなってくると何をやるか事前に決めておかないと、混乱してしまう。また、先々どんな準備が必要かもわからなくなるよ。

体制とスケジュール

タスクと役割の関係を整理したものをTRM（Task Responsibility Matrix）（⁠※1）と言います。タスクをメンバの責任や役割に応じて割り当てた表のことです。縦軸にタスク、横軸にメンバをとった二次元マトリクスを作り、両軸の交わるマス目に役割を記入します。

このように役割を明確にすることで、計画の精度を上げていきます。

スキル一覧

もし、メンバのスキルがわかっていないのであれば、スキル一覧も作っておきます。このスキル一覧を見ながら役割を割り当てていきます。また、プロジェクトに必要なスキルを持つ人員が不足していることがわかりますので、新たに人員を確保するなど対策をとります。

その他

この他に、コミュニケーション計画（定例会の設定や開発チームとのQ＆Aのやり方）を決めたり、リスクと対策を決めておいたりします。

そうそう、プロジェクトキックオフや中途振り返り会なども決めておきます。

大塚先輩：

まずは目につくところを挙げてみたがどうだい？

中山君：

はい、正直簡単に考えていました。まさかこんなに考えることが多かったなんて…

大塚先輩：

テスト実施の担当者を長年やっていると自信がついてくるが、リーダーというのは単なる作業とりまとめ者じゃない。必要となる考え方や視点、スキルなど大きく違ってくる。

中山君：

今までは自分に直接関係がなかったので、計画書などもまじめに読んでいませんでした。だからダメだったんですね。

大塚先輩：

そこに気がついただけでも、一歩前進だ。適当に読んでいた計画書をもう一度しっかり読んでごらん。そしてもう一度作成してごらん。

中山君：

はい！初心に戻って、もう一度作成してみます！

どうせ計画書なんて使われないから適当でいいやと考えていた中山君でしたが、結果として大塚先輩にたくさんの指摘をもらうことになってしまいました。

テスト実施者とテストリーダでは求められるものが大きく異なります。特に今回取り組んだテスト計画は、テスト実施者としての作業が主だった頃にはほとんどなじみがありません。リーダを目指すにあたっては、まずこのようななじみのない作業を行うとき、周りがどのように行っているのかちゃんと確認する必要があります。

終わりに

さて、大塚先輩はざっと目に付くことを指摘しましたが、どうやらまだまだ言い足りないようです。これらの指摘以外には、いったいどのようなことに気をつけなければならないでしょうか？ 読者の皆さんも「○○は書かなきゃ！」とか「××に気をつけろ！」とか言いたいことがあるかもしれません。再度第1回の資料を参照しながら考えてみてはいかがでしょうか。

また、せっかくの機会ですから、本稿での指摘点などを参考に、皆さんの普段の仕事や、会社に準備されている標準を見直してみてください。きっといろいろなことに気が付くでしょう。