探索的テストを高度化するためのテスト技法

1.テスト技法の活用

テスターなら誰しも、以下のようなケースで欠陥を発見したことがあるのではないでしょうか。

・テスト実行中に見つけた欠陥の周辺を更にテストした。
・テスト実行中に仕様の不明点に気付き、製品の実動作を確認した。
・何らかの処理中など、シビアなタイミングを狙って操作した。
・直感的に怪しいと思った箇所をテストした。
・過去の経験や製品知識、開発者の癖から怪しい箇所を狙ってテストした。

上記のような思考はテスト実行と並行して頭の中で考えるため、テスト手順・条件がドキュメントとして残らずテストの内容やカバレッジを説明しづらかったり、属人的なテストになったりします。
そのため、上記の思考を評価プロセスに落とし込み、属人的なテストになるのを防ぐと同時に、探索的テストをより計画的、戦略的に実施することが重要です。
その手法として、「テストチャーター」と「セッションベースドテスト」というテスト技法があります。

2.テストチャーター

①テストチャーターとは

探索的テストを開始する前にテストチャーターと呼ばれるリストを準備します。
テストチャーターとは、探索的テストを実施する際に考え得るテスト観点（目的）とそれを達成するための指針を明記したものです。 テストチャーターに定めるテストの指針は、テストの自由度を保つためにテスターの経験に合わせて、ある程度抽象的な書き方にすることが推奨されます。

テストチャーターの作成は、テスト管理者や熟練テスターの頭の中にしかない探索的なテスト思考を第三者にも分かる形に書き出すため、テスト初心者が探索的テストの道しるべを得ることができます。
ただし、スクリプトテストのように詳細なテストケースを作成しないため、探索的テストの実行結果のフィードバックを活用してテストをコントロールするプロセスがなければ、テスターの技量によってはテスト管理者が想定した結果を得られない場合があるでしょう。

メリット
・テスト手順や期待値などを明確に定めない（抽象度が高い）ため、テスト設計工数が削減できる。
・テストの指針（狙い）を定めるため、経験が浅いテスターでも弱点にフォーカスして探索できる。
・知見を持ったメンバーの経験や知識などを取り入れるため、仕様書に記載のない暗黙知を活用できる。

デメリット
・テストチャーターを細かく設定し過ぎると自由度が下がり、探索範囲が狭くなる。
・テストチャーターの粒度が粗過ぎると、評価の目的から逸脱したテストになりやすい。
・テスト管理者とテスターの認識のズレを無くすためのテスト管理工数が発生する。

②テストチャーターの決め方

テストチャーターの例から、テストの指針や狙いをどのようにリスト化するかを説明していきます。
テストチャーターを作成する上で注意すべきは、粒度を細かくし過ぎないことです。テストチャーターが詳細になればなるほど、テスト設計・実装工数が削減できるという探索的テストのメリットを失いかねません。探索的テストという技法に適した粒度で、テストチャーターを作成することが重要です。

以下の例では、何（テスト対象）を、どうしたら（テスト観点）、どうなる（想定不具合）ことを狙いとしているかをリスト形式でまとめています。 また、詳細は後で説明しますが、探索的テストに取り入れる「ツアー」を記載することで、テスターにどのように探索して欲しいかを示します。

[チャーターのサンプル]

Ⅰ.　何をテストするか
記載内容は「テストの範囲」であり、テスト対象の機能や画面などを記載します。テストを行う対象や範囲をある程度定めることでカバレッジを管理し、効率良くテストを行います。
　例1：ログイン機能
　例2：ユーザーのマイページ　など

Ⅱ.　テスト観点
記載内容は「テストの目的（観点）」であり、上記Ⅰに対してどのようなテスト（How、With、Resources、Conditionなど）を実施するかを記載します。テスト観点をどの程度の抽象度で記載するかは、テスターの経験に合わせて調整する必要があります。
目的はテストを実施する上で必要不可欠なもので、テストの方向性を示さなければ、テストチャーターに沿ったテストができず、無駄なテスト工数の増加を引き起こしかねません。
　例1：権限の異なるユーザーでログインする
　例2：論理削除後に再登録したユーザー情報でテストする　など

Ⅲ.　想定不具合
テストチャーターで定めたテストで狙う不具合の例を記載します。テスト観点と合わせて記載することで、テスト管理者の狙いをよりテスターが理解しやすくする効果があります。（例なので記載した不具合を検出する訳ではありませんが、ここに記載したような不具合がないことを確認しながらテストします）
　例1：ユーザー権限により実施できるはずの操作が受け付けられない
　例2：再登録したユーザーで特定の操作ができない　など

Ⅳ.　ツアー
どのツアーに沿って探索的テストを行うかを記載します。
上記サンプルの場合、テスト対象の機能を使用してデータを生成する際に、データが処理される流れに着目して（FedExツアーを取り入れて）探索的テストを実施することを示しています。

