[テストマネジメント虎の巻] 第四回：計画編その2　～テストする環境とやり方をきめる～

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

-----------------------

皆さんこんにちは。2011年2回目のテストマネジメント虎の巻です。前回からは、計画編として、具体的に何をやっていくかに入りました。今回は、テストする環境と、テストのやり方について書いていきたいと思います。

前回のおさらい

前回の本連載では、計画書を作る前に行うこと（テストのために検討すること）としては、大きく以下のことがあるとしました。

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

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

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

・テストしていく上での配置を決める

上記の中で、「テストする範囲」についてまでを前回ご説明しました。簡潔にまとめると、テストするソフトウェアを理解し、テストする機能を決めた上でその内容をプロジェクト内で合意するということでした。すごく当たり前に聞こえると思いますが、当たり前すぎて「どうせわかっているだろう」とか「細かいことでいちいちみんなに聞くのも面倒だ」と思うと、そこに抜け漏れや無駄な重複が生まれます。こういうことを省いてしまわずに一つ一つ押えて仕事を進めることがマネジメントなのではないかと思います。

テストする環境を決める

今回は、テスト対象のハードウェア構成やソフトウェア構成を調査して、テストに必要な機材を含めたテスト環境を決める話から入りたいと思います。これらは、要はテスト機材やテスト用のデータをテスト開始時期に合わせてどれだけ調達できるかを調整しておくといったことです。組み込みソフトウェア開発によくある話でいえば、ソフトウェアをテストするためハードウェアの調達時期や台数の問題があります。試作機上にソフトウェアを搭載してテストする場合、物理的に何台用意してもらえるのか、試作機にはテストするために必要な部品がすべて搭載されているのか、試作機が調達できないときに代わりにテストを進めるためのシミュレータはあるのか、ということを予め調査して、自分たちがテストするときにはどうするかを決める話になります。予算や工数との兼ね合いもあるので、闇雲にたくさんのことを要求できません。プロジェクトにとって最適なことをテストマネジメントを担当する人自身が考えた上での調整となります。

ITシステム開発でいえば、連携する他のシステムは調達できるのか？テストデータはどこまで本物に近いものを用意できるのか？ネットワーク構成は再現できるのか？と言ったことになるでしょう。たくさんのハードウェアを用意してテストをする「場所」が確保できるのか、といったことも非常に重要です。たとえばシステムテスト用の疑似環境を作るには最低でもサーバが5台必要で、10人がテストをすることになった時に、サーバ5台、クライアント10台以上の電源が確保でき、10人が作業できる場所が確保できないとなると、テストができなくなってしまいます。（一例ですが、私がテストリーダをやっていたときに、狭い部屋でテストをしなければならないために全部のPC本体を並べて設置していたら、テスト中にPCから出る熱のためにハードが壊れたことがあります。）

最近では仮想化環境を使って効率よくテスト環境を整えると言った例もありますが、セキュリティや負荷の問題を考慮しないと、後で上手くいかずにテストができないなんて問題になってしまうので要注意です。（顧客データが仮想化したテスト環境から流出したという事例も聞いたことがあります。）

また、テストのインフラとして不具合管理ツールや、テストケースを管理するツールは何を使うのか、テストツールはどの程度使用可能か、ということも決めておきましょう。

テスト環境の問題は全部に影響を与える

テスト環境の問題をこれほど大きく考慮するのは理由があります。テスト環境がどうなるかは、テストのやり方やリソースの見積もり、スケジュールの作成に大きく影響を与えるからです。人員を潤沢に揃えてもテスト環境が足りなくなってしまっては本末転倒です。テスト結果をどうやって確認するかをテスト環境の制約によって工夫しないといけないケースも多々考えられます。

また、テスト環境の調達は、開発スケジュールそのものに影響を受けます。テストを効率よくやりたいと思ったら、そのタイミングでテストできる状態のものが必要です。それは開発スケジュールを見直さないと実現できないこともあり、そのためにはより早い段階で関係者に必要性を訴えて調整していかないと理想とはほど遠い状況でテストをしていかなくてはならなくなってしまいます。

