これは2011年01月にHPのマーケティングサイトであるBTOClub（当時）のブログへ投稿したものを転載しています。

ーーーーー

皆さんこんにちは。2011年最初のテストマネジメント虎の巻です。本年もよろしくお願います。前回は、テストマネジメントの全体像についてでした。今回からは、テストマネジメントとしてやることを最初から書いていきたいと思います。今回から数回は計画編です。

テストの計画

計画とは、「目的を達成するにはどうすればいいかを活動前に十分に検討することである」と前回言及しました。テスト計画はテストのための「計画」です。JSTQBの用語集では「テスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント」であると書かれています。「狙い」は、目的のこととほぼ同一でしょう。アプローチは「どうすればよいか」ということへの回答です。リソースは見積もりに関することになります。スケジュールはそれらが全部反映し、具体的な作業に割り振った結果です。

ソフトウェアの開発プロジェクトが発足し開発計画が立てられる中では、テストに関してどうするかも計画に含めていかなければなりません。読者の皆さんが今どのような立場でテストに携わっているかは千差万別だと思いますが、どちらにしろテストには計画が必要です。なぜならテストは単に与えられた期間に適当にソフトウェアを動かしていれば済むものではなく、マネジメントが必要だからです。（詳しくは第一回を参照してください。）

開発プロジェクトのテストを任せられたら

まず最初にテストを任されたところから話を始めていきます。あなたがソフトウェア開発プロジェクトのテストを任されたらどうしますか？まずは、プロジェクトマネージャから開発プロジェクトの概要の説明を受けるでしょう。もしかしたら、突然、「君がテストのリーダーね。テスト工数見積もって」などと言われるかもしれません。そのときにはあわてずに、

・どういう目的で使われるソフトウェアなのか？ （もしくは機能変更や追加の目的）

・予算（もしくは何人のメンバーを使ってよいかという話かもしれません）

・納期はいつ（いつからいつまででテストを行うのかという話かもしれません）

といったことを確認（もしくは再確認）し、プロジェクトの計画に関する基本的な情報を得るようにします。もうひとつ、何のためにテストを行うのか？ という話もうやむやにしないで、冷静に確認しておきましょう。テストのミッションは、製品がリリース可能な品質かどうかを証明することだけではありません。バグをたたき出し信頼性を向上させることや、搭載技術の実現可能性を確認すること、もしくは品質規格を満たしていることを証明するためのデータ計測など様々なことが考えられます。テストは品質を確保するための一手段であり、プロジェクトではいろいろな手段を組み合わせて品質を担保しています。何でもかんでもテストするのではなく、品質を確保するためにテストに求められていることを明らかにすることがテストの方針、目的として非常に重要になります。

テスト計画を書くその前に

それらの話を受けて、「さぁ、テスト計画書を作ろう」となるのはまだ早いです。まず、計画には何を書くのでしょうか？

以下の様な回答はNGです。

・ファイルサーバにある過去の計画書を元に、闇雲にそれと同じ計画書を書く

・IEEE829（国際的なテスト関連のドキュメント標準）のをベースに穴埋めをする

・MSProjectなどでガントチャートを使ってスケジュールのみを書く

なぜNGかと言うと、これでは、目的を達成するにはどうすればいいかを活動前に十分に検討したことにならず、筆者が冒頭で記述した「計画とは？」に反するからです。実際、1、2時間プロジェクトの説明を受けただけではとうてい作れるものではありません。（だからと言って時間をかければよいというものでもありません。時間をどれくらいかけるのかについては別の回で記載します。）

計画書を作る前に行うこと（テストのために検討すること）としては、大きく次の3つがあります。

・テストする範囲を決める

・テストする環境を決める

・テストのやり方を決める

・テストしていく上での配置（人員の配置、時間的な前後関係）を決める

重要なのは文書を作ることではなく、上記の３つを決めることです。決めたことをプロジェクトマネージャやプロジェクトメンバーなど開発プロジェクトに関わる人たちにわかってもらえるよう、文書に残します。「けど、計画書なんて実際は見てません。」と断言する人もいるかもしれません。しかし、誰も見ない計画書など本当は作る必要が無いのです。見てもらえる計画書を書くポイントは、チームとして仕事する際にわかっておいてもらいたいことがはっきり書いてあるかどうかです。何でもかんでも文書にして分厚い計画書を作るのは間違っていますし、読んでもらえないからと言ってスケジュールしか書かないのは、スケジュールの前提となる意図が抜け落ちてしまうため本末転倒です。

では、計画書を作る前に必要な３つのことのうち、「テストする範囲を決める」についてもう少し詳しく書いていきます。

テストする範囲を決める

テストを計画するために最初に行うのは、テスト対象となるシステムへの要求や仕様の理解です。理解しないことにはテストのしようがありません。理解したら、要求や仕様が書かれたドキュメントからテスト対象になることをつらつらと書き出していきます。そういうと簡単そうですが、そのためにはテストベースを収集しながら、「テストする対象（テストアイテム）」について分析（つまり、分解することで理解を深めること）をしなければなりません。それはいったいどのようなユーザに何のために使われるソフトウェアなのか、またそのソフトウェアの機能にはどのようなものがあり、ユーザが各機能を何のために使うのか？を理解する必要があります。ある程度テスト対象についてわかってきたら、その情報をもとに不明点のヒアリングをしていきます。ヒアリングする相手は設計者の場合もあれば、顧客の場合もあります。ドキュメントが充実していなくて、わからない部分が残っている場合もありますが、悩んで時間を費やすようでしたら、先にヒアリングを行うのも一つの手です。

テスト対象についての情報を収集し、不明点などをヒアリングしたら、「テストする機能」を洗い出して一覧にしておきます。漏れがないことを意識して、常に整理しながら進めていくことが大事です。ただ、開発プロジェクトにテスト計画をするテストチームが関与できるタイミングによって、要求定義や設計がどこまで進んでいるか異なるので、一覧がどの程度細かく作れるかどうかはケースバイケースです。対象になる機能を理解してまとめていく作業では、細かく作れなかったとしても、不明確な部分がどこなのか洗い出しが出来ているようにしましょう。不明確な部分が多いと後々まで苦労することになるからです。

最後に、一覧を使って、開発メンバーと（できれば顧客とも）テスト範囲の意識合わせをします。テストは開発プロジェクトみんなが行います。コードを書く人は、自分が書いたコードが正しく動くかをテストしますし、顧客は自分が使いたいソフトウェアになっているかを確認し、開発側にお金を払います。（いわゆる検収です。）あなたが関わる開発プロジェクトの規模にもよりますが、あなた自身がテストリーダとしてテストを受け持つ範囲でないところをテストするテストチームが他にいるかもしれません。それぞれがどの部分をテストしているのかがわからないと、無駄な重複が起こるかもしれませんし、もっと怖いのは誰もが当然テストするだろうと思っていたことを誰もテストしていないといった状況です。

あなた（のチーム）と他のプロジェクトに関与する人たちとのテスト範囲の棲み分けを行い、また、あなたが考えたテストの優先度について意識合わせを行って合意すると、それは限られたテスト工数をどう有効的に使うかの指針になります。不明点があることを認知してもらう意味でも大事ですし、たとえば段階的にリリースをしていく場合、テストしやすいようにリリース順を考慮してもらったりする交渉もできます。

今回はテストを任せられたら行うこととして、「テストする範囲を決める」ことについて説明しました。次回は、「テスト環境とテストのやり方を決める」ことについての説明をしたいと思います。