探索的テストのデメリットを克服するには（2）
「テスト実施者にスキルが必要である」への対策
「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」に記述がある通り、探索的テストは「経験豊富」なテストエンジニアが実施することが前提条件です。しかし、「経験豊富」なテストエンジニアは多くいるわけではないので、比較的テスト経験が浅いテストエンジニアにも探索的テストをできるようになってほしいと考えていました。
試行錯誤と仕組み化の結果、1～2年目のテストエンジニアでも、ある程度の品質で探索的テストができるようになりました。社内で実施した項目は以下の3つとなります。
- 仕組み化によるトレーニング
- 集中的な業務経験
- フィードバックの仕組み
それぞれについて、詳しく見ていきましょう。
1. 仕組み化によるトレーニング
仕組み化によるトレーニングは、無印良品を赤字から立て直した、名経営者である松井忠三氏の著書『図解 無印良品は、仕組みが9割』から着想を得ました。松井氏いわく、当時、経理部が一人前になるには15年かかっていたそうです。それが明文化してマニュアルを作成したこところ、2年で一通りの仕事を覚えられ、5年もあれば一人前になったそうです。ソフトウェアテストは、経理とは違いますが、人が学習する過程は同じはずです。
つまり、知識を体系立てて学び、作業をマニュアル化すれば、テストエンジニアが早く育つと考えたのです。まずは、テスト知識を体系立てて学ぶ方法ですが、国際的なソフトウェアテスト資格であるISTQB（日本ではJSTQB）を活用しました。毎年ISTQBトレーニングを受け、試験を受けることを必須としています。昇格にも影響するので皆必死に勉強し、ほとんどの社員がISTQBの資格を有しています。
その効果はてきめんで、自分が適用したテスト技法を理論立てて説明できるようになりました。また、指示を出すテストマネージャも、適用するテスト技法を細かく説明する必要もなくなり、意思の疎通が迅速になりました。
次に、作業のマニュアル化ですが、社内で探索的テストとセッションベースドテストのやり方をマニュアル化しています。ISTQBを学習したメンバーであれば、すぐに一通りの流れを把握できるようになりました。
2. 集中的な業務経験
人材育成の第一人者である東京大学准教授の中原淳氏が、業務経験について著書『フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術』の中で、以下のように述べています。
三十年ほど前まで、人材開発の世界では、研修や教育プログラムの研究や評価が非常に盛んでした。(中略) それが二十年ほど前に見直され、やはり「業務経験こそが最も大きな成長の資源である」という考え方が広まってきました。(中略) 人材開発の世界では、業務経験から学ぶことを「経験学習」と言います。
出典：『フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術』（中原淳著、PHPビジネス新書）
つまり、いくらトレーニングをしても、業務経験が伴わないと、人材は成長しないことになります。この点、弊社はテスト専門会社なので有利です。弊社の社員は四六時中テストを実施しているため、集中的にテストの業務経験がたまります。
また、弊社では、経験の浅いメンバーが、経験豊富なメンバーとペアになってテストを実施するペアテストを実施しています。ペアテストでは、テスト実施するテストオペレータと、テスト実施について質問するナビゲーターという役割を設けます。
テストオペレータとナビゲーターは、一定期間ごとに役割を交代します。こうすることにより、テスト経験の浅いメンバーは、テスト経験豊富なメンバーの業務経験やノウハウをじかに学ぶことができ、急成長していきます。
3. フィードバックの仕組み
東京大学准教授の中原淳氏は、著書内で以下のように述べています。
いつかは自律して、自分で自分を律さなければならないにしても、自律を獲得するには、 若い時期に他人に律せられる「他律」の時期が必要です。成長するためには、正しく進んでいるかどうかを誰かにチェックしてもらい、指摘してもらうこと、つまりフィードバックが欠かせません。
出典：『フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術』（中原淳著、PHPビジネス新書）
つまり、経験が浅いメンバーが成長するためには、適切なフィードバックが必要になってきます。これを実現するために、前述したペアテストおよびセッションベースドテストで、フィードバックができる仕組みを整えました。
まず、経験の浅いメンバーは経験豊富なメンバーとペアになって、探索的テストを実施します。その際、経験豊富なメンバーから、テストのやり方について逐次フィードバックを受けます。ペアテストで探索的テストに慣れてきたら、今度は一人でテストします。
この時、セッションベーステストを適用しているので、各セッションの前後にテストマネージャより、フィードバックを受けられます。これによって、絶えず軌道修正している形になるため、経験の浅いメンバーでも品質を保ちながら、探索的テストをこなせるようになっていきます。
「テストを資産化できない」への対策
探索的テストでは、テスト計画やテスト設計を頭の中でだけで実施するので、テスト計画書、テスト設計書、テストケース仕様書などを作りません。そのため、それらの情報資産は残りません。
バルテスでは、それらに代わる3つの資産として「テストサマリーレポート」「ノウハウ」そして「テスト観点表」を作成し、残すようにしています。これらの資料により、たとえ実施者が変わったとしても、前回のテストの経験を活かすことができます。
| No. | ドキュメント | 説明 |
|---|---|---|
| 1 | テストサマリーレポート | テスト終了後、不具合の内容を分析し、不具合傾向などを分析した資料 |
| 2 | ノウハウ | テスト終了後、振り返り会議を実施し、どのような教訓やノウハウを得たのかをまとめた資料 |
| 3 | 観点表 | テスト対象のテスト観点をまとめた表 |
まとめ
第2回では、探索的テストのデメリットを弊社がどのように対策してきたかについて述べてきました。デメリットの対策方法をまとめると、次の通りです。
| デメリット | 対策 |
|---|---|
| テストが担当者任せになってしまう |
1）機能一覧によるテストカバレッジの測定
2）テストチャータの作成
3）セッションベースドテストの適用
|
| テスト実施者にスキルが必要である |
1）仕組み化によるトレーニング
2）集中的な業務経験
3）フィードバックの仕組み
|
| テストを資産化できない |
以下の3つを残す
1）テストサマリーレポート
2）ノウハウ
3）観点表
|
次回は、これから探索的テストを実際にやってみたいと思う読者のために、弊社で実際に行っている探索的テストのやり方を紹介します。