テスト用環境に必要なものはわかった先から列挙していき、テスト環境の構成図などを作って漏れのないようにして、調達のための交渉を早い段階で開始しておきましょう。

テストのやり方を決める

テストの準備をしているときにやっておかなければならないことは他にもあります。それはテストプロセスを決めることです。テストプロセスを基本的には単純で、だいたい以下のプロセスで構成されます。

・テスト計画作成

・テスト分析・設計

・テスト実装（環境の準備、テスト実施手順決定）

・テスト実行

・報告書作成

・マネジメント作業（モニタリングとコントロール、欠陥管理、構成管理）

テストプロセスは、組織で標準的なやり方が決まっていればそれをベースにすればよいと思います。しかし、そのまま鵜呑みにせず、自分たちのプロジェクトに合うように標準のテストプロセスを見直す、もしくは自分たちの考えていたやり方を見直すことが必要になります。これはマネジメントとして重要な仕事になります。また、前回もご説明した通り、テストはテストチームだけがやるのではなく、開発者も顧客やユーザも行うので、それぞれがどの部分をテストしているのかがわからないといけません。

図 テストプロセスとテストレベル

図は、V字モデルにテストプロセスを書きこんだ例です。テストプロセスは、V字モデルの右側のテストレベル（単体テスト、統合テスト、システムテスト、受入テスト）毎にあります。標準的に計画～報告書作成までのプロセスが必要ではありますが、それぞれのテストレベルごとにまるで同じ活動を計画し、同じアウトプットを作成しなくてもかまいません。あなたが受け持つテストレベルを明らかにして、そのテストレベルは標準のテストプロセスをどうカスタマイズしたかをあなた自身がわかった上でテストを進めていけばよいのです。カスタマイズしても本当にそこで必要なものがそろっていれば問題ありません。本当に必要なものがどこにあるかわかるようにしておくことが計画をドキュメントに残す理由です。

テストのやり方として、テスト計画作成前にちゃんと考えなければならないことは、開発プロセスのどのタイミングでテストプロセスの何をするかということと、誰がどのテストをやるかということです。誰がどのテストをやるのかという話は前回の「テストする範囲を決める」をベースに調整をする話となります。テストに関与する人たちが綺麗にテストレベルで分割できる場合もありますが、同じテストレベルに複数のテストチームがいる可能性もありますので、しっかり整理しておかないと無駄に同じテストをしてしまうこともあります。もっと恐ろしいのは、自分たちの範囲ではないと勝手に思ってしまい誰もテストしていない部分がでることです。

あなたが受け持つテスト以外には、誰がどうテストを行い、それらは開発プロセスのどのタイミングで上記のテストプロセスの何をするかという関係付けを考えると、確認しなければならない関係者も増えるため大変です。開発プロセスに対して柔軟に単体テストから受入テストまで全部のテストのバランスを最適化するなどといったことは、現実的にはかなり困難ですが、できる範囲でしっかり考えて、無駄のないテストをするようにしましょう。

また、開発プロジェクト全体とあなた（とあなたのチーム）とのコミュニケーションに関わる部分も決めておきましょう。これもテストレベル毎に異なります。ざっと思いつく最低限必要なことを挙げてみます。

・テスト計画を作成するときの不明点を明確にするためのコミュニケーション方法
・バグレポートの起票から開発チームでの回答、原因分類、終了のフロー
・仕様変更が入った場合の連絡の方法

・開発からテストチームへのリリースの方法
・品質情報（バグの統計情報など）の開発へのフィードバック方法
・その他情報共有のためのミーティングの設定（定例が望ましい）
・出荷判断のためのミーティングの設定

テストのやり方を決めるのは、複数のテストレベルが同時進行し、また開発プロセスに依存するからです。決めておかないとテストしたほうが良いのかしなくてよいのかがわからなくなり、「手が止まって」しまうのです。プロジェクト全体との円滑なコミュニケーションがとれるように、準備段階から意識するようにしょう。

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