ツアーには、以下のようなパターンが存在します。
【ツアーのパターン】
　・ガイドブックツアー：ユーザーズマニュアルやオンラインヘルプに基づいてテストする
　・マネーツアー：営業がお客様向けに行うデモに基づいてテストする
　・ランドマークツアー：ソフトの状態遷移をリスト化し、それを網羅するようにテストする
　・知的ツアー：境界値などエラー処理を外れるような厳しい値でテストする
　・FedExツアー：ソフトウェアで処理されるデータの流れ（ライフサイクル）に着目してテストする
　・ガーベージコレクターツアー：各画面、ダイアログや各機能を粗めの観点でテストする
　・嫌な隣町ツアー：欠陥が偏在する箇所を狙ってテストする
　・ミュージアムツアー：ソフトの古いコードが残っている箇所を狙ってテストする
　・裏通りツアー：ユーザーがあまり使用しない機能を狙ってテストする
　・オールナイトツアー：長時間何かの操作をしたまま、別の処理をテストする
　・スーパーモデルツアー：パッと見のUIや画面の様子、レスポンスなどに着目してテストする
　・カウチポテトツアー：最低限の操作で機能を使ってテストする
　・強迫性障害ツアー：何度も同じ操作を繰り返すテストを行う

ツアーはテスターがテストの方向性を見失わないための情報であり、テスターが持っているテスト観点の幅を広げることに役立つ情報にもなるため、チャーターごとに適切なツアーを定めましょう。

3.セッションベースドテスト

①セッションベースドテストとは

セッションベースドテストとは、一定の時間（セッション）ごとに区切って探索的テストを実施するテスト技法です。

セッションベースドテストでは、セッションごとにテストチャーターとレポート様式を兼ねたセッションシートを準備し、テスターへのテストの指示と、テスターからのフィードバックを得られるようにします。テスト管理者はセッションシートのレポートから、テスターがどんなテストをして、どんな結果になったのかを把握することができ、その結果を基に次にどんな探索的テストを行うか作戦を立てることができます。
また、テスターはテスト管理者から新たな観点やテストの方向性などをフィードバックされることで、自分だけで探索するよりも深い、多様な観点で探索的テストを行うことができます。

このように、随時テスト管理者とテスター間で情報を共有してテストの内容をコントロールしながら探索するのが特徴です。セッションごと、あるいは日次でテスト管理者とテスターが話し合う場を5～10分程度設け、コミュニケーションを取りながら探索的テストを行います。

メリット
・テスト管理者が探索的テストの内容をコントロールしやすい。
・テスターはテスト管理者から知見を得ながら探索できる。
・テスターの集中力が持続でき、探索的テストが徘徊・散策的になるのを防止できる。

デメリット
・セッションごとにテストの予実管理や追加テストの検討が発生するため、テストの管理工数が増加する。
・セッションを細かくし過ぎると、テストの自由度が低下して探索しづらくなる。

②セッションベースドテストの記載事項

セッションベースドテストでは、セッションごとに以下の内容をドキュメント化（セッションシートに記載）して、探索的テストを実施します。

Ⅰ.　各セッションの時間枠
30分～2時間程度の時間を各セッションに割り当て、その時間枠を基に1日に実施するセッション数を決めます。テスターが持続できる集中力を考慮して、1日の最大セッション数は3程度にするのが妥当です。
テスト管理者はこの情報を基にテストの進捗を管理します。

Ⅱ.　チャーター
テスト実行前に準備したテストチャーター・ツアーの中から、該当のセッションで実施する内容を記載します。
テスターはこのテストチャーターに従ってテストを行います。

Ⅲ.　レポート
テスターは探索的テストを実施した結果として、以下のような情報をレポートにまとめてテスト管理者に報告します。

【レポートに記載する内容】
　・テスター名
　・実行日時
　・ソフトウェア情報（バージョンなど）
　・各ミッションでかかったテストの実施時間
　・テスト中に気付いたこと（製品に対する違和感、ユーザー視点で不便と感じたことなど）
　・テスト中に発生した課題
　・検出した各インシデントの内容　　　　　　　　　　　　　　　　　　　　　　　　　　など

探索的テストの結果、想定した不具合が発生しなかった場合でも、どのような評価結果が得られたかをレポートにまとめ、テスト管理者がテストの状況を把握できるようにします。また、テスターはセッション中に発見したインシデントの内容だけはなく、インシデントを見つけるためのヒントになりそうな気付きもレポートに記載します。
それらの情報はテスト管理者が次のセッションでどのようなテストを実施するかを検討するための重要な情報になります。

4. まとめ

プロセスを考えて探索的テストを実施するための手法として、テストチャーターとセッションベースドテストというテスト技法についてご紹介しました。
これらのテスト技法は、これまでテスターの技量に依存していた探索的テストから脱却し、経験の浅いテスターでもより高度な探索的テストを実施するために有効な手段です。
最初はチャーターの記載粒度やツアーの内容に戸惑うことが多いと思いますが、テスターが製品・運用方法などについて学び、そこで得た経験やテストデータを蓄積し、それを基にテストチャーターの内容や粒度感をチーム内で継続的に改善することが重要です。
そして、実際の業務で評価プロセスに基づいたテストを実行し、探索的テストで発見した欠陥数やテストの網羅率などで効果を確認しながら、テストプロセス全体をブラッシュアップしましょう。