2022.12.02
本記事では、探索的テストについて、2回にわたってまとめています。第1回目は、探索的テストとは何かを俯瞰したあと、筆者が感じている探索的テストのメリットとデメリットについて述べました。
第2回目である本記事では、探索的テストのデメリットである、「テストが担当者任せになっていまう」、「テスト実施者にスキルが必要」、「テストを資産化できない」という3点に対し、どのように対策が必要になるのか、探索的テストのやり方を紹介していきます。ここで紹介する方法がベストではないかもしれませんが、ご参考にしていただければ幸いです。
また、実践編を追加した無料の資料もご用意しています。探索的テストを行ってみたい方はぜひダウンロードしてみて下さい。
- もくじ
1．テストが担当者任せになってしまう」への対策
探索的テストがなぜ、担当者任せになってしまうかというと、テストの計画やテストケースを作成しないため、何のテストを実施しているか見えないからです。JSTQBが発行している「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」の「5.3 テストのモニタリングとコントロール」の章に以下の記述があります。
テストモニタリングの目的は、テスト活動に関する情報を収集して可視化し、フィードバックをかけることである。(中略)
テストコントロールとは、収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることである。
出典：「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02
つまり、担当者任せになってしまわないようにするためには、テスト実施内容を可視化し、途中途中にガイドや補正のアクションが取れるようにすれば良いわけです。ただし、あまりモニタリングとコントロールを強くしすぎると成果物や実施することが増え、探索的テストのメリットを活かすことができません。よって、これらのバランスが重要になってきます。そこで、以下の3つことを実施することで、探索的テストのメリットを活かしながら、担当者任せにならない良いバランスを探ります。
- a) 機能一覧によるテストカバレッジの測定
- b) テストチャータの作成
- c) セッションベースドテストの適用
それぞれについて、詳しく見ていきましょう。
a) 機能一覧によるテストカバレッジの測定
思いつくままテストを実施していると、どのテストを実施したか分からなくなり、抜けもれが発生します。そこで、機能一覧を利用して、どの機能をテストしたか分かるようにします。これが、『テストカバレッジの測定』です。
記録のつけ方は、機能一覧の各機能の横にテスト実施した日付を書くのでも良いですし、後述するテストチャータを各機能分、先に作ってしまうのでも構いません。ここで重要になってくるのは、全ての機能を抜けもれなくテストすることですので、それを達成できる記録方法を選んで下さい。
機能一覧は、要件定義工程や開発工程で作成されているのであれば、それを利用します。ない場合は、システムを触りながら抽出します。画面一覧や要件一覧で代用することもあります。何をカバレッジ対象とするかは、顧客やプロジェクトマネージャと合意して決めます。
b) テストチャータの作成
テストチャータとは、テスト実施する前にテストの目的とその目的が達成されたことを判断する指針を示したドキュメントとなります。テストケースとの違いは、テストチャータの方が、抽象度が高い点です。弊社の場合は以下の内容を記述しています(複数環境でテストする場合は、テスト環境も記載します)。
- 実行日
- 実行者
- 実行時間
- 担当者/打合せ参加者
- テスト対象機能/画面
- テスト観点
- テストの目的/テスト内容のおさらい
- 目的の達成度合い
実際に内容を記載した例としては、以下になります。
| 実行日 | 2020/07/04 |
|---|---|
| 実行者 | テスト太郎 |
| 実行時間 | 2時間 |
| 担当者/打合せ参加者 | テストマネージャ花子 |
| テスト対象機能/画面 | ログイン/ユーザー登録 |
| テスト観点 | GUI・機能テスト（正常系、異常系） |
| テストの目的/テスト内容のおさらい |
GUI：画面崩れ、文言誤り、レイアウト誤りがないこと |
上記例をご覧いただくと分かると思いますが、テストケースに比べると抽象度が高く、具体的な値まで記述していません。よって、再現性という点においては、テストケースに劣ると言えます。ただし、どのような機能を、どのような観点で、何時間テストしたかについては可視化されるため、テストをコントロールできるようになります。
c) セッションベースドテストの適用
セッションベースドテストは、JSTQB「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02」の「4.4.2 探索的テスト」で以下のように紹介されています。
探索的テストでは、活動を体系的にするためにセッションベースドテストを使用する場合がある。セッションベースドテストでは、探索的テストをあらかじめ決められた時間枠内で行う。テスト担当者はテスト目的を含むテストチャータに従ってテスト実行をする。
出典：「テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2018.J02
セッションベースドテストを適用すると、テストが体系立てられ、コントロールしやすくなります 。ここで重要になってくるのが、「あらかじめ決められた時間枠内で行う」という部分です。自社で行う場合は、まず、テストマネージャとテスト実施者が数分程度のミーティングを行います。
このミーティングでは、テストチャータの内容、つまりどの機能のテストを、どのような観点で、どのくらいの時間実施するか(30分～2時間：この単位をセッションと言います)を決定します。通常は、最も基本的な機能や、不具合が多そうな(リスクが高そうな)機能を最初に選びます。
あらかじめ決められた時間が来たら、再度、打合せして、次のテスト内容を決めます。テストがセッション期間内に終わらなかった場合や不具合が多数見つかった場合は、追加のテストを実施するか検討します。
逆に、品質が良さそうだと判断したら、さっさと次の機能や観点に進みます。このように、セッションベースドテストを適用すると、テストがかなりコントロールできるようになります。
2．「テスト実施者にスキルが必要である」への対策
「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018 対応」に記述がある通り、探索的テストは「経験豊富」なテストエンジニアが実施することが前提条件です。しかし、「経験豊富」なテストエンジニアはそうそう多くいるわけではありません。
試行錯誤と仕組み化の結果、1～2年目の経験が浅いテストエンジニアでも、ある程度の品質で探索的テストができるようになりました。
バルテス社内で実施した項目は以下の3つとなります。
- a) 仕組み化によるトレーニング
- b) 集中的な業務経験
- c) フィードバックの仕組み
それぞれについて、詳しく見ていきましょう。
a) 仕組み化によるトレーニング
仕組み化によるトレーニングは、無印を赤字から立て直した名経営者である松井忠三氏の著書「図解 無印良品は、仕組みが9割」から着想を得ました。松井氏いわく、当時、経理部が一人前になるには15年かかっていたそうです。それが明文化してマニュアルを作成したこところ、2年で一通りの仕事を覚えられ、5年もあれば一人前になったそうです。ソフトウェアテストは、経理とは違いますが、人が学習する過程は同じはずです。
つまり、知識を体系立てて学び、作業をマニュアル化すれば、テストエンジニアが早く育つと考えたのです。
まずは、テスト知識を体系立てて学ぶ方法ですが、国際的なソフトウェアテスト資格であるISTQB（日本ではJSTQB）を活用しました。バルテスではJSTQBの講習を実施し、試験を受けることを推奨しています。結果、バルテスのエンジニアのうち全体の92%がJSTQB資格保有者となりました。
その結果多くの人が、自分が適用したテスト技法を理論立てて説明できるようになりました。また、指示を出すテストマネージャも、適用するテスト技法を細かく説明する必要もなくなり、意思の疎通が迅速になりました。
次に、作業のマニュアル化ですが、探索的テストとセッションベースドテストのやり方をマニュアル化しています。JSTQBを学習したメンバーであれば、すぐに一通りの流れを把握できるようになりす。
b) 集中的な業務経験
人材育成の第一人者である東京大学准教授の中原淳氏が、業務経験について、著書内で以下のように述べています。
三十年ほど前まで、人材開発の世界では、研修や教育プログラムの研究や評価が非常に盛んでした。(中略) それが二十年ほど前に見直され、やはり「業務経験こそが最も大きな成長の資源である」という考え方が広まってきました。(中略) 人材開発の世界では、業務経験から学ぶことを「経験学習」といいます。
出典：フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術（中原淳 著、PHPビジネス新書）
つまり、いくらトレーニングをしても、業務経験が伴わないと、人材は成長しないことをなります。この点、バルテスはテスト専門会社なので有利です。開発会社やユーザー企業は、企画工程や開発工程があるため、ずっとテストをしている訳ではありません。
しかしバルテスの社員は四六時中テストを実施しているため、集中的にテストの業務経験が溜まります。また、経験の浅いメンバーが、経験豊富なメンバーとペアになってテストを実施するペアテスト方式を実施しています。ペアテストでは、テスト実施するテストオペレータと、テスト実施について質問するナビゲーターという役割を設けます。
テストオペレータとナビゲーターは、一定期間ごとに役割をチェンジします。こうすることにより、テスト経験の浅いメンバーは、テスト経験豊富なメンバーの業務経験やノウハウを直に学ぶことができ、急成長していきます。
c) フィードバックの仕組み
東京大学准教授の中原淳氏は、著書「フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術」の中で、以下のように述べています。
いつかは自律して、自分で自分を律さなければならないにしても、自律を獲得するには、 若い時期に他人に律せられる「他律」の時期が必要です。成長するためには、正しく進んでいるかどうかを誰かにチェックしてもらい、指摘してもらうこと、つまりフィードバックが欠かせません。
出典：フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術（中原淳 著、PHPビジネス新書）
つまり、経験が浅いメンバーが成長するためには、適切なフィードバックが必要になってきます。これを実現するために、前述したペアテストおよびセッションベースドテストで、フィードバックが出来る仕組みを整えました。
まず、経験の浅いメンバーは経験豊富なメンバーとペアになって、探索的テストを実施します。その際、経験豊富なメンバーから、テストのやり方について逐次フィードバックを受けます。ペアテストで探索的テストに慣れてきたら、今度は一人でテストします。
この時、セッションベーステストを適用しているので、各セッションの前後にテストマネージャより、フィードバックを受けられます。これによって、絶えず軌道修正している形になるため、経験の浅いメンバーでも品質を保ちながら、探索的テストをこなせるようになっていきます。
3．「テストを資産化できない」への対策
探索的テストでは、テスト計画やテスト設計を頭の中でだけで実施するので、テスト計画書、テスト設計書、テストケース仕様書などを作りません。そのため、それらの情報資産は残りません。
バルテスでは、それらに代わる3つの資産として「テストサマリーレポート」、「ノウハウ」、そして「テスト観点表」を作成し、残すようにしています。これらの資料により、例え実施者が変わったとしても、前回のテストの経験を活かすことができます。
| No. | ドキュメント | 説明 |
|---|---|---|
| 1 | テストサマリーレポート | テスト終了後、不具合の内容を分析し、不具合傾向などを分析した資料 |
| 2 | ノウハウ | テスト終了後、振り返り会議を実施し、どのような教訓やノウハウを得たまとめた資料 |
| 3 | 観点表 | テスト対象のテスト観点をまとめた表 |
まとめ
本記事では、探索的テストの実施方法についてご紹介してきました。
既に見てきたように、探索的テストを上手に活用することで、テストの質を上げ、コストを抑え、しかも期間を短縮させることが可能です。一方で、デメリットをきちんと認識してその対策を打たなければ、テストの質が不安定になり、品質への悪影響が懸念されるようになります。
システム開発において最も重要なリソースとは、言うまでもなく「人」です。高いスキルを備えた人材が確保できれば、多くの開発案件をこなすことができ、知識・経験が蓄えられていきます。こうして蓄えられた知識・経験は、次のビジネスに活かすことができ、企業の成長を促します。結果的に、ヒト・モノ・カネ・情報といった経営資源が確保しやすくなり、人材確保・育成にも予算を投じる余裕が生じ、徐々にリソース不足は解消に向かうと予測できます。
探索的テストの有効活用は、テスト工程における「リソースとの戦い」を有利に運ぶ解決策になりうるものです。本資料で紹介したように、探索的テストのメリットを活かすとともにデメリットを抑える対策を併せることで、探索的テストの有効活用を図り、ソフトウェアテストの品質向上にお役立ていただきたいと思います。
本記事の完全版として、ダウンロード資料を作成いたしました。
こちらの資料では、バルテス流の「探索的テスト」の実施方法を、ミーティングの進め方やシートへの記述方法など、具体的にお伝えしています。資料の中に書いてあることが、一つでも業務の参考になれば幸いです。是非ダウンロードしてみて下さい。
