アジャイル的な開発⼿法の⼀つである『探索的テスト』は、テスト設計やテストケース作成をせずに動くモノがあれば、軽くテストを始められるのが特⻑で、従来のスクリプトテストと⽐べて、バグ検出効率は数倍⾼いと報告されています。すでに多くの開発現場で実践されている⼿法ですが、JSTQB⽤語集では「⾮公式なテスト」としています。
⼀⽅、今から８年前に販売開始した弊社の『動的テストツール DT10』。初めて出展した技術展でのキャッチフレーズは、「バグ、減らせます！」。「グレーボックステスト」ツールとして、すでに導⼊実績は650社突破し、様々な開発現場でご愛⽤いただいています。

「バグに効く」「実機での動的なテスト」という共通点から、ブラックボックステストの『探索的テスト』が持つ弱みを、グレーボックステストの『動的テストツール DT10』で補完できないか？非公式なテストながらも、忙しい開発現場において活用できる『探索的グレーボックステスト』として確立できないか？『探索的テスト』と『動的テストツール DT10』の親和性とソフトウェアのQCD向上の施策を探索していきます。
※QCD：Quality・Cost・Delivery

まずは『探索的テスト』がどのようなものかを説明します。

CONTENTS
  1. 『探索的テスト』とは？
  2. 『探索的テスト』の強みと弱み
  3. 「⾮公式なテスト」の可能性を探索する 

『探索的テスト』とは？

『探索的テスト』の定義

規格などによる厳密な定義はありません。James Bach 氏が提唱した「学習、テスト設計、テスト実⾏を並⾏して実施するもの」といった内容が定義として引⽤されることが多いようです。
いつくか⽂献を調べてみて、別の⾔い⽅をすると、以下のようなことが要点になります。

  • 無駄になるかもしれないテストケースは、事前に作成しない。
  • テストを実施しながら、テスト結果や製品の振る舞いを⾒ながら、臨機応変に次にやるテスト内容を考える。
  • そして、バグが潜んでそうな部分を集中的にテストしていく。

バグは偏在する傾向にありますが、テスト設計段階で事前に潜伏箇所を特定することはできません。
テストケースに依存せずに、すぐに始められて、重要度や優先度の⾼い部分から実際の振る舞いを分析しつつ、バグ探しを効率的におこなうことができます。某⽜丼チェーンのコア・コンセプトではありませんが、「早く」て「安く」て「うまみ」のあるテスト⼿法です。決まった⼿順もないことから、⼿法と⾔うよりも、アプローチと⾔った⽅がしっくりくるかもしれません。

『探索的テスト』の活⽤フェーズ

⼀般的に『探索的テスト』は、『スクリプトテスト』との相互補完という形で活⽤されます。
品質保証のためのテストを『スクリプトテスト』で構築し、潜在バグ検出のテストは『探索的テスト』で補完するといった活⽤が⼀般的です。例えば、テスト変更を『探索的テスト』で担保して、『スクリプトテスト』の変更コストを削減するといった活⽤です。

『探索的テスト』には、テスト対象として動くものが必要となります。
V字モデルの開発プロセスの統合テストやシステムテストの上位のテストフェーズにおいて、ブラックボックステストとして主に活⽤されています。バグを早い段階で⾒つけるほど、回帰テスト⼯数が削減でき、QCDに良い影響が出ます。また、製品の利⽤⽬的や利⽤する状況、どのうような⼿順をするかといったユーザー視点で実施することで、ユースケーステストとして、仕様以外の不具合検出にも活⽤されます。

図1: 探索的テストの活用フェーズ

『探索的テスト』の強みと弱み

探索的テストの強み
  • テストケース作成工数、保存コスト削減

時間を掛けて、きっちりテストケースを作っても、すべてのバグは⾒つかりません。
『探索的テスト』の本来の⽬的である無駄を省くという考えのもと、ドキュメントは極⼒作りません。テストケースを作らないので、仕様変更やテスト順番の変更においても、メンテナンスが不要です。明⽂化しにくい操作や動作にも柔軟に対応できます。

  • 必要なところをピンポイントですぐテストできる

