確認のためのテストと、バグを見つけるためのテスト
ソフトウェアのテストは、正しく動くことを確認するために行う場合と、バグを見つけるために行う場合の、２つのアプローチがある。どちらのアプローチで臨むかによって、テストのやり方は違ってくる。
正しく動くことを確認するアプローチでは、まず、確認すべき正しい『結果』を定める。これは通常、要求仕様書や機能仕様書、設計書などとして、テスト工程に進む前に既に文書化されているであろう。テストでは、それらの文書に記述されている通りの結果が得られることを確認する。
このアプローチは、いわば、結果を中心に組み上げる、結果指向のテストである。
これに対して、バグを見つけるためのテストでは、どのようなバグを見つけられるかを、予め定めておくことはできない。その代わり、バグを見つけるために何をやるか、を定める。事前の計画では、なるべくバグを見つけられるような手順を考える。テストではその手順を実行し、バグが見つかれば記録する。
このアプローチは、いわば、手順指向のテストである。
テスト項目は、バグを見つけるためのテストに適さない
一般的なソフトウェアテストは、下記のような流れで行われている。
- 仕様書や設計書を基に、テスト計画を立てる。
- テスト項目を列挙する。
- テスト項目に従って、テストを実施する。
テスト項目には、行うべき操作の手順と、期待される結果が書かれている。ソフトウェアの動作が、期待される結果の通りであれば、項目をクリアしたとして、検証結果の欄に○印が記入される。テストは、テスト項目をすべてクリアするまで行われる。
テスト項目には、期待される結果が書かれている。この形式は、結果指向である、確認のためのテストを行うのに適している。だが、手順指向である、バグを見つけるためのテストでは、期待される結果というものが無い。一般的なテスト項目の形式は、バグを見つけるためのテストには適さないのである。
期待される結果が無いと、手順そのものがテスト項目から抜け落ちてしまいやすい。すると、バグは見逃されることになる。つまり、テスト項目に従ったテストしか行っていない場合は、一通りの機能は正しく動作しても、まだまだバグが残っている可能性が高い。
バグを見つけるために、しっかり計画を立てよう
バグを見つけるためには、テスト項目に期待結果を書けないような、さまざまな操作をする必要がある。
とはいえ、やみくもにソフトウェアを使っているだけでは、バグは根絶できない。確認のためのテストと同様、実際にテストに着手する前に、しっかり計画を立てる必要がある。
初めに、どのような点についてどのようなテストを行うか、テストの方針を洗い出す。次に、それを基に、具体的に行うテストの手順を定める。最後に、テストを行う順序を、リスクや優先度を考慮して決める。
確認のためのテストと違って、バグを見つけるためのテストでは、正解が無い。思いつく限りの方針・手順を挙げていこう。ソフトウェアの設計や実装を意識して、どのようなバグがありそうか予想しながら行うと良い。また、類似ソフトウェアで行ったテストや、バグの再現手順なども参考になる。
効率良くバグを見つけるために工夫しよう
正しく動くことを確認するテストでは、納品・出荷されるソフトウェア製品そのものを使って、実際に動かしてみて、本当に正しい結果が得られるかどうかを確かめる必要がある。
だが、バグを見つけるためのテストでは、必ずしも製品そのものを使う必要はない。目的は、バグを見つけることである。より効率的にバグを見つけられる方法があれば、そちらを採用するべきである。
典型的な例をいくつか紹介しよう。
- コードレビュー
-
実際にソフトウェアを動かすよりも、ソースコードを読み直した方が、バグが見つけやすいこともある。例えば、排他制御や状態遷移の仕組みに潜むバグを見つけ出す時は、これに該当する。
ただソースコードを読むだけでなく、ソースコードから逆にシーケンス図やステート図といった設計図を作り直すというのも、良い方法だ。設計フェーズで作成した図と見比べると、バグが見つけやすい。
- ソースコードの修正
-
製品そのものではなく、テストのために少し手を加えたソフトウェアを使った方が、バグが見つけやすいこともある。
例えば、排他制御や通信、スレッドなどのタイミングに関するバグを見つけ出す時は、ソースコードの随所に適当なSleep文を入れて、Sleepの時間を変えつつテストした方が、バグが見つけやすい。
ユーザの立場になって使ってみよう
最近のソフトウェア開発では、ユーザが使いやすいソフトウェアを作るために、従来のような機能中心の考えではなく、ユースケース駆動型の開発が広く行われるようになってきた。
ソフトウェアテストでも、ユースケースに従ったテストが行われる。これは、確認のためのテストというよりも、バグを見つけるためのテスト、という趣が強い。つまり、ユーザの立場になって操作して、使いにくいところがないかを調べるのである。この場合、使いにくい、ということはバグと見なされる。
このテストで見つかるバグの例をいくつか紹介しよう。
ユーザにとって使いにくいと思った例
- ボタンを押しても、画面に何も変化がないので、ちゃんと処理が実行されたかどうか分からない。不安なのでもう一度押してしまった。
- うっかり変な数値を入力してしまうと、簡単にはやり直せない。すごい長い時間待たされてから、ようやくやり直すことができた。
- エラーメッセージが表示されたが、メッセージを読まずにうっかり閉じてしまったので、どう対応して良いか分からなくなった。
- 同じエラーメッセージが３回連続して表示されたので、いらいらした。
テストを始めてからも、テストを充実させていこう
実際にテストを始めると、ソフトウェアへの理解も深まり、勘も働きやすくなる。そのため、最初の計画では思いつかなかったような方針や手順が、テストを始めてから思いつくことも多い。その時は、テストを追加していこう。
バグを見つけるためのテストでは、効率的にバグを見つけることが最優先される。より多くのバグが見つかるのなら、テストが増えても構わない。
但し、新たに思いついたテストは、他のモジュールや機能にも適用できるかもしれない。また、リスクや優先度を考慮すると、後回しにした方が良いかもしれない。
そこで、新たにテストを追加する際は、テスト計画全体にも見直しをかける。
ある特定の機能やモジュールに偏向したり、費用対効果が低くなったりしないように、全体のバランスを保ちつつ、次第にテストを充実させながら、テストを進めていくことが重要である。
おまけ
バグを見つけるためのテストも、従来のテスト項目に含めて良いか？
バグを見つけるためのテストの手順は、期待される結果が無いので、従来のテスト項目には並べられないはずである。
しかし実際には、バグを見つけるためのテストを、確認のためのテストと区別せず、バグを見つけるためのテストの手順も、従来のテスト項目に含めていることも多い。
バグを見つけるためのテストの手順は、予め、起こりうるバグを予想して作ることも多い。この場合、テスト項目には、予想したバグを裏返して、「○○が起こらないこと」という期待結果を記入することができる。
だが、どうしても期待結果を書けない手順もある。それでもテスト項目に含めるために、期待結果の欄には「何も問題が起こらない」などと書かれていることもある。しかし、これは下記の２つの意味で問題である。
- テストの記録としては、虚偽の報告となる。
- テスターによって判定基準が異なり、テストの再現性が無くなる。
たとえバグを予想できる場合でも、それだけを確認すれば良い訳ではない。期待結果が書いてあると、予想しなかった問題が起きても、見逃してしまうかもしれない。
アプローチの違いを明確にするためにも、確認のためのテストと、バグを見つけるためのテストは、１つのテスト項目にまとめない方が良いだろう。
西康晴氏が挙げる、テストの４つの視点
電気通信大学の西康晴氏は、＠IT ソフトウェアテスト・ミーティング（2005年5月31日）で行われた基調講演「ソフトウェアテストの動向」の資料の中で、ソフトウェアテストの狙いとして、下記の４つの視点を挙げている。
| 視点 | 内容 |
|---|---|
| User-view（ユーザの視点） |
ユーザが何をするかを考える
|
| Spec-view（仕様の視点） |
仕様を考える
|
| Design-view（設計の視点） |
設計やソースコードを考える
|
| Fault-view（バグの視点） | 起こしたいバグを考える |
だが、これら４つの視点の中では、Fault-view（バグの視点）だけ位置付けが異なっているように思う。
ソフトウェアテストの分野では、ウォーターフォール型開発モデルにおける開発工程と品質保証との関係を、下図のようなＶ字型モデルで表す。
User-view（ユーザの視点）、Spec-view（仕様の視点）、Design-view（設計の視点）の３つの視点は、製造フェーズの要求分析、基本設計、詳細設計・実装の工程にそれぞれ対応するテストであるように思われる。
これに対して、Fault-view（バグの視点）は、テストに臨むアプローチを表している。
User-view（ユーザの視点）、Spec-view（仕様の視点）、Design-view（設計の視点）の３つの視点についても、確認のためのテストだけでなく、バグを見つけるためのテストというアプローチも必要であろう。