テストはテスト計画、テスト設計、テスト実行、テスト管理という4つのプロセスで構成され、それぞれに最低限実施すべき作業がある。各プロセスではアウトプットとしてドキュメントを作成し、それがプロセスの間をつなぐ役割を果たす。やるべき作業をしていなかったり、ドキュメント作成をサボっていたりすると、テストはうまくいかなくなる。

 今回はソフトウエアテストの全体を俯瞰して、ソフトウエアテストを構成する4つのプロセスと各プロセスでの作業、プロセスのアウトプットとして作成するドキュメントを解説する。

テストのプロセスと作業
4つのプロセスと15の作業を押さえる

 ソフトウエアテストではどんな作業を実施しなければならないのか。改めて聞かれると、自信を持って回答できる人は多くないだろう。もしかすると、あなたの現場はやるべき作業を不用意に飛ばしてしまっているかもしれない。あるSIベンダーの若手社員「ワカテくん」もテストの作業を勘違いしているようだ。

 
ワカテ:ソフトウエアテストが「ソフトウエアが想定通りに出来上がっているかどうかを確認する」ということは分かりました。となると、テスト担当は開発が終わるまで何もしなくていいんでしょうか。

センパイ:いや、それは違うよ。やらなければならない仕事はその前にも色々あるんだ。

ワカテ:あ、そうか。テストケースを作らなくちゃいけないんでしたね。

センパイ:結構分かってきたようだね。でも、それも合格点をあげられる回答じゃないな。事前にやるべき作業はテストケースの作成だけじゃないんだ。

 テストというと、開発が終わった後のテストフェーズを思い浮かべる人が多い。あらかじめ決めたテスト手順の操作を実行して「テストケース」(テストで確認すべき事項を記述したドキュメント)を消化していくというイメージが強いようだ。だが、これは「テスト実行」という、テスト全体のプロセスのごく一部。しかも、ひたすらテストケースを消化するのは、テスト実行プロセスの一面にすぎない。

 ここではテストの準備から終了までの一連の作業を概観しよう。一連の作業のことを「テストプロセス」と呼ぶ。テストプロセスには「テスト計画」「テスト設計」「テスト実行」と、各プロセスの状況を確認する「テスト管理」の4つがある(図1)。

図1●テストプロセスの全体像
[画像のクリックで拡大表示]

 主軸となるのはテスト計画、テスト設計、テスト実行の3つのプロセスだ。基本的にこの順番で実施する。テスト管理は3つのプロセスが計画通りに行われているかを確認し、うまくいっていない場合に対策を実行するプロセスとなる。テスト実行まで終わった後、品質に関する評価を実施して、プロジェクト関係者向けに評価を報告するのもテスト管理のプロセスだ。

 以下ではテスト計画、テスト設計、テスト実行の3つのプロセスについて、必須となる作業を紹介する。これは最低限の作業で、プロジェクトによってはほかにも必要な作業が存在する点は注意してほしい。

テスト計画で必須の6つの作業

 テスト計画は、ソフトウエアテストで最初に行うプロセスだ。何をテストするか、どのような種類のテストをするかを決め、それに従って役割分担やスケジュール、管理方法を検討する。テストの大枠を決めるプロセスだ。テスト計画が不十分だと、後続のプロセスであるテスト設計やテスト実行を場当たり的に進めることになる。時間やコストの無駄だし、やるべきテストを実施し損ねるといった抜け漏れにもつながる。

 テスト計画で実施する作業は(1)テスト対象の決定、(2)テスト種類の決定、(3)役割分担の決定、(4)準備対象の洗い出し、(5)スケジュールの決定、(6)管理方針の決定、の6つである(図2)。

図2●テスト計画プロセスの作業
[画像のクリックで拡大表示]

 (1)のテスト対象の決定では、テスト対象の範囲を決める。多くの場合、テスト対象のシステムはこの段階で既に決まっている。システムに搭載されている機能の中から、テストをする機能としない機能を決めることになるだろう。例えば、あるECサイトのテスト対象を考えるとする。どの機能をテスト対象にするかを検討して、「商品購入機能は修正対象なのでテストをするが、今回修正対象になっていない会員登録機能はバグ混入の可能性が低いため、テストをしない」といったことを決定する。

 (2)のテスト種類の決定では、実施するテストの種類を決める。テストには「機能を確認するテスト(機能テスト)」「性能を確認するテスト(性能テスト)」「使いやすさを確認するテスト(ユーザビリティテスト)」など複数の種類がある。ECサイトが保有している会員登録や商品購入といった機能を確認したいなら、機能テストの実施が必要だ。画面操作のレスポンスを確認したいなら、性能テストが必要である。

 (3)の役割分担の決定では、(2)で決めたテストを誰が担当するのかを決める。商品購入機能の機能テストはAチーム、画面のレスポンスはBさんといった具合だ。テスト設計以降にも複数の作業があり、作業ごとに担当を分ける場合がある。部門をまたいだ調整が必要になる可能性もあるため、大まかな作業(例えば、テストケースの作成、テストデータの作成、テスト環境の構築、テストの実行など)単位で役割分担を検討しておく。

 (4)準備対象の洗い出しとは、テスト環境やテストツールのようにテストが始まるまでに準備しておく必要があるものを洗い出して手配することだ。コストがかかったり、他社にも協力してもらう必要があったりする。検討が不十分だと、コストが上振れをしたりスケジュールが遅延したりと大きな影響がある。忘れやすいので注意が必要だ。

 (5)スケジュールの決定とは、いつからいつまでの期間で作業を行うのかの計画を立てることだ。作業や作成する成果物を洗い出し、各作業や成果物の作成にどのくらいの時間がかかるかを見積もる。(4)で洗い出したテスト環境やツールの入手、セットアップの計画もスケジュールに折り込む。

 (6)管理方針の決定では、テスト中の管理のルールや管理方法を決める。例えば、日々のテスト実行の進捗はどのように記録するのか、発見した障害はどう記録して共有するかといった事項を決定する。テストは複数の関係者が共同で行うことが多い。誰が何をどのようなタイミングで行うのかルールを決めておかないと、テスト中に混乱を招く。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら