QbookジャーナルQBOOK JOURNAL

テスト経験を最大限に活かす手法「探索的テスト」とは?

執筆者:高木 陽平

テスト経験を最大限に活かす手法「探索的テスト」とは?

皆さんは「探索的テスト」というテスト手法をご存知でしょうか?探索的テストは、経験ベースと言われるソフトウェアテスト手法の1つです。テスターの経験や直感を最大限に活かしたテスト手法であり、テストケースやテスト手順を作成しないで、テストが実施される場合が多いのが特徴です。本記事は、探索的テストについて、筆者が2年間に渡って実践してきた結果、学んだことを紹介していきます。

第1回は、探索的テストとは何かを俯瞰したあと、探索的テストのメリットとデメリットに言及いたします。

筆者プロフィール

yohei_takagi.jpg
高木 陽平

Executive Director, Valtes Advanced Technology

バルテスのフィリピン子会社であるVALTES ADVANCED TECHNOLOGY INC.の取締役で、現地責任者である。今まで、多数のソフトウェアテストやテストプロセス改善の業務に従事。2019年に、Stuart Reid博士が開発したISO29119トレーニングのトレーナー用トレーニングを、Stuart Reid博士本人より教わり、日本人初のISO 29119トレーニングトレーナーとなる。ISO 29119 Certified Tester、JSTQB初の完全上級テスト技術者(テストマネージャ、テストアナリスト、テクニカルテストアナリスト)の資格を保有。

ソフトウェアテスト手法『探索的テスト』とは?

私(高木)は、バルテス株式会社のフィリピン子会社 VALTES ADVANCED TECHNOLOGY Inc.(VAT)の現地責任者として、2018年から探索的テストを企画・サービス化し、推進してきました。サービス開始以来、現在では年間数十件の探索的テストを現地で実施するまでに成長しています。中には「製品出荷前はバルテスで探索的テストを実施してからでないと出荷しない」というお客様もいらっしゃいます。このように、今では多くのお客様が弊社の探索的テストに頼っていただけるようになってきています。しかし、最初から多くのご支持があったわけではなく、ここまでくるのに多くの試行錯誤がありました。その試行錯誤を今回はご紹介したいと思います。

経験ベースのソフトウェアテストの一つである探索的テストは、仕様把握、テスト実施内容の決定、テスト実施の3つを同時に実施していきます。この時、基本的にテストケースを作成せず、ソフトウェアの振る舞いや結果をみて、次に何のテストをするか決めていくことになります。例えば、この機能でバグが出たので、もう少し深掘りをしてテストをしようとか、この機能は大丈夫そうだから次の機能のテストをしようとかになります。つまり、探索的テストとは、予めテストケースを作成しないで、テスターが頭の中でどのようなテストをするかその都度決めて、次々にテスト実行していくテストになります。

探索的テストは、Cem Kaner氏が著書「Testing Computer Software(邦訳:基本から学ぶソフトウェアテスト)」の中で、「進化型アプローチ」として紹介しました。その後、「Lessons Learned in Software Testing(邦訳:ソフトウェアテスト293の鉄則)」で、探索的テストとなりました。日本では、Cem Kaner氏に直接師事した高橋寿一氏の著書「知識ゼロから学ぶ ソフトウェアテスト【改訂版】」で詳しく紹介されました。さらに、世界のソフトウェアテスト資格のデファクトスタンダードであるISTQB(日本ではJSTQB)で、経験ベースドテストの一つの手法として紹介されています。

それでは、探索的テストについて詳しく見ていきましょう。

探索的テストのメリット

私の経験上、探索的テストを実施する上での大きなメリットは次の3点であると考えます。

  1. テスト実施中の気づきを、テストに反映しやすい
  2. 相対的にコストが安くなる
  3. すぐにテストを実施できる

1. テスト実施中の気づきを、テストに反映しやすい

テストを進めていくと、システムに対する理解がより深くなったり、仕様書に載っていない機能や微妙な違いに気づいたり、システムの不具合傾向が見えてきたりします。それにより、テストの新しいアイディアが出てきます。そのアイディアは大抵、あらかじめ決めたテストケースよりも質が良いです。なぜならば、実際にシステムを動かして試せた方が、テストケース作成の難易度が数段易しくなるからです。習熟度が高まってから、テストケースを作成した方がテストケースの質が高くなるのは自明です。最近はソフトウェアの大規模化、複雑化が進み、全ての仕様を事前に把握することが難しくなっている事情もあると思います。

