【テスト設計にお悩みの方向け】探索的テストをツールで管理する！

昨今、ソフトウェア開発のスピードはとても速くなってきています。

それは競合他社より先に市場を押さえるためだったり、お客様のニーズが高まった時期にそのチャンスを逃さないためだったり色々な要因があると思います。

開発期間はどんどん短くなり、それに伴って検証時間も短くなる傾向にあります。

それでもテストエンジニアは品質を担保するために、日々頭を悩ませながら試行錯誤を繰り返していることと思います。（私もその1人です。）

皆さんはテスト業務の中で時間が一番かかる部分はどこだと感じますか？

私は、テスト設計・テスト実装の部分が特に時間がかかるなと感じています。場合によっては、テスト実施より時間がかかる事も。

テスト設計やテスト実装で重要なことは、抜け漏れを無くし、誰がそのテストケースを実施しても同じ検証結果になることだと考えます。（個人的な見解です）

「抜け漏れを無くすためにはこのテスト技法を用いて・・・」

「このテストケースってチョット曖昧だから、しっかり最初の操作手順から記載して・・・」

などなど、色々な事を考えて準備をしなければならないので時間がかかります・・・

確かに大規模開発で大勢のテスター（スキルレベルも様々）と一緒に検証を実施していく場合は、管理をするためや、検証品質の均一化、エビデンスを残すためにも重要な事だと考えます。

しかし、小規模開発であったり、とにかく早くリリースしたいなどのオーダーがあった場合などはどうでしょう？これまで通りのプロセスを踏むのが正解なのでしょうか？

現場毎の考え方や状況がありますので、これには正解は無いと思っていますが、一つの回答として、「探索的テストを取り入れる」があると考えます。

この記事を書いた人

探索的テストとは？

では、その探索的テストとはどんなものでしょうか。端的に言うと

「テスト設計・テスト実行・学習を並行して実施していく、経験ベースのテストである」

となります。具体的には、探索的テストではテスト設計書やテスト項目書などを作成せず、エンジニアが頭の中でテスト設計をしながらテストを実行し、その結果から製品の学習をして、さらにテスト設計をする。その一連のプロセスを繰り返すテスト手法になります。

探索的テストでの目的はバグを発見することであり、ドキュメントを作成しないことでテスト工数の大幅な削減を見込めるので、アジャイル開発とも親和性が高いテスト手法です。

また、経験ベースのテストとなっている通り、テストエンジニアのスキルに大きく依存するものとなります。

探索的テストをアドホックテストやモンキーテストと同じに考える方々がいらっしゃいますが、両者は明確に違いがあります。決定的な違いはテスト設計をするか、しないかの違いです。

アドホックテストやモンキーテストでは、何も考えず気の向くままに操作するだけですが、探索的テストでは、前述の通りバグを発見することを目的として頭の中でテスト設計をしながら操作をしていきます。

アドホックテストやモンキーテストとの違い

アドホックテスト/モンキーテストとは

探索的テストとよく似たものとして、アドホックテストやモンキーテストがあります。これらも、ソフトウェアテストの一種であり、対象となるシステムに詳しくないテスト実行者があえてランダムにシステムを操作することで、通常のテスト方法では発見しにくいエラーやバグを見つける手法です。

アドホックテスト/モンキーテストも探索的テストと同様にテストケースを事前に作成せず、その場の直感や思いつきで実施されます。そのため、予期せぬユーザー行動によって発生する問題を特定することが可能です。

ただし、ランダムな操作のため、発見されたエラーやバグの再現性が低い場合があります。

アドホックテストとモンキーテストの違いについては会社や団体によって見解はさまざまで、確立された定義はありません。テストを実行する人のシステムに対する知識の深さにあるという考えもありますが、曖昧な点が多いです。

探索的テストとアドホックテスト/モンキーテストとの違い

探索的テストとアドホックテスト/モンキーテストの違いは、テスト設計の有無にあります。

両者とも事前にテスト設計を行わずに実施する点では共通していますが、探索的テストはテストの目的や手順、観点を明確に定義し、テストチャーターを用意してから実行します。
一方、アドホックテスト/モンキーテストは目的や手順を定義せず、ランダムにシステムを操作します。そのため探索的テストの方が再現性と精度が高く、アドホックテスト/モンキーテストは予測不能なバグを発見するのに適しています。

探索的テストのメリット

探索的テストのメリットをまとめると

• 工数を大きく削減できる

　⇒テスト設計書、テスト項目書を作成しないため

• 不具合を効率よく発見できる

　⇒不具合が潜んでいそうな部分だけをピンポイントでテストできるため

• 仕様漏れ、仕様の誤りを検出できる

　⇒仕様書を元にテストケースを作成するわけでは無いので、仕様書に出てこない部分や整合性が取れていない部分をテストしやすいため

• ユーザビリティ観点でのテストがしやすい

　⇒テスト項目を作るのが難しい（文章化が難しい）、ユーザー目線での使用性の確認がしやすいため

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

探索的テストにはもちろんデメリットもあります。

• テストエンジニアのスキルに大きく依存する
• 進捗の管理が難しい
• 終了規準が明確でない
• 実行エビデンスが残し難い
• 網羅的でない

これらのデメリットの幾つかへは、具体的な対策方法が提唱されているため、それらを利用することで、リスクを軽減することが出来ます。

