第3回 テストを設計するには（その1）：理論的・計画的なWebアプリケーションのテストの実現（1/2 ページ）

前回は、テストプロジェクトの目次となるテスト計画書とテストの種類を解説した。今回は、テストを設計するために必要となる知識について説明する。常にレビューやテストを考慮し品質への意識を持つことが重要である。

[加藤大受，ITmedia]

前回のまとめ

　前回はテストを一つのプロジェクトととらえ、テストプロジェクトの目次となるテスト計画書を作成することを説明した。テスト計画書のひな形としては前回紹介したIEEE std 829-1998が存在しているが、プロジェクト計画書のように、まずはどんなテストを行うかということが書かれた目次的なものを作成することを心がけていくとよいだろう。また、テストにはどのようなものが存在しているかについても前回簡単に触れている。

　今回はテスト計画書に書かれている各テストをどのように考えていくかについて説明していこう。

いきなりテスト要件を考えない

　テスト計画でどんなテストを実施するかを洗い出した後は、各テストの要件を洗い出す作業に入ると思われるかもしれない。しかし、これは間違いである。

　システムを開発する場合、ユーザーからの要求をRFP（request for proposal：提案依頼書）やヒアリングから要求定義としてまとめるのが一般的である。テストの場合も同様に、要求定義された内容からテスト要件を洗い出すのが望ましい。あるいは作成された要件定義書を品質の面からレビューし、実装フェーズに入る前に要件レベルでの欠陥がないかを確かめる必要がある。多くの読者の方々がすでに経験しているように、後工程になればなるほど、不具合や仕様の問題などのソフトウェアの欠陥を修正するのにかかる工数が増大する。できる限り早い段階から品質の面から要件や設計をレビューすることが望ましい。

　図1はウォーターフォール（Vモデル）での実装とテストの流れとの関係について簡単に図にしたものであるが、図のように実装の工程とテストの工程とをペアにすることで品質を高めることができる。

図1　実装の流れとテストの流れの関係（クリックで拡大）

品質はリスク分析であると考える

　すでに品質をリスクとして考えている方も多いと思われるが、まだリスク分析を行っていない方のためにも少し説明しておこう。おそらくテストを行っているときはバグが発見されることを想定し、発見するバグの数の予想、テストの設計、テストの実施をしているだろう。また、設計したテストを実施するときに優先順位を設定しているかもしれない。では、その優先順位はどのように決めているのだろうか。

　優先順位の決め方としては機能の重要度、つまり技術レベルから決めることが多いと思われる。しかし、もしバグがプロジェクト期間中に発見されず、本運用を開始した後に起きた場合、そのバグが引き起こす問題はビジネス的な要因も加味して考える必要がある。例えば、ユーザーが非常に少ないWebシステムであり、めったに起こることのないタイプの不具合だったとしても、そのシステムが保存している個人情報が流出してしまうような脆弱性だった場合、ビジネス的には非常に大きな損害を受けることが予想される。このような可能性を考慮すると、いかに小さなシステムであり可能性が低いパターンの問題を発見するためのテストであっても、それが引き起こすビジネス的なリスクが高いと予想されるならその優先順位は高くなるのである。

　品質をリスク分析として考える方法についてはすでに数多くの書籍などで紹介されているので、ここでは詳しい説明は省略するが、品質を考えることは常にリスクを分析することであるということを意識し、ビジネス的要因を加味してテストの優先度を考えるべきである。

次ページは単体テスト、機能試験、性能検証といったテストに関連する知識について