ATS|テスト自動化

2021.6.14

今こそ求められる探索的テストとは? 【第3回】:探索的テスト適用における現場の課題

テスト工程を改革する上で特に有力なテスト技法が、テストの設計・実行を並行する「探索的テスト」です。探索的テストでは、テスト実行しながらテスト項目を選定するため、テスト設計における大幅な工数削減が期待できます。また、テスターの経験やスキルを活かして短期間で効率的なバグ検出を可能にします。

探索的テストは、このように大変有力なテスト技法です。しかし、実際の開発現場では多くの場合、網羅的なテスト設計をもとにテスト実行する従来型の「記述式テスト」が採用されています。探索的テストによりテスト工程の改革を実現する上で、現場の課題を把握することが必要不可欠です。

そこで、探索的テストの連載第3回である本記事では、探索的テスト適用における現場の課題についてご紹介します。なお、探索的テストの基礎知識やメリット・デメリットについては、連載第1、2回の記事をご一読ください。

今こそ求められる探索的テストとは? 【第1回】:探索的テストの基礎知識
今こそ求められる探索的テストとは? 【第2回】:探索的テストのメリット・デメリット

探索的テスト適用の障壁となる、開発現場における3つの課題

なぜ、探索的テストの適用が開発現場で進まないのでしょうか。ここでは、探索的テストを適用する上で高い障壁となっている、3つの課題について解説します。

課題1:スキルの高いテスターの確保が困難

探索的テストでは、システムの特性やテスト結果をもとにして、次に実行すべきテスト項目を選定します。この選定作業はテスターが独断で行うこととなり、システムの深い知識はもちろん、バグに対する嗅覚も求められます。探索的テストの成否は、テスターの経験やスキルにより決まるといっても過言ではありません。

したがって、質の高い探索的テストを行うためには、スキルや経験値の高いテスターの確保が必要不可欠です。しかし、開発サイクルの短い今日の現場では、探索的テストを成功に導くテスターの確保は容易ではありません。スキルの高い要員は実装などにアサインされる場合が多く、経験の少ない要員がテスターを務めることも多いのが実情です。

そうしたケースではバグが検出されやすい箇所の見極めが難しく、探索的テストのメリットである効率的なバグ検出が実現できません。テスターのスキルに依存せずテスト成果を得るために、テスト仕様書に沿って実行する記述式テストが多くの現場で適用されているのです。

ただし、探索的テストが担当者任せにならないように工夫が試みられることもあります。テスト目的を明記する「テストチャーター」や、テストを一定のセッションに区切って実行管理する「セッションベースドテスト」などが代表例です。詳細については「【第1回】:探索的テストの基礎知識」をご参照ください。

この場合も、手順のマニュアル化や長期間にわたる要員の教育トレーニングといったコストが発生します。さらにテスト管理者とテスターの間で確認やミーティングが常時必要となり、アジャイル開発などに欠かせないスピード感の実現には結果として結びつきません。

課題2:プログラムによる自動化のハードルが高い

前述したテスターの経験不足をカバーしながら探索的テストを実現するためには、プログラムによる自動化が必須です。しかし、繊細な判断力が要求される探索的テストを自動化することは、容易ではありません。プログラミングを熟知したエンジニアの力をもってしても、膨大な工数を費やすことは確実です。

仮にテスト実行だけを自動化できたとしても、環境構築やフィードバックといった全テストプロセスを自動化するのは困難です。現実的には自動化できないプロセスは手作業で行うこととなり、それほどの費用対効果は期待できません。

それどころか、システムをバージョンアップする度に自動化プログラムの保守作業が必要となり、余計な工数が発生することも考えられます。このように、探索的テスト自動化の試みは開発現場にとってリスクが高いため、本格的な取り組みが行われることはまだまだ少ないのが現状です。

課題3:探索的テストだけで品質保証するのが困難

探索的テストでは、記述式テストのように網羅的なテスト項目を作成することはありません。場合によっては、実行したテスト項目さえテスト仕様書に記録されないこともあります。それゆえにバグ検出に注力できる一方で、システムの品質を客観的に保証することは難しいのが課題です。

機能要件の網羅性を示せないテスト仕様書では、開発チームや発注元顧客の理解を得ることは難しいと言えます。それに加えて、探索的テストは基本的にユーザビリティやメンテナンス性といった非機能要件の品質保証には適していないと言われています。これらの欠点をカバーするために、現実的には探索的テストと記述式テストを組み合わせて実施するのが一般的です。

しかし、それではテスト設計の工数が大きく増大する上に、両テスト技法の兼ね合いを考慮する新たな負担が生じます。また、探索的テストと記述式テストを併用すると、自動化プログラムの実装はさらに困難となります。探索的テストの適用において品質保証は切り離せない課題であり、そのメリットだけを得ることは難しいのです。

さらに、探索的テストの性質上、現場においてテスト計画書や設計書、テスト仕様書などのドキュメントが残らないケースがほとんどです。自動化プログラムの実行後には、テスト結果のサマリーからインサイト (洞察) を含む予測・分析レポートなど、次の開発に引き継ぐ情報資産の確保も重要な課題となります。

探索的テスト適用の課題に対する解決策とは?

今回は、探索的テスト適用の高い障壁となっている現場の課題についてご紹介しました。このような課題があるために、探索的テストは「非公式のテスト」として位置付けられている現実があります。

しかし、短期間で高いテスト成果を上げられる探索的テストの可能性は大きく、開発サイクルの短い今日の現場に適用すべき手段です。探索的テストのメリットを失わずに、適用の課題を解決する方法は存在します。

この解決策を把握して探索的テストを適用することこそが、DX時代の開発現場には求められます。次回は、探索的テストの課題に対する有力な解決策として、以下の2点について解説します。

・モデルベースドテストの併用
・AIを活用したテスト自動化

上記の解決策をともに実現する『ADOC Testing Service for Eggplant』は、必要に応じ記述式テストと併用することで両方のメリットを享受できる、AIを駆使した探索的テスト自動化実装サービス。詳細は、次回以降でしっかり論じたいと考えています。

■ ADOC Testing Service for Eggplantの概要へ
■ ADOC Testing Service for Eggplantの資料請求へ

  • 2021.6.14
  • 今こそ求められる探索的テストとは? 【第3回】:探索的テスト適用における現場の課題