• テストエンジニアのスキルに大きく依存する

⇒テストチャーターを運用することで、経験やスキルの不足する部分を補い、テストの方向性についても統一させることが出来る。

• 終了基準が明確でない

　⇒探索的テストの実施を短い時間（セッション）で区切ることで、終了基準を明確化し、深追いしすぎるや、確認不足などを防ぐことが出来る。

• 網羅的でない

　⇒スクリプトテストと併用する。例えば基本的な導線や基本機能は、スクリプトテストとして確認の抜け漏れを防ぎ、複雑な観点や組み合わせは、探索的テストで補う様な形を取れば一定の網羅性は担保できる。

テストチャーターとは

ここで、テストチャーターについて概要を説明します。

テストチャーターとは探索的テストの各セッション内での目的を記載した資料になります。

具体的には、テストして欲しい範囲と深さ、条件、観点を記載して、探索的テストの方向性を指示します。

テストチャーターで注意しなくてはならないのは、記載するテスト観点の粒度になります。

探索テストではテストエンジニアのインスピレーションが重要で、それまでの経験や知識によりバグが存在しそうな条件や操作など自由に設計し、テストを実施していきますが、テストチャーターに細かく指示が記載されいるとその内容に捕らわれ、自由な発想を阻害する恐れがあります。

ですからテストチャーターへ記載する観点の粒度は、スキルの低いテストエンジニアには細かく、スキルの高いエンジニアへは粗く、などテストエンジニアのレベルにあわせその都度調整する必要があります。

探索的テストの管理・エビデンスの残し方

探索的テストは、頭の中でテスト設計をしながらリアルタイムでテスト実行をしていくことで、大幅に工数を削減することが出来ますが、その一方でテストがどこまで進んでいるのかや、どんな検証を実施したのかなど、テストの進捗管理や作業エビデンスを残すことが難しいことがデメリットです。

これらについては、進捗やエビデンス残すためのフォーマットを用意して運用するなど、ルールを設定することによりカバーすることが出来ます。

もし、複雑なルールや記入量が多すぎるフォーマットだったりする場合は、エンジニアのインスピレーションを阻害する要因になりますので、注意が必要です。スクリプトテストと探索的テストで集計方法や管理方法が異なるため、テスト管理は煩雑になることが想定されます。

総合テスト管理ツールPractiTestのススメ

そこで私がお勧めするのは、総合テスト管理ツールであるPractiTestです。

PractiTestを利用すればそれら集計フォーマットの違いによる煩わしさや、探索的テストでの実施内容の不透明さも、効率よく管理することが出来ます。

テスト管理ツールは数多く存在し、それぞれのツール毎に特色がありますが

探索的テストを含め、テスト工程全体を最も効率よく管理できるテスト管理ツールはPractiTestであると思います。（注：個人的感想です。）

では、具体的にどの様なところが探索的テストの管理に向いているのかをご紹介します。

探索的テストのテストケース管理

PractiTestでは、スクリプトテスト、探索的テストなどのテストタイプの異なるテストケースも同一階層での管理が可能です。それらテストケースのテストタイプは、一覧でアイコンを確認することで判別可能ですし、フィルターにより探索的テストのみに絞り表示することも出来るので、とても管理しやすくなります。

探索的テストのテストケース作成

PractiTestでの探索的テストのテストケース作成は簡単で、テストタイプを選択することでフォーマットが表示されるため、そこに必要な情報を記入することで作成できます。

フォーマットとして用意されるのは「テストチャーター」「探索的テストのポイント」になり、「テストチャーター」には前述した内容を記載し、「探索的テストのポイント」については任意の内容を記載する部分になりますので、記述内容をチーム内で規定し、運用することができます。

探索的テストの実行内容の管理

探索的テストの実施中は画面上部で「テストチャーター」「探索的テストのポイント」を確認することが出来るので、テストケースへ遷移して確認する必要がありません。

セッション時間についてもタイマーで管理しているので時間超過のリスクを減らせます。

また、実施内容は「注釈」を追加していく形で証跡を残していくことができ、「注釈」ごとに「タイプ」を設定できるのでタイプでの検索や記載内容での検索も可能です。

バグを発見時は「注釈」から直接チケットを登録できるため、紐づけも自動で実施されるためどのテストで発見されたバクなのかも追跡することが可能です。

実施内容はインスタンスとして自動保存されるため第三者がリアルタイムにテストの実行内容を確認し、コメントを残すことも可能ですし、後から内容を確認することもできます。

テスト結果の集計管理

PractiTestでは様々なタイプ（スクリプトテスト、探索的テスト、自動化されたテスト）のテストを同一ツール上で管理できるため、テスト進捗やテスト結果を個別で管理する必要はなく、一括して集計した結果をリアルタイムで表示させたり、レポートとして出力することができます。

このように、PractiTestではテストタイプの違いによる管理の煩雑さを解消でき、探索的テストで不透明になりがちだった実行の証跡も容易に作成・管理することができる仕組みを備えているため、探索的テストの導入に躊躇する心のハードルが随分下げる事が出来るのではないでしょうか？

実際にPractiTestを探索的テストの実施のために導入していただいた企業様もあり、その運用方法については日々改善のサポートさせていただいております。

さあ、皆さんも検証フェーズでの工数削減にお困りなら、探索的テストの導入を検討してみてはいかがでしょうか！