CodeZine(コードジン)

特集ページ一覧

探索的テストのデメリットを克服するには? 対策事例を紹介

「探索的テスト」でテスト経験を最大限に活かそう 第2回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 本記事では、ソフトウェアテスト専門会社 バルテス株式会社のフィリピン子会社 VALTES ADVANCED TECHNOLOGY Inc.の現地責任者で、2018年に探索的テストサービスの立ち上げ、推進してきた筆者が3回にわたって探索的テストについてまとめています。前回は、探索的テストとは何かを俯瞰したあと、筆者が感じている探索的テストのメリットとデメリットについて述べました。第2回となる本記事では、探索的テストのデメリットである「テストが担当者任せになってしまう」「テスト実施者にスキルが必要」「テストを資産化できない」という3点に対し、どのように対策を講じたのか、実際の対策事例を紹介します。

目次

対象読者

  • 探索的テストを試してみたいが、どのように制御するか知りたいエンジニア読者
  • 探索的テストのスキルをどのように獲得するか知りたいエンジニア読者
  • 探索的テストのテスト資産をどのように残すか知りたいエンジニア読者

探索的テストのデメリットを克服するには

 前回は、探索的テストのデメリットを見てきました。今回はそれぞれのデメリット項目に対する解決方法を紹介したいと思います。もちろん、ここで紹介する方法がベストではないかもしれませんが、私が3年以上試行錯誤して得たノウハウなのでご参考にしていただければ幸いです。

  • 「テストが担当者任せになってしまう」への対策
  • 「テスト実施者にスキルが必要である」への対策
  • 「テストを資産化できない」への対策

 それぞれについて、詳しく見ていきましょう。

「テストが担当者任せになってしまう」への対策

 探索的テストがなぜ、担当者任せになってしまうのかというと、テストの計画やテストケースを作成しないため、何のテストを実施しているか見えないからです。JSTQBが発行している「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」の「5.3 テストのモニタリングとコントロール」の章に以下の記述があります。

 テストモニタリングの目的は、テスト活動に関する情報を収集して可視化し、フィードバックをかけることである。(中略)

 テストコントロールとは、収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることである。

 出典:「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」

 つまり、担当者任せになってしまわないようにするためには、テスト実施内容を可視化し、途中途中にガイドや補正のアクションが取れるようにすれば良いです。ただし、あまりモニタリングとコントロールを強くしすぎると成果物や実施することが増え、探索的テストのメリットを活かすことができません。そのため、これらのバランスが重要になってきます。そこで、以下3つことを実施することで、探索的テストのメリットを活かしながら、担当者任せにならない良いバランスを探ります。

  1. 機能一覧によるテストカバレッジの測定
  2. テストチャータの作成
  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時間:この単位をセッションと言います)を決定します。通常は、最も基本的な機能や、不具合が多そうな(リスクが高そうな)機能を最初に選びます。

 あらかじめ決められた時間が来たら、再度打ち合わせして、次のテスト内容を決めます。テストがセッション期間内に終わらなかった場合や不具合が多数見つかった場合は、追加のテストを実施するか検討します。

 逆に、品質が良さそうだと判断したら、さっさと次の機能や観点に進みます。このように、セッションベースドテストを適用すると、テストがかなりコントロールできるようになります。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 高木 陽平(VALTES ADVANCED TECHNOLOGY INC.)(タカギ ヨウヘイ)

      東京理科大学大学院 技術経営修士(MOT)卒業。バルテスのフィリピン子会社であるVALTES ADVANCED TECHNOLOGY INC.の取締役。今まで、多数のソフトウェアテストやテストプロセス改善の業務に従事。大学でソフトウェア工学の研究室に入り、プロセス改善を研究。そのこともあり、CM...

バックナンバー

連載:「探索的テスト」でテスト経験を最大限に活かそう
All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5