この記事はMatthew Heusserによるゲスト投稿です。
「従来の」テストの目標は、テスト作業を予測と繰り返しが可能な安定したものにすることでした。作業がきっちり定義されていれば、スキルの低い作業者でも実施でき、計測と予測が可能です。そこで一般的に、テストケースとテスト手順をあらかじめ定義しておくことが行われました。
作業を定義すると、テスターがスクリプトを離れ、作業しながら探索したり学習したりする能力が制限されます。しかし、よいテストのアイデアの多くは、主体的にソフトウェアと関わり、テストを行う中で思いつくものです。
『Testing Computer Software』の著者であるCem Kanerは、あらゆるテストにはスクリプトを離れた要素がいくらか存在するものだと指摘しました。手順が文書化されていても、テスターはバグを見つけるでしょうし、バグを見つけたらバグの再現と文書化が必要です。テスターが予定された計画に戻った時、まったく同じ場所から再開することはあまりないでしょう。同じ場所に戻ったとしても、バグ再現手順を行ったため、ソフトウェアの状態は異なっているでしょう。
探索テストは、このようなあいまいな現実を無視するのではなく、アドバンテージに変え、その時々に判明したリスクを追究する自由をテスターに与えます。しかし、テスターを自由にしたら、システムのしかるべき部分がテストされたことをどうやって確認すればよいのでしょうか？どのようにテストを管理すればよいのでしょうか？
この記事は、そのような疑問に答えます。
探索的テストとは
1988年にKanerが「探索的テスト」という用語を作ったとき、彼の念頭にあったのは、クイックアタック、または「ゲリラ攻撃」といった言葉でした。ソフトウェアを動作不能にするさまざまな方法を熟知したスキルの高いテスターは、業務ルールを知らない場合でさえ、テストに飛び込んで即座にバグを指摘できたからです。これより後の時代の探索テストの定義は、リアルタイムでテストを設計し、実行し、結果を計画に応用するテスターの能力に焦点を当てたものでした。
2006年にJames BachとMichael BoltonはKanerの解釈を修正し、次のように探索テストを定義しました。
探索テストとは、各テスターの個人的自由と責任を重視し、学習、テスト設計、テスト実施をプロジェクトと並行して行われる相互補完的なアクティビティとみなすことで、テスターの作業の価値を継続的に最適化するというソフトウェテストに対するアプローチです。
このアプローチには大きな利点があります。何をテストするかをその時々でテスターが主体的に判断できます。計画は縄張りではないこと、テスターは作業しながら新しいバグの発見につながる何かを見つける場合があること、テスターは作業しながら複数のアクティビティを切り替えることが強調されます。
この定義に不足しているのは、ソフトウェアシステムで起きていることの概要を把握する方法です。
ソフトウェアの規模が小さく、信頼が厚いなら、それでもかまわないかもしれません。スキルの高いテスターなら、OSの時計ウィジェットやテキストファイルを処理する簡単なデータエクスポート機能を「単にテストする」ことも可能です。問題は、ソフトウェアが複雑であったり規模が大きかったりする場合、また複数のチームメンバーが探索テストを行っており、重複を最小限にしたい場合です。こういった場合、するべきことのリストがあり、リストに従って作業できれば、非常に便利に思えます。しかし、探索的アプローチは変化する計画を利点と捉えるいっぽうで、事前の計画を避ける傾向があります。
テスト ダッシュボード、チャーター、スレッドベーステストなど、この問題を防ぐためのテクニックも出てきています。
アプリケーションのフィーチャーツアーも役に立ちますが、カスタマージャーニーや突発的なリスク、そして新しいビルドでは変更が加えられているという現実を無視しがちです。スプレッドシートを使用したアプローチを採るチームは、メジャービルドごとに新しいシートを作成するのが一般的ですが、その際、「これらの機能は変更がなかったはずだから」といってセクションをテスト対象外として除外することがあります。また、この種のテストダッシュボードはメトリクスや予測を提供しません。
探索的テストのステータスを視覚化する最も簡単な方法は、おそらくホワイトボード上に機能の一覧を作成し、笑顔、普通、困り顔のマークで品質を表し、どの程度機能がカバーされたかをスコアまたは色で表すというものでしょう。
James Bachの Low-Tech Testing Dashboard、Google Docs、その他の共有スプレッドシートを使うとより簡単で、誰もがリアルタイムにダッシュボードを参照できます。上記のサンプルは、Excelon Developmentの実際のお客様のものです。列はブラウザーおよびモバイルデバイスを表しています。
チャーター、セッション、スレッド
探索テストの管理における次の大きな進歩は、セッションベースのテスト管理でした。Hewlett-Packardで編み出されたセッションは、どのように時間を使うかに関するミッションであるチャーターを中心とし、時間を区切った集中的なテストアクティビティです。HPでの当初のセッションは90分間でした。現在では30分間のセッションがより一般的です。
セッションの長さをそろえることで、パフォーマンスのメトリクスの計測が可能になります。このような枠組みを作ることで、「テスター」だけでなくチームメンバーのだれもがテストを実施できます。セッションを実施するメンバーは、メモを取り、終了後にリーダーまたはマネージャーと活動報告会を行い、バグ、テスト、セットアップにかけたおおよその時間の合計、つまりBTS時間を記録します。
セッションベーステストの2大メトリクスは、完了したセッション数と円グラフで示したBTS時間です。簡単なスプレッドシートで管理時間、あるいはセッション外にかけた時間を計算することもできます。
探索テストのチャーターおよびミッション
チャーターは、不注意による特定のリスクを最小限にするためのものです。たとえば、ソーシャルメディアアプリケーションのチャーターであれば、「プロファイル作成周りのクイックアタック」あるいは「同一グループ内またはグループ外の複数ユーザーのコメント、パーミッション、競合状態をテストする」といったものが考えられます。
2番目のチャーターを与えられたテスターは、2つは同じグループに所属する3つのアカウントを作成し、グループだけが参照できるポストを送信し、3番目のメンバーがポストを参照できないことを確認するでしょう。また、ポストを作成し、2番目のユーザーにポストが表示されるのを確認したら、1つのブラウザーでポストの削除をクリックし、2秒後に他のブラウザーでポストにコメントすることも考えられます。
通常、チャーターは、ショッピングカート、ログイン/パスワードを忘れた場合の処理、レポートパネルなど、アプリケーションの特定の部分に着目します。しかし、特定のユーザージャーニーや新機能を探索することも可能です。新しいブラウザーをリリースする場合、あるいはブラウザーやタブレットをサポートするのに必要な作業を簡単にチェックする場合などに簡易的な概要セッションを行うのはよくあることです。
チャーターを使用すると、ブラックボックス化されたあいまいなプロセスを処理し、セッションの実行によって対処されるリスクの集合に変えることができます。しかし、結果を共有スプレッドシートで追跡するのは大変な作業であり、詳細が失われる可能性があります。結果をネットワークドライブ上の個別のドキュメントで管理した場合は、さらに事態が悪化するかもしれません。もっとよいアプローチが必要です。
探索テストを追跡する方法
チームが1日で集中的にテストするなら、各チャーターを付箋にして優先度でソートし、ボードの「未開始」列に貼り付け、「作業中」および「完了」列を追加します。お昼または終業時にステータスをレビューして作業が順調かを確認できます。
1プロジェクトの1回限りのテストであれば、これはうまくいきますが、複数のチームではそうはいきません。探索で収集されたデータは追跡されません。メトリクスは、せいぜいスプレッドシートで手作業でカウントし、保存するしかありません。もっと規模の大きいプロジェクトでは、テストケース管理システムにテストケースとしてチャーターを保存できます。
すると、テストランが特定の回帰テストまたは新機能のセットに対してチャーターされたテストケースの集合になります。テスターはセッションの場合と同じようにテストケースにコメントを残し、テスト管理システムがデータを収集してサマリーレポートを作成します。スクリプト化されたテストと探索テストを組み合わせた比較的シンプルなアプリケーションの例では、テストランは20個ほどのスクリプト化されたテストケースと特定のリスクを探索するための4つのチャーターで構成されるといったケースが考えられます。次のサンプルでは、セッションをテストケースとして記録しています。
探索テストをレポートする方法
探索テストが「失敗」するのは、テストを続けられなくなるような問題が見つかった場合だけです。探索テストの重点は、テストの成功/失敗よりも、意思決定者の役に立つ情報を明らかにする点にあります。探索テストの管理で問われるのは、どちらかというと「まだ完了していないのか」、「いつ完了できるのか」といった点です。テストマネージャーであれば、誰でもアプリケーションの品質や全体的なカバレッジのほうに敏感になるため、完了報告はセッションでは見落とされやすい情報支援です。
テストケース管理ツールは、探索テストについてもすぐれたビューを提供します。セッションが複数のリリースで実施される場合、リリースを表す「テストラン」内の「テストケース」としてセッションを構築すると、画面をスクロールダウンしてカバー済みのセッションとまだカバーされていないセッションを確認できます。 テスト管理ツールで探索テストを改善する方法については、こちらの記事を参照してください。
Matthew Heusser はプロジェクト管理、開発、著述、システム改善の知識を持ち、Excelon Development の Managing Director を務めています。そしてもちろん、ソフトウェアテストも行っています。
（この記事は、開発元Gurock社の Blog 「How to Manage and Track Exploratory Testing」2022年4月18日の翻訳記事です。）
関連する製品
テスト管理ツール TestRail
テストケースの管理やテスト結果の記録、チームでの情報共有など、Excelを使ったテスト管理の業務に限界を感じていませんか？TestRailはシンプルで使いやすいUIを提供し、テストにかかるさまざまな管理コストの削減に貢献します。
■ TestRailの特長 ■
- テストにさまざまな情報を関連づけて一元管理
- Webブラウザー上でテストケースを簡単に入力や編集可能
- テスト実施の準備と結果の共有が容易
- 進捗や比較などのレポートを提供
- 要件 / 課題管理ツールやテスト自動化ツールと連携
日本国内では、テスト管理にExcelを使っていたお客さまからの乗り換えが多く、Web上で完結するテスト管理を実現されています。
TestRail でテスト管理のお悩みを解決しませんか？
テストの生産性向上をTestRailでお試しください
クラウドおよびオンプレミス、デモサイトでTestRailがお試しいただけます。
- TestRailクラウド（クラウドサービス）
- クラウドサービス環境でTestRailをお試しいただけます。
- TestRailサーバー（オンプレミス版）
- お客様のマシンにTestRailをインストールしてお試しいただけます。
- TestRailデモサイト
- インストールなどの設定なしにTestRailにサンプルデータが登録された環境にて操作をお試しいただけます。