製品のソフトウェアのバグが潜伏してそうな弱点部分をピンポイントでテストできます。仕様が未確定なまま開発を⾏った場合でも、設計書や仕様書に依存することなくシステムのバグを発⾒することができます。

  • テスト実行時のマンネリ感が解消

『スクリプトテスト』は、⼤量にあるタスクを台本どおりにひたすらこなし続けるといった受け⾝の意識になりがちで、飽きやすく、けっこう眠くなる傾向にあります。
⼀⽅、『探索的テスト』は、⾃分の経験や想像⼒を活かし、バグが潜伏してそうな道(ルート)に当たりをつけて、バグを探り当てていく。あの「ポケ〇ン」的な要素があります。バグは⼈⽬がつかないところに隠れています。⾃らバグを探しに⾏かないと⾒つかりません。バグを⾒つけた時は、『バグ、ゲットだぜ！』と⾃慢ができます。レアなバグの発⾒は褒めてもらえるので、きっと楽しいです。徹夜でゲームする時みたいに、きっと眠くなることも無いでしょう。

 

探索的テストの弱み
  • テストする人のスキルによっては、「アドホックテスト」になりがち

「アドホックテスト」との違いは、事前の準備を必要とすることです。
『探索的テスト』は、事前にテストの⽬的やゴール、⽅針を決めてから実施します。⽬的や⽅針の有無により、テストの成果や得られる情報が変わります。また、テスト対象を動かしてみて得た情報、過去の不具合や製品の弱点などの事前の分析情報、テストする⼈の知⾒や思考(ノウハウ)をベースにして、頭の中でテスト設計をすることになります。製品やソフトウェア構造を理解し、バグの探索ができるノウハウやスキルを持つ⼈が望ましいとも⾔われます。

  • 記録が残しにくく、見つけたバグの再現性が低い

『スクリプトテスト』のような⼿順書はないので、不具合発⽣時の証跡を残しにくく、再現性を確保しくいです。

  • テストの網羅性に欠け、品質を保証しにくい

『スクリプトテスト』と⽐べると、事前に設計するテストケースのリストが無いので、テストの漏れ、ダブり、テスト結果の網羅性は分かりにくいです。

『探索的テスト』は「⾮公式なテスト」

『探索的テスト』はエビデンスを残さないことを基本的なスタイルとするので、『スクリプトテスト』と⽐べると、再現性、客観性、可監査性が乏しいです。「ベテランのテスターが探索的テストしたので、⼤丈夫です！」と説明しても、お客様には受け⼊れられません。『探索的テスト』の結果から品質状況を説明するのは、難しいです。バグ検出効率が⾼いテストながらも「⾮公式なテスト」であるため、内部的なQCD向上施策として実施することになります。

「⾮公式なテスト」の可能性を探索する

『探索的テスト』がどのようなものか、イメージを掴んでいただけましたか？
「早く」、「安く」できる使い勝⼿や効率が良いテスト⼿法でありながら、テスト実施による成果としては、「⾮公式なテスト」という点でテスト結果を品質保証として扱えない。また、テストする⼈のスキル次第ではバグが⾒つからない。再現性が低い。というように、場合により「うまみ」を⼗分に引き出せない結果になってしまいます。
しかし、これらの弱みを改善できれば、『探索的テスト』の効率効果がさらに⼤きくなることも考えられます。
次回は、『探索的テスト』の進め⽅をご紹介します。

関連記事「チャレンジ！『探索的グレーボックステスト』」シリーズ
ハートランド・データの動的テストツールをぜひお試しください。

無料のトライアルをご用意しています。
－ 「動的テストツールDT+」の詳細はこちらから －

＜参考文献＞

高橋寿一「知識ゼロから学ぶソフトウェアテスト【改定版】」翔泳社
テスト技術勉強会 井芹 洋輝「探索的テスト入門」
三菱電機メカトロニクスソフトウエア株式会社 都築将夫 「探索的テストの適用事例」
株式会社NTTデータ 熊川 一平　「探索的テストを活用したシステム開発手法の提案」