「探索的テスト」とは？
システム開発で従来行われてきた「記述式テスト（スクリプトテスト）」は、設計書や仕様書をベースにあらかじめテスト内容を考え、テストケースと呼ばれるドキュメントに記述して実施する手法です。記述式テストは仕様に対して網羅的にテスト出来ますが、事前準備に時間を要する上に、原則として作成した全テストケースを実施するため、システムの不具合が見つかる確率の低いテストも実施する必要がありました。
これに対して、新しい手法である「探索的テスト」では、テストを実施しながら次に行うテスト内容を考えていきます。具体的には、直前のテスト結果やテストした際のソフトウエアの振る舞いに着目し、臨機応変にテスト内容を決めることで、システムの不具合が潜んでいそうな箇所に対し集中的にテストを行います。テストケースのドキュメントを作成しなくて済むため、テストの事前準備が減り、効率よくシステムの不具合を発見することができます。テストの実施担当者に一定のスキルは要求されますが、仕様が未確定なまま開発を行った場合でも、設計書や仕様書に依存することなくシステムの不具合を発見できる点が優れています。
このように、記述式テストと探索的テストにはそれぞれメリットとデメリットがあるため、仕様に対して網羅的なテストを行う記述式テストと、不具合に対して集中的にテストを行う探索的テストを組み合わせ、両者を相互補完的に実施することが一般的に重要と言われています参考1、2、3。
図1：記述式テストと探索的テストのイメージ
「探索的テスト」の効果を高める管理手法
探索的テストは北米の企業などで活用が進むものの参考4、国内、特に金融機関や企業向けのシステム開発での活用事例はあまり多く見られません。これは探索的テストが以下のような問題を抱えていることが原因と想定されます。
- テストの内容を事前にレビューできないため、あまり効果的でないテストを実施してしまう。また、複数のテスト担当者で同じようなテストを実施してしまう。
- システム開発の委託元の企業やテストチームのマネージャーが、実施するテストの量や範囲を確認できないため、テストの計画を立てることができない。
このような問題に対して、Session-Based Test Management（セッションベースドテストマネジメント）参考5というテスト管理手法が注目されています。この手法では、テストを30分から2時間程度の細かな「セッション」に分割し、セッションごとにテストの目的やテストする機能を定めることで、複数のテスト担当者が同じようなテストばかり実施する状況を回避できます。テスト結果はマネージャーに日々報告され、マネージャーはシステムの不具合がよく発見される機能や発見される不具合の偏りを元に、以降のセッションを随時見直すことができます。また、テストする機能単位や1日単位でのセッション実施数を集計することで、テスト総量や進捗度合も確認できます。
図2：セッションベースドテストマネジメントのイメージ
NTTデータでは、従来型の「記述式テスト」だけでなく、「探索的テスト」をセッションベースドテストマネジメント手法と組み合わせて用いることで、効果的なテスト方法論の開発に取り組んでいます。
参考文献
- 参考1ソフトウエア品質知識体系ガイド-SQuBOK Guide-（SQuBOK策定部会、株式会社オーム社、2007年）
- 参考2ソフトウエアテスト教科書 JSTQB Foundation 第3版（湯本 剛、大西 建児、勝亦 匡秀、佐々木 方規、鈴木 三紀夫、町田 欣史、吉澤 智美、中野 直樹、翔泳社、2012年12月25日）
- 参考3探索的テストを活用したシステム開発手法の提案（熊川 一平）（PDF：37ページ, 979KB）(外部リンク)
- 参考4STATE of TESTING 2013（PDF：13ページ, 21,538KB）(外部リンク)
- 参考5Session-Based Test Management（James Bach）（外部リンク）