初めにテストケースを作成してからテスト実施すると、実施中に浮かんだアイディアはテストに反映されにくくなります。一番大きな理由は、タイムプレッシャーでしょう。テスト実施はソフトウェアライフサイクルの最終工程であり、時間的余裕がない場合がほとんどです。

ステークホルダーからの強いプレッシャーにより、テストを消化すること以外に時間を割くのが困難な場合が多く、あとでやろうと思ってもテスト実施に忙殺され、せっかく思いついたアイディアも忘却の彼方に消えてしまいます。また、時間的余裕がない状況で、承認されたテストケースを変更するのは勇気がいります。致命的な内容でない限り、そのままでいこうとなってしまうでしょう。その結果、テスト実施時に思いついた質の良いテストは、永久に実施されることの無いまま消えていくことになります。

一方、探索的テストは、テストケースを作成しないため、テストを実施しながら次のテストを決定します。よって、テスト実施中に思いついた良質なアイディアをテストに反映しやすいと言えます。例えば、あるシステムのテスト中、特定のブラウザでの不具合が多いことに気づき、そのブラウザでの試験を手厚くして、多くの不具合を検出した事例があります。

他にも、テストを行っている最中、プロセスの途中でネットワーク障害がおこるとシステムがロックされてしまうことに気づき、異常状態を多く実施(意地悪テストを含む)するようにし、複数のクリティカルな不具合を未然に防いだ事例もあります。逆に、ある機能が複雑でバグが多いと予想していましたが、品質が良く早々に次のテストに移行した事例もあります。複雑であるがゆえに気を付けて開発しており、逆に他の機能より品質が良かったようです。

このように、テストの途中で不具合が多そうな箇所(デフェクトクラスターと言います)を見つけ、そこのテストを手厚くしたり、逆に品質が良い箇所はツボを押さえたテストのみにしたりするなど、テスト実施中の気づきを柔軟に反映できるところに大きなメリットがあります。

2. 相対的にコストが安くなる

テストケースを作成する場合、テストする内容をあらかじめ決める必要があります。そのテストケースを作成するにも、仕様理解やテスト設計などの工程を経る必要があります。その工程で、ドキュメントが作成されます。ドキュメントは、アイディアの言語化であり、相応のコストが必要になります。また、ドキュメントは、成果物であるため、厳密性が必要になってきます。その厳密性を確保するために、確認作業も必要になってきますし、メンテナンスも必要になってきます。

一方、探索的テストは必要最小限のドキュメントしか作成しないため、コストは相対的に安くなります。コストの制約が厳しいプロジェクトの場合、探索的テストは有力な選択肢となると思います。

例えば、あるシステムのテストの見積で100万円の費用がかかると分かったとしましょう。これにはテスト計画やテスト設計、テストケースといった中間生成物の作成が含まれています。しかし、顧客の予算は65万円でした。テストケースを削減して費用を抑えるのはNGです。こういった状況だと、中間生成物を作成しない探索的テストはコストを抑えるのに役立ちます。実際、このような事例で予算内に収まる探索的テストを提案し、採用された実績がありました。このようにコストの制約が厳しいとき、探索的テストは選択肢の一つとして大きな魅力があると言えます。

3. すぐにテストを実施できる

テストケースやテスト手順を作成する場合、それを作成する時間以外に、仕様理解やテスト設計、レビューの時間も必要です。よって、テスト開始までに、相応の時間が必要になります。

一方、探索的テストは、前準備が最小限のため、スピーディにテストを開始できます。時間の余裕がない時や、すぐに試したい時などは、即座にテストを実施できるのは魅力です。実際の事例を紹介いたします。

ある顧客が製品を展示会に出展するため、2週間後にはテストを完了しなければならない状況でした。システムを確認すると、通常のテストフローだと、テスト計画とテスト設計、テストケースの作成だけで2週間、その後のテスト実施にさらに2週間、合計4週間かかることが分かりました。物理的にも時間的にもテスト完了は絶望的な状況でした。そこで、すぐにテスト実施できる探索的テストを提案し、その難局を乗り切りました(ただし、仕様理解しながらのテスト実施なので、単純に半分になる訳ではありません。本事例の場合、リソースの追加と残業対応で、なんとか2週間に圧縮しました)。

