PR

暗黙知任せのアドホックテストはもうやめよう

 こうしたテスト観点を利用すると、異なるメンバーがアドホックテストを担当しても同様の不具合を発見できる。ところが、実際の現場ではアドホックテストのテスト観点の形式知化が進んでいない。担当者の暗黙知任せになっているのだ。そのためか「アドホックテストはほかのテストよりもテスト担当者に経験やセンスが求められる」という言説が多い。

 もちろん、対象のソフトウエアを知り尽くした高スキルのテスト担当者がいる場合は、その担当者の経験と勘が大いに生かされる場合もある。ただ、実際の現場で予算・時間・人員のリソースがそこまで恵まれているのはまれだ。アドホックテストを担当するエンジニアが、必ずしも経験やセンスに長けているとは限らない。そのような場合にはテスト観点の形式知化が重要となる。

 筆者が担当する現場では、対象と同一または類似したソフトウエアから検出された過去の不具合のデータを蓄積し、分析した上でチェックリストを作成している。このチェックリストを活用すると、テスト経験の浅いテスト担当者もアドホックテストの勘所がつかみやすい。必要な観点を押さえたアドホックテストを実施できる。従来の暗黙知に頼るアドホックテストに比べると、スキルや経験のみに頼り切りになることがなく、品質の標準化が図れる。

 ただし、チェックリストはあくまで対象のソフトウエアに起こりやすい不具合の特性を知るためのヒントである。チェックリストのテスト観点を参考にテストを実施し、その際に生じた気づきから発想をふくらませて新たなテスト項目としていく。

導入するか否かの判断基準は「テスト密度」と「バグ密度」

 通常、プロジェクトの見積もりやテスト設計の段階ではアドホックテストの実行を計画しない。対象のソフトウエアに品質強化が必要となった場合に導入する。その際、代表的な判断基準となるのが「テスト密度」と「バグ密度」だ。

 テスト密度とは、プログラムのステップ数(LOC)に対するテストケース数のこと。バグ密度とは、プログラムのステップ数に対する適正な不具合検出数の指標値のことだ。一般にプロジェクト立ち上げ段階で、テスト密度とバグ密度の達成基準値(品質基準値)を設定する。単体テスト、結合テスト、総合テストなどのテストフェーズをすべて完了したにも関わらず、達成基準値内に不具合が収まらない場合にアドホックテストを実行するといい。

 アドホックテストは「仕上げのテスト」という面もある。結合テストや総合テストなどの基本的なテストを実施して得られる仕様書に沿った最低限の品質(当たり前品質)に加えて、アドホックテストを実施すればユーザーの期待値を超える品質(魅力品質)のソフトウエアを提供できる。筆者はこうした側面に着目しており、あらゆるプロジェクトにおいて短時間でもいいのでアドホックテストの導入を推奨している。

喜多野 宗夫(きたの としお)
SHIFT ビジネストランスフォーメーション事業本部 エンタープライズビジネスユニット
喜多野 宗夫(きたの としお) SIベンダーでパッケージソフトの開発業務に従事。上流工程から下流工程まで一連の開発工程を経験した後、ソフトウエアの品質保証業務を専業とするビジネスの可能性に惹かれて2013年にSHIFT入社。複数の金融系システムの開発プロジェクトに品質保証の観点から参画。プロジェクトの推進や品質分析を得意とし、現在ではアジャイル開発プロジェクトにおけるテスト・品質保証にも注力をしている。