テスト計画の立案：開発プロセス再入門（7）（1/2 ページ）

[津田義史（豆蔵），＠IT]

　今回は、どのビルドでどのようなテストをすべきかを計画する方法について説明します。ソフトウェア開発プロジェクトでは、いろいろな計画を立てなければいけませんが、テスト計画はその中でも大事なものです。テスト範囲とテスト戦略、QA要員やテストに必要なソフトウェア／ハードウェアなどのリソース調達、そしてスケジュールなどについて、テスト計画書を記述します。また、具体的なテストケースの記述と、この実施についても計画しなければなりません（一般に、テスト計画書の中にはテストケースは含まれません）。一口にテストといっても大変に奥が深く、テストのすべてを包括的に説明しようとすれば分厚い本が書けてしまうほどですが、今回は反復型開発において注意すべき事柄に的を絞って説明したいと思います。

テストの目的

　テスト計画を立案・実施する前に、なぜそのテストをするのか、そのテストの目的を明らかにしておきましょう。ソフトウェア開発プロジェクトの各フェイズにおいては、さまざまな目的のためのテストを順に実施していくのですが、ここではテストの目的を狭義に「ソフトウェアに潜む不具合を発見するため」ととらえます。この目的を達成できないテストは、品質が悪いテストです。

　例えば、あるテストを実施したとき、不具合が1つも見つからなかったとします。この場合、次の2つの可能性が考えられます。

• ソフトウェア（テスト対象）の品質が高い
• テストの品質が低い

　 しかし、リグレッションテスト（回帰テスト）の結果であればともかく、開発中のソフトウェアで不具合が1つも見つからないというのは考えられないことです。実際のところ、テストを実施した結果、不具合が1つも見つからなかったとしたら、間違いなく実施したテストの方の品質が低かったと考えられます。そのようなテストは、実施する価値がありません。

　開発者は、可能な限り不具合を出さない、というゴールを設定して作業してもよいでしょう。しかし、QAは可能な限り不具合を出す、というゴールを設定して作業すべきです。「品質の良い製品を顧客にリリースする」という開発者とQAの最終的な目的は同じですが、これをブレイクダウンした個々の作業の目的は異なってきます。

　この連載の第1回「だれも書かなかった反復型開発のホントの姿」でも簡単に説明しましたが、いま自分がどの帽子をかぶって、どのような役割（ロール）でプロジェクトに参加しているのか、その役割における作業の目的は何か、強く意識できなければいけません。開発者とQAを兼任する人は、特にそうです。開発者は、どうしても「正しく動くことを確認する」という視点でテストを行いがちですが、それはテストを実施する際の姿勢としては正しくありません。開発とテストは違う人が行うべきだ、とはよくいわれることですが、その理由の1つがここにあります。繰り返しますが、テストの目的は「不具合を発見する」ことです。テストをして不具合が1つも見つからなかったとき、それを誇らしげに報告すべきではないでしょう。もちろん、同件の不具合を重複してたくさん報告してもいけません。

　そして、テストとは際限のない作業です。ちょっとしたソフトウェアであれば、すぐにテストケースの数（操作手順や入力データが取り得る場合の数）があふれてしまうのは、皆さんがご存じのとおりです。ソフトウェアが取り得る状態をすべて網羅するテストケースを記述し、それを実施することは困難もしくは不可能です。このため、より不具合を発見できる可能性の高いテストケース、致命的な（修正が必須となる）不具合を漏れなく発見できるテストケースを効率的に記述していくことが必要です。

　つまり、テストを計画するときは、

• どこまでテストするのか（テストの範囲）
• どのように不具合を効率的に発見するのか（テストの戦略）

といった視点が重要となります。

テストの種類

　ソフトウェア開発におけるテストには、次のようなものがあります（テストに関する用語は方言が多く、同じ語が複数の意味で使われます。以下は、筆者が認知度が高いと思う順に並べています）。

• ソフトウェアを構成する最小の単位において実施する単体テスト（unit test）
• ソフトウェアの各部品を部分的に結合したものが、意図どおり協調動作するか検査する結合テスト（joint test）
• 製品の体をしたものに対して行う統合テスト。システムテストともいう（integration test、system test）
• 実装した機能が、意図どおりに動作するか検査する機能テスト（functional test）
• 期待した処理速度が確保できているか検査する性能テスト（performance test）
• 大量のデータを処理させても、問題なく動作するかを検査する負荷テスト。性能テストの一種（stress test）
• 一度パスしたテストをすべて試行し直し、最新のビルドでもすべてのテストがパスするか検査する回帰テスト（regression test）
• 納品されたソフトウェアを検収する受け入れテスト（acceptance test）
• 中の仕組みが分かっているものを検査する論理依存テスト（white box test）
• 機能は分かっているが、中の仕組みは不明のものを検査する入出力依存テスト（black box test）
• ソフトウェアを正しく導入／除去できるか検査するインストール／アンインストールテスト（install／uninstall test）
• 意図したソフトウェアが構築可能かどうか検証する実現可能性テスト（feasibility test）
• QAにリリースする前に、施したはずの実装や不具合の修正が正しく行われたかどうかを（開発者が）検査する候補テスト（candidate test）
• QAにリリースされた後、施されたはずの実装や不具合の修正が報告どおりに行われたかどうかを（QAが）検査する確認テスト（verification test）

　このほか、使いやすさテスト（usability test）、機密保持テスト（security test）、互換性テスト（compatibility test）、回復テスト（recovery test）、文書テスト（documentation test）など、いろんな側面での検査があります。テストは、異なる側面から、複数のカテゴリに分類することもできます。

　例えば、すべてのテストは単体テストと統合テスト（あるいはその中間の結合テスト）のどちらかに分類できるともいえますし、別の側面ではすべてのテストはホワイトボックステスト（論理依存テスト）とブラックボックステスト（入出力依存テスト）のどちらか（あるいはその中間のグレーボックステスト）に分類できます。この文章中で説明するテストとは、すべて統合テスト、つまりQAにリリースした（もしくはその候補となる）ビルドを対象としたテストです。

　ソフトウェアの各開発工程においては、注目すべき品質の側面に合致するテストを順に実施していきます。例えば、最初のビルドでは実現可能性テスト、パフォーマンステスト（性能テスト）、負荷テスト、アルファビルドでは機能テストやインストールテスト、ベータビルドでは機能テストに加えてインストール／アンインストールテスト、互換性テスト、文書テスト、最終ビルド（候補）ではリグレッションテスト（回帰テスト）といった形で、実施するテストの位置付けが変わっていきます（もちろん、テストはマイルストーンビルドに対してだけ行うものではありません。ウイークリービルドに対しても順に実施していきます）。また、これは一例であり、違う順でテストを計画することもあります。●テスト計画

　前述したように、テストの計画の中にはいろいろなものが含まれますが、ここではテストケース記述とテスト実施計画について説明しましょう。まず、ユースケースや画面仕様、そして（初期の）ビルドをインプットとして、テストケースドキュメントを記述します。そして、このテストケースドキュメントをインプットとしてテストを実施します。

　テスト計画の立案には、トップダウン的なアプローチとボトムアップ的なアプローチがあります。トップダウン的なアプローチでは、最終ビルド候補をビルドする日時を最初に決め、これに合わせて各機能の実装とテストが終わるように計画していきます。ボトムアップ的なアプローチでは、どのようなテストが必要か、また各テストに必要な工数はどれだけかを見積もり、テストを計画します。実際には、この両方の要素を考慮しながらスケジュールを引くことになるでしょう。

　ユースケースは、テストケースを記述するときのインプットとして利用できます。ただし、ユースケースとテストケースでは、仕様について注目すべき側面と記述の粒度が異なります。ユースケースは、システム化する範囲を決め、そのシステムがユーザーに提供する価値を正しく定義するために記述するものです。ユースケースにおいては、その正しさが最も重要であり、その精度は二の次です。オブジェクト指向開発が失敗する大きな要因の1つが、ユースケース記述に時間をかけ過ぎてしまうことです。精度が高くても、正確であるとは限りません。精度の高過ぎるユースケースは、それが正しくなかった場合に、修正するためのコストが大きく掛かってしまうため、詳細過ぎるユースケースが記述されていることは、むしろプロジェクトが失敗してしまう兆候です。

　これに対してテストケースは、ソフトウェアの仕様すべてを高い精度でドキュメント化します。テストケースには、テストを実施するために詳細なテスト手順と、そのテストにパスしたかどうか明確に判断するに十分な情報が記述されていなければいけません。このため、ユースケースだけをインプットとしてテストケースを書くことはできません。画面仕様書や運用手順書などに記述されていることもすべて、漏れなくテストケースドキュメントの形にする必要があります。テストケースとは詳細な、つまりその仕様が正しく実現されているかを検証可能な、仕様書なのです。

　このため、開発の初期の段階で、完全なテストケースドキュメントをすべて手に入れることはできません。最初から精度の高いテストケースをすべて記述しようとすれば、それは（精度は高くても）不正確なものになってしまう可能性が高くなります。開発の初期の段階で詳細なテストケースをすべて書き上げ、これをそのまま凍結できれば、ソフトウェア開発の見積もりはずっと簡単になることでしょう。しかし、現在の計算機は高性能であり、また顧客も計算機を使って何ができるのか理解していないことも多く、開発を進めながら顧客の要求を発見／発明していくことも必要です。

　だからといって、開発も末期になってから、すべてのテストケースの詳細化を完了すればいいというわけではありません。テストは開発と並行して実施していかなければ間に合いません。なるべく早い段階で、開発におけるリスクを発見するのもテストの役割の1つだからです。そして、テストの実施時には、テスト手順とテスト結果の判断基準が完全に記述されたテストケースが必要となります。つまり、すべてのテストケースを少しずつ詳細化していくのではなく、ある段階ごとに、完全な形で記述された（詳細化された）テストケースをインクリメンタルに追加していく必要があります。

　開発の初期の段階では、精度を求めても問題ない、早い段階で仕様をフリーズ可能な部分から、テストケースを作成していかなければなりません。反復型の開発プロセスでは、仕様を段階的に詳細化していくことが肝心です。テストケースを記述する順を誤るということは、仕様を段階的に凍結していくことに失敗するということです。テストを計画するときは、どの段階（どのビルド）までに、どの機能のテストケースを誰が用意するのか、そしてそのテストをどのビルドから誰が実施するのか、を計画するわけです。これにより、QAチームがプロジェクトに参加する時期も決まってきます。テスト計画はビルド計画と一緒に立案する理由がここにあります。

　残念ながら、テストケースを管理するためのツールには、デファクトスタンダードと呼べるものはありません。これは、ソフトウェアのドメインによってテストケースの書式が大きく異なるからなのかもしれません。テストケースの詳細な書式や記述方法については、この文章中では説明しません。もっとテストケースについて知りたい人は、「ソフトウェア・テストの技法」(Glenford J.Myers著、松尾正信訳、近代科学社）、「ソフトウェアテスト技法」(Boris Beizer著、小野間彰／山浦恒央訳、日経BP出版センター)「基本から学ぶソフトウェアテスト」(Cem Kaner／Jack Falk／Hung Quoc Nguyen著、テスト技術者交流会訳、日経BP社)」などが良い道標になるでしょう。