テストの新たなアプローチ - レビュー(1)

ここで取り上げるレビューとは、プロジェクトの計画や進捗を確認するプロジェクトレビューではなく、ドキュメントやコードなどの開発の成果物に対するレビューです。

手法としてはインスペクションやウォークスルーなどがありますが、これらの手法に依存しない、テスト設計や実施の観点でレビューするアプローチを紹介します。これを進める上でのポイントは大きく分けて2つあります。

テスト容易性を持つかどうか

1つは「テスト容易性を意識したレビュー」です。

ISTQBの用語集では、テスト容易性を「変更されたソフトウェアがテストしやすいかどうかを示すソフトウェア製品の能力」と説明しています。しかし実際は、変更されたソフトウェアだけではなく、新規に作成したソフトウェアでもテスト容易性を考慮する必要があります。

テスト対象がテスト容易性を持つかどうかの判断材料として、以下の3つを挙げて説明します。

1.テストで検証/評価できるチェックポイントがあるか

テストケースで確認項目(期待結果)に「正しく機能/動作すること」と書くことは、典型的な悪い書き方の例です。「正しさ」は人によって異なる可能性があるからです。したがってテストケースには、「何を確認すれば良いのか」を明記しておく必要があります。実際には、仕様書の内容を確認する手段が用意されていなかったり、テスト対象の構造に問題があったりして、「何を」を特定できないケースも珍しくありません。それでも、テストのための備えは実装前に明らかになっていないと手遅れになることがほとんどです。

2.テストで検証/評価できる状態を作り出せるか

「1万アクセスかつ100のシナリオが特定のタイミングで発生しないと起こり得ない」という仕様をどのように確認すればよいのでしょうか? このような状態を作り出すことは現実的には難しいでしょう。他にも、手動テストだととらえきれないことはたくさんあると思います。このようなケースでは、テストツールを使ったテストの自動化や状態観察のための手段が必要となります。また、状態変化を人為的に遅延させたり、中止したりするための仕掛けの検討も必要でしょう。これも計画と準備が不可欠ですから、設計段階であらかじめ確認しておくべきです。

3.テストで検証/評価しきれるかどうか

コンポーネントテストでモジュール間インタフェースを確認するケースを考えてみましょう。図2のように5つのモジュールがつながっているとします。この図の左側のように相互の依存関係が複雑に絡まっている場合、インタフェースレベルのテストで確認すべきパスはすぐに爆発してしまいます。このモジュール間インタフェースの流れを図の右側のように整理できれば、テストすべきパスは劇的に減るはずです(注:これはいわゆる凝集度と結合度の問題です)。このようなことも、モジュールの設計が終わった段階で気付くのでは遅すぎます。

執筆者プロフィール

大西建児 (Kenji Onishi)
株式会社豆蔵 シニアコンサルタント。国内電機メーカー、外資系通信機器ベンダーで培ったテストや品質保証などの経験を生かし、テスト手法や技術の普及、発展に取り組む。NPO法人ソフトウェアテスト技術振興協会(ASTER)副理事長。JaSST’08東京 共同実行委員長。著書に「ステップアップのためのソフトウェアテスト実践ガイド」(日経BP社)などがある。

『出典:システム開発ジャーナル Vol.3(2008年3月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。