その他の事例として、アジャイル開発のテストがあります。ある顧客のアジャイル開発は2週間のイテレーションとしていたため、テストケースを作成していては間に合わないことが分かりました。そのため、探索的テストが採用され、2週間のイテレーションでも、きちんとテストを実施することができました。この経験から私は、アジャイル開発と探索的テストは相性が良いと感じています。

このように、時間的制約がある場面においては、スピーディにテストを実施できる探索的テストには大きなメリットがあります。

余談ですが、時間がかかるということは、別の問題もはらんでいます。テスト実施のタイミングを開発完了と同じタイミングにしようとすると、開発完了前にテストケースの記述を開始しないといけません。しかし、テストケース作成のタイミングが早ければ早いほど、仕様には不明確な部分が増えていき、手探り状態での作成部分が多くなります。よって、テストケース作成のタイミングが早ければ早いほど、テストケースの品質は落ちていくことになります。

つまり、テストケースの質だけを考えた場合、なるべくテストケース作成は遅らせた方が良いということになります。ただし、早期のテスト作成は仕様の品質向上に貢献すると言われており、どちらが良いとは一概には言えません。

探索的テストのデメリット

今まで探索的テストのメリットを見てきましたが、もちろんメリットだけではありません。デメリットもあります。メリット同様にデメリットを3つ挙げたいと思います。

  1. テストが担当者任せになってしまう
  2. テスト実施者にスキルが必要である
  3. テストを資産化できない

それぞれについて詳しく見ていきましょう。

1. テストが担当者任せになってしまう

探索的テストは、基本的にテストケースは作成されません。よって、何のテストをするのかの事前確認はできませんし、何のテストをしたのかも事後確認できません。つまり、適切なテストを実施したか/実施しているか、管理することはできないということになります。

高橋寿一氏も著書で、「探索的テスト(もしくはほかの手法)単独の手法で品質確保することはできないので、探索的テスト(もしくはほかのテスト手法)だけでテストを終了することはできないのも事実です。」と述べています。これは、発注する顧客にとっても、管理するマネージャにとっても、恐怖であると思います。この事が、探索的テストの普及を阻んでいる大きな要因になっていそうです。

2. テスト実施者にスキルが必要である

探索的テストは、スキルのあるテスト実施者を前提としています。このことは、「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」の経験ベースのテスト設計技法の章で、以下のように説明されています。

作業者のスキルに依存するテスト設計となるため、スキルの低い開発担当者がこの技法を用いるとなると、単なるやみくもなテスト(「モンキーテスト」と呼ばれることもあります)になってしまいます。反対にテスト対象に対する理解が深く、経験豊富であるならば、一通りのテストが終わったあとの最終確認的な位置付けとして一定の効果が期待できます。このようなベテランによるテストを「探索的テスト」と呼びます。


スキルのあるテスト実施者は、数が非常に限られます。そうなると、探索的テストをできる人は非常に限られてしまいますし、単価が高いテストになってしまいます。

3. テストを資産化できない

通常、テスト計画書、テスト設計仕様書、テストケース仕様書などのドキュメントは、似たようなプロジェクトの際に再利用されたりします。またそれらのドキュメントは、テスト対象やテスト技術のノウハウが詰まっており、資産価値があります。成熟した組織は、それらのドキュメントを有効活用して、テストの品質を高めています。しかし、探索的テストは、それらのドキュメントを基本的に作成しません。そのため、探索的テストは再現性が低く、ノウハウの移転も難しいテストと言えるでしょう。

まとめ

探索的テストの第1回目である本記事では、探索的テストとは何かを俯瞰したあと、探索的テストのメリットとデメリットについて述べてきました。メリットとデメリットをまとめると、次のとおりです。

メリット
  • テスト実施中の気づきを、テストに反映しやすい
  • 相対的にコストが安くなる
  • すぐにテストを実施できる

デメリット

  • テストが担当者任せになってしまう
  • テスト実施者にスキルが必要である
  • テストを資産化できない

第二回では、上記で示したデメリットをどのように克服したか、実際の体験を交えたソリューション事例を紹介したいと思います。

ライター:高木 陽平

Executive Director, Valtes Advanced Technology

バルテスのフィリピン子会社であるVALTES ADVANCED TECHNOLOGY INC.の取締役で、現地責任者である。今まで、多数のソフトウェアテストやテストプロセス改善の業務に従事。2019年...