テスト項目のレビューは無理
開発も終わりに近づくと、チームの一部のメンバーは、テストの準備に取り掛かる。準備を任されたメンバーは、しばらくは作業に没頭しているだろう。そしてある日、膨大なテスト項目を書き連ねた文書を見せて、こう言って来る。「できました。レビューして下さい」。
ソフトウェアの品質は、テストにかかっている。テスト項目が不十分であれば、バグが見逃され、できの悪いソフトウェアをリリースしてしまうことになる。だから、膨大なテスト項目でも、１つずつ目を通して、レビューを行うことになるだろう。
だが、この作業は、極めて大変で困難なものである。
テスト項目は、たいていは一覧表の形になっている。１つ１つの項目には、テストする操作の手順と、実行結果が書かれている。テスト結果を記入するための空欄も用意されているだろう。
膨大なテスト項目が並べられた巨大な一覧表のすべてに目を通し、内容をチェックする。気の遠くなるような作業だ。それでも、責任感のある開発者は、何としてもやり遂げようとする。だが、その努力は報われないだろう。
テスト項目の一覧表は、テストを効率良く進めていけるように、項目を順に羅列したものだ。何をやるかは書いてあるが、何のためにやるかは書いていない。テストを実施するには適した形式だが、内容を理解して、正しいかどうかをチェックするには、まったく不向きだし、不可能でもある。これをレビューしようというのが、そもそも間違いなのだ。
「できました。レビューして下さい」。無理です。
テスト項目はどこから出てきたのか？
そもそも、テストの準備を任されたメンバーは、どのようにして膨大なテスト項目を考え出したのだろうか。
テスト項目が出来るまでのプロセスは、図のようなモデルで表されるだろう。
テスト項目の元になるのは、機能仕様書や設計書といった文書である。それらの文書に書かれている内容を、テストの方針に従って書き換えたものが、テスト項目になる。
文書を入力とし、テスト方針という関数を通すと、出力としてテスト項目が挙がる、というのが、テスト項目が出来るプロセスである。
テスト項目の元になる文書や、テストの方針をレビューしよう
テスト項目の元になる文書と、テストの方針。この２つに抜けや誤りが無ければ、そこから作り出されるテスト項目も、十分であると言える。
テスト項目と違って、この２つは、人が読んで理解したり、内容を検証したりしやすい。よって、テスト項目のレビューとしては、実際に項目を挙げる前に、これらの２つを対象にレビューを行おう。
テストのために文書をレビューする
機能仕様書や設計書といった文書は、これまでもすでに作成してきているし、レビューも行ってきているだろう。
だが、機能仕様書は設計のため、設計書は実装のために作る文書である。設計や実装を行うために必要な、最小限のことしか書かれていないかもしれない。レビューでも、設計や実装に支障があるかどうか、という点しかチェックしていないかもしれない。
テスト項目の正しさを検証するためのレビューでは、従来のレビューとは違った観点から、これらの文書をチェックする必要がある。
例えば、エラーが発生した時のログ出力の方式などは、後で考えればいいや、ということで、機能仕様書や設計書では記述が省かれているかもしれない。それでも、設計や実装には特に問題なく進めたかもしれない。だが、このままでは、テストではログ出力に関するテスト項目が完全に抜け落ちてしまうことになる。
これまでの文書の作り方に対する改善のアプローチとしては、具体的には下記の２通りが考えられるだろう。
- テストの前に見直しのレビューを行う
-
機能仕様書や設計書を作成した時点では、これまで通りのレビューを行う。テストの前に、テストのためにもう一度レビューを行う。
但し、テストのためにレビューする時点では、すでに設計、実装まで終了しているので、何か抜けや誤りが見つかると、手戻りが発生することになる。
- テストを見据えて文書を作る
-
機能仕様書や設計書を作成する時点で、目先の設計や実装のことだけでなく、将来のテストのことまで見据えて、文書を作るようにする。
テストという新たな視点から、文書を多角的に見ることで、抜けや誤りをより減らすことができる。また、要件定義や設計という早い段階で問題点を洗い出すことができ、リスクの軽減にも繋がる。
テスト方針を文書化してレビューする
これまでも、テスト項目を挙げるためには、何らかのテスト方針は頭の中に思い浮かべていたはずである。だが、出来上がったテスト項目をレビューする、というこれまでの方法では、テスト方針は文書という形では残されていなかったかもしれない。
テスト方針として、テストに臨む上でのさまざまな切り口を洗い出し、文書としてまとめる。
例えば、ある名簿管理システムでは、名前を入力する欄が２ヶ所にあるとする。名前の入力に関する妥当性のチェックは、共通の関数を呼び出して行っているとしよう。このケースでは、名前の入力に関するテスト方針は、次のようになるだろう。
名前を入力する欄のテスト方針
- ちゃんと共通関数を呼び出しているかどうかのテスト
- ２ヶ所それぞれで実施する。
- 共通関数のテスト
- どちらか１ヶ所で実施する。
- 共通関数のテスト
- 入力できる文字
- 空白（全角／半角）
- アルファベット（全角／半角）
- 数字（全角／半角）
- 記号（全角／半角）
- 日本語
- 入力の方法
- キー入力
- コピー＆ペースト
- 名前の書式
- 空白による苗字と名前の区切り
- 外国人の名前
- エラー
- 空
- 文字列の長さ制限
- 名前の重複
また、ダイアログ画面を持つアプリケーションでは、たいてい、テスト方針は次のようになるだろう。
ダイアログ画面のテスト方針
- モーダルかモードレスか
- モードレスの場合
- フォーカスの移動
- ダイアログに関連するパラメータの変更
- 同じダイアログをもう１つ表示
- 画面を閉じる順序やタイミング
- OK／キャンセル／適用
- リターンキー／エスケープキーの入力
- タブオーダー
- ラージフォント／スモールフォント
- スペルミス／用語の統一
- フォーカスの移動
- アプリケーションの他のウィンドウに切り換え
- アプリケーションのメインウィンドウに切り換え
- ウィンドウの最小化
- タスクバーから他のアプリケーションに切り換え
- Alt＋Tabキーで他のアプリケーションに切り換え
- Windowsメニューから他のアプリケーションを起動
テスト項目を書き出す前に、このようなテスト方針に抜けや誤りがないかをチェックする。
テスト項目は、テスト対象のソフトウェアに強く依存している。良く考えられたテスト項目も、他のソフトウェア開発には流用することはできない。
それどころか、ソフトウェアの機能追加や仕様変更があった時も、以前のテスト項目は使えなくなってしまう。ただテスト項目を残しておくだけでは、ソフトウェアの改造に際しての回帰テストすら、満足に行えないだろう。
テスト項目は、テストを実施するためだけの使い捨ての文書なのだ。
テスト方針を残すようにしておけば、たとえ機能追加や仕様変更があった時も、方針を少し手直しするだけで済む。変更のあった点だけ、改めてテスト項目を挙げ直すことも容易になる。
さらに、テスト方針は、１つのソフトウェアに特化しない、汎用的なものになることも多い。一通りのテスト方針を確立すれば、それはいくつものソフトウェア開発で利用できる、共通の資産となるだろう。
テスト項目を挙げる前にレビューを行うことは、テストの抜けや誤りを無くすだけでなく、テスト方針という資産を生み出すことにも繋がるのだ。