プロジェクトマネジャーから 「一通りテストを実施したがどうも不具合が残っている。追加のテストケースを作っている時間もないので、とりあえず君の経験でテストをしておいてほしい」と頼まれた。 テスト経験もシステムに対する理解も深くはなかったものの、思いつくままにテストを行った。だが、結局何の不具合も出せないまま作業が終了してしまった―――。

 こうしたテスト担当者が直感的かつ自由な形式で検証を行うテストを「アドホックテスト」と呼ぶ。仕様書に沿って機能が正しく動作するかを確認する「単体テスト」や「結合テスト」「総合テスト」とは異なり、テストケースを作成しない。とはいえ、やみくもにテストを行えばよいということではない。テストを依頼する側、実行する側の双方がアドホックテストの役割や効果を理解していないと、冒頭のような駄目なテストに陥る。アドホックテストを正しく行うには、ユーザーが実際にどうソフトウエアを取り扱うのかという観点が必要だ。

 単体テストや結合テスト、総合テストでは、設計書に記載されている通りにソフトウエアが正しく動作するかを確認する。一方、アドホックテストで検出したいのは、ソフトウエアの設計段階で想定されない使われ方をした場合に発生する不具合だ。仕様書に記載されにくい観点や、開発者からすると意地悪な観点を組み入れることで、結合テストや総合テストで見過ごされがちな不具合を抽出する。

 アドホックテストの最大のメリットは、結合テストや総合テストとの組み合わせでソフトウエアの品質強化を図れること。これは2つの意味がある。1つは前述したように検出しようとしている不具合の性格が異なり、結合テストや総合テストの補完になること。もう1つは小回りの利く品質強化策であることだ。アドホックテストはほかのテストと比べて事前準備や実行時間が短時間で済む。つまり、通常のテストでは品質確保が不十分と判断した時点で追加的にアドホックテストの導入を決めたとしても、納期への影響は小さい。短納期化が進んでいる近年のソフトウエア開発の悩みに合致する解決策となる。

 今回はアドホックテストの導入効果を最大化するための「実行時に持つべきテスト観点」「テスト観点の形式知化」「導入の判断基準」について解説する。

この先は有料会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら