対象読者
- 探索的テストを試してみたいが、どのように制御するか知りたいエンジニア読者
- 探索的テストのスキルをどのように獲得するか知りたいエンジニア読者
- 探索的テストのテスト資産をどのように残すか知りたいエンジニア読者
探索的テストのデメリットを克服するには
前回は、探索的テストのデメリットを見てきました。今回はそれぞれのデメリット項目に対する解決方法を紹介したいと思います。もちろん、ここで紹介する方法がベストではないかもしれませんが、私が3年以上試行錯誤して得たノウハウなのでご参考にしていただければ幸いです。
- 「テストが担当者任せになってしまう」への対策
- 「テスト実施者にスキルが必要である」への対策
- 「テストを資産化できない」への対策
それぞれについて、詳しく見ていきましょう。
「テストが担当者任せになってしまう」への対策
探索的テストがなぜ、担当者任せになってしまうのかというと、テストの計画やテストケースを作成しないため、何のテストを実施しているか見えないからです。JSTQBが発行している「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」の「5.3 テストのモニタリングとコントロール」の章に以下の記述があります。
テストモニタリングの目的は、テスト活動に関する情報を収集して可視化し、フィードバックをかけることである。(中略)
テストコントロールとは、収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることである。
出典：「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」
つまり、担当者任せになってしまわないようにするためには、テスト実施内容を可視化し、途中途中にガイドや補正のアクションが取れるようにすれば良いです。ただし、あまりモニタリングとコントロールを強くしすぎると成果物や実施することが増え、探索的テストのメリットを活かすことができません。そのため、これらのバランスが重要になってきます。そこで、以下3つことを実施することで、探索的テストのメリットを活かしながら、担当者任せにならない良いバランスを探ります。
- 機能一覧によるテストカバレッジの測定
- テストチャータの作成
- セッションベースドテストの適用
それぞれについて、詳しく見ていきましょう。
1. 機能一覧によるテストカバレッジの測定
思いつくままテストを実施していると、どのテストを実施したのか分からなくなるものです。私の経験上、必ず抜け漏れが発生してしまいます。そこで、機能一覧を利用して、どの機能をテストしたかを分かるようにします。これが、テストカバレッジの測定です。
記録のつけ方は、機能一覧の各機能の横にテスト実施した日付を書くのでも良いですし、後述するテストチャータを各機能分、先に作ってしまうのでも構いません。ここで重要になってくるのは、全ての機能を抜け漏れなくテストすることなので、それを達成できる記録方法を選んでください。
機能一覧は、要件定義工程や開発工程で作成されているのであれば、それを利用します。ない場合は、システムを触りながら抽出します。画面一覧や要件一覧で代用することもあります。何をカバレッジ対象とするかは、顧客やプロジェクトマネージャと合意して決めます。
2. テストチャータの作成
テストチャータとは、テスト実施する前にテストの目的とその目的が達成されたことを判断する指針を示したドキュメントです。テストケースとの違いは、テストチャータの方が抽象度が高い点です。弊社の場合は以下の内容を記述しています（複数環境でテストする場合は、テスト環境も記載します）。
- 実行日
- 実行者
- 実行時間
- 担当者/打ち合わせ参加者
- テスト対象機能/画面
- テスト観点
- テストの目的/テスト内容のおさらい
- 目的の達成度合い
実際に内容を記載した例としては、以下になります。
| 実行日 | 2021/03/07 |
| 実行者 | テスト太郎 |
| 実行時間 | 2時間 |
| 担当者/打ち合わせ参加者 | テストマネージャ花子 |
| テスト対象機能/画面 | ログイン/ユーザー登録 |
| テスト観点 | GUI・機能テスト（正常系、異常系） |
| テストの目的/テスト内容のおさらい |
GUI：画面崩れ、文言誤り、レイアウト誤りがないこと
機能：さまざまなパターンのユーザー登録、ログインができる/できないこと
|
上記例の通り、テストケースに比べると抽象度が高く、具体的な値まで記述していません。そのため再現性の点においては、テストケースに劣ると言えます。ただし、どのような機能を、どのような観点で、何時間テストしたかについては可視化されるため、テストをコントロールできるようになります。
3. セッションベースドテストの適用
セッションベースドテストは、JSTQB「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」の「4.4.2 探索的テスト」で以下のように紹介されています。
探索的テストでは、活動を体系的にするためにセッションベースドテストを使用する場合がある。セッションベースドテストでは、探索的テストをあらかじめ決められた時間枠内で行う。テスト担当者はテスト目的を含むテストチャータに従ってテスト実行をする。
出典：「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」
セッションベースドテストを適用すると、テストが体系立てられ、コントロールしやすくなります。ここで重要になってくるのが、「あらかじめ決められた時間枠内で行う」という部分です。自社で行う場合はまず、テストマネージャとテスト実施者が数分程度のミーティングを行います。
このミーティングでは、テストチャータの内容、つまりどの機能のテストを、どのような観点で、どのくらいの時間実施するか（30分～2時間：この単位をセッションと言います）を決定します。通常は、最も基本的な機能や、不具合が多そうな（リスクが高そうな）機能を最初に選びます。
あらかじめ決められた時間が来たら、再度打ち合わせして、次のテスト内容を決めます。テストがセッション期間内に終わらなかった場合や不具合が多数見つかった場合は、追加のテストを実施するか検討します。
逆に、品質が良さそうだと判断したら、さっさと次の機能や観点に進みます。このように、セッションベースドテストを適用すると、テストがかなりコントロールできるようになります。
