第 38 年度 実践コース 品質技術の実践

探索的テストの学習基盤の構築- 探索的テストプロセスの定義 研 究 員：飯沼
主 査 ：飯泉
副 主 査：足立真一（株式会社 AGEST）
紀子（株式会社日立ハイテク）
久美（LIGHT SIDE PROCESS）

研究概要
エンタープライズ系のアプリ開発において，製品のユーザビリティを効果的かつ効率的に検証するために，探索的テストの需要が高まっており，探索的テストを担える技術者の増員が急務である．しかしながら，探索的テストは豊富なドメイン知識と経験を持つ熟練者が担っており，探索的テストのやり方が熟練者の個人技となっているため，探索的テストを担える技術者の養成が難しい．そこで， 熟練者の探索的テストのやり方を抽出し「探索的テストプロセス」を定義し，探索的テストの学習基盤とした．また，効果的な探索を行うための道しるべとなる探索的テストマトリクス の作成手順を示した．定義した探索的テストプロセスにならって探索すれば，探索的テストのやり方を理解できるようになり，探索的テストを実施する担当者の効率的な 養成が期待できる．
1. はじめに近年，システムの大規模化／複雑化／短納期化が進み，エンタープライズ系のアプリ開発において，実際の利用者が具体的に製品をどのように使用しているのかがよくわからないなどの製品のユーザビリティに関する実運用上の問題が増加している．エンタープライ
ズ系のアプリとは，OS の上に利用者の業務が効率化するような仕組みを持つソフトウェアのことである．そのため，製品のユーザビリティを効果的かつ効率的に検証し，製品品質を早期に向上させる必要がある．この問題の検証手段として，一般的に用いられているテストケースベースドテストだけでなく，探索的テストを併用して実施するといったように，探索的テストの需要が高まっている．しかしながら，探索的テストは豊富なドメイン知識と経験を持つ熟練者が担っており，熟練者の数が非常に少ないのが現状である．なぜなら，
これまでのテストはテストケースベースドテストが主に採用されており，探索的テストのニーズが少なかった．そのため，探索的テストはできる人だけがやるものだった． それだ
けでなく，探索的テストのやり方が熟練者の個人技つまり暗黙知となっていることに加えて，熟練者は比較的高齢であることから，熟練者のもつ暗黙知が後進に 時間をかけて十分に伝承される機会もなく，異動や退職などによって喪失している側面がある．この側面は，探索的テストを担う技術者の養成が難しいことを意味し， 探索的テストを担える技術者を増員することの妨げとなっている．
そこで，探索的テストを担える技術者を効率的に増員するために， 探索的テストの活動の中で，熟練者がどのように探索を開始し進めているかを 「探索的テストプロセス」として定義し，学習基盤とすることを考えた．具体的には，探索的テストのやり方を経験から抽出／整理して，探索的テストの経験の少ない初心者のために形式知にする．2 章では，探索的テスト実施上の問題点と課題を述べる． 3 章では，定義した探索的テストプロセスと探索的テストマトリクスについて説明する．4 章では，成果と今後の進め方を述べる．

1

第 38 年度 実践コース 品質技術の実践
2. 探索的テスト実施上の問題点と課題
2.1. 探索的テストの問題点とその原因
探索的テストについては，筆者が 2022 年に投稿した論文「探索的テストを効果的に行うための留意点のパターン化 [1] 」で説明したとおりであるが，探索的テストの特徴は，テストケースを書かないことでテスト実行に早く着手できることである．しかしながら，テストケースを書かないため，探索的テストを実施する担当者には，アプリの仕様や利用されるシチュエーションについて十分に理解している必要があることが実施上の問題点である．
2.2. 探索的テスト実施上の課題
2.1 で述べた 論文 [1] では，テスト実施においては熟練者の留意点（経験と勘）に依存するところが大きいことを問題点として挙げた．そこで，非熟練者が熟練者と同等に探索的テストをできるようにするために，熟練者の留意点をパターン化して非熟練者へ適用することを考えた．しかしながら，非熟練者へパターンを適用しようとしても，そもそも探索的テストのやり方がよくわからないため，適切なテストを実施できない．従って，探索的テストのやり方（手順）を修得する必要があるのではないかと考えた．
そこで今回は，テストのやり方に焦点を当てて検討を行った．検討の結果，探索的テストは特定のプロセスを決めず，経験に基づいて探索することが特徴であるが，経験が少ない人が熟練者並みにできるようになるまでには，試行錯誤して成功体験を積む必要があるため，時間とコストがかかってしまう．せめて，テストすべき領域を特定して深掘り始める部分を熟練者程度に引き上げることができれば，これまでよりも早く熟練者と同等の探索的テストが可能になると考えた．
そこで，本論文の課題を「探索的テストのやり方の大まかなプロセスを定義し，学習基盤を構築すること」とした．これにより，効果的かつ効率的に探索的テストの経験を積むことが可能となる．
2.3. 先行調査結果
探索的テストを実施する担当者に熟練者の やり方を移転可能とするためには，それらを何らかの方法で学習しなければならない．そこで，探索的テストの学習方法の観点で先行事例を調査した．
先行文献「Lessons Learned in SOFTWARE TESTING [2]」では，さまざまな探索的テストの体験からの教訓が示されており，探索的テストについての理解をさらに深めていくには有効である．しかし，探索的テストの経験の少ない初心者には ，教訓を活用するには至らないという問題があった．
先行文献「ソフトウェア品質知識体系ガイド‐SQuBOK GuideV3‐第 3 班 [3] 」では，探索的テストの進め方や留意点が示されているが，一般的な解説にとどまっている．
先行文献「ソフトウェア品質を高める開発者テスト ‐アジャイル時代の実践的・効率的なテストのやり方‐初版 [4] 」では，探索的テストの留意点が示されており，探索的テストの知見と考え方をさらに深めていくには有効である ．しかし，設定した課題の解決には具体的なやり方が分からないといった点で解決には不十分である．
先行事例を調査した結果，探索的テストの経験の少ない担当者に熟練者のやり方を移転可能とし，繰り返し伝授できる状態にする方法は見つからなかった． それだけでなく，探索的テストの実施者は，テスト関連の学習を行いながら，継続的にテストスキルを洗練させていかなければならないことがわかった．
3. 探索的テストの学習基盤の構築
探索的テストを担える技術者を効果的かつ効率的に養成するためには， 熟練者の個人技となっている探索的テストのやり方を真似るのが手っ取り早い．そこで，筆者の探索的テ
2

第 38 年度 実践コース 品質技術の実践
ストの実施経験からエッセンスを抽出して整理を行い，探索的テストプロセスとして形式知化し，学習基盤を構築することを考えた．そして，探索的テストの成功を達成するためのリスク回避として，探索的テストを実施する前に考案した探索的テストプロセスを確認し，テスト活動の中で活用してもらう．さらに，探索的テストにおいては，「テスト済の機能」や「セッション回数と検出したインシデント」が重要な道しるべとなる．そこで，探索的テストマトリクスの作成手順を形式知化し，併用することとする．
3.1. 探索的テストプロセス
探索的テストプロセスとは国際規格「ISO／IEC／IEEE 24774：プロセス記述のための仕様」を参考にして，熟練者のやり方をある記述書式でまとめたもので，以下の記述書式を定義した．
1) 探索的テストプロセスの記述方法＜記述書式（項目：記載方法）＞
第一段落
・プロセス名称：プロセスにわかりやすい名前を付けたもの
・プロセス目的：プロセス目的を具体的に示したもの
・プロセス活動：プロセス活動の概要をわかりやすく示したもの
第二段落・プロセス活動（Activity）：プロセス活動を具体的に示したもの・プロセス活動の説明：プロセス活動の主要なタスクを連想できるもの・プロセス活動への入力：プロセス活動ごとの作業成果物に取り込むデータ
・タスク：プロセス活動に必要なタスクを具体的に示したもの
・プロセス活動の出力：プロセス活動ごとの作業成果物
・注記：タスクやプロセス活動のやり方を注意事項として定義したもの
このような記述書式とした理由は，熟練者のやり方を，予め探索的テストを実施する担当者が十分に認識／理解しておかなければ，探索的テストの 習得は難しいと考えたためである．
探索的テストプロセスは，探索的テストを実施する担当者間で ，探索的テストの実施状況の共有を可能にするものである．そして，探索的テストの「道しるべ」とし，そこから得られた「製品」「市場」「リスク」「障害」「テストで失敗した方法」について学んだ重要なナレッジを蓄積／共有するという基本プロセスの位置付けである．
2) 探索的テストプロセスの定義
実際に考案した探索的テストプロセスの第一段落および第二段落を以下の表 1 と表 2にそれぞれ示している．また，本プロセスはシステムテストにもとからテスト計画があり，それを基にテストケースベースドテストを行っている前提である．

プロセス名称
プロセス目的プロセス活動表 1 「第一段落」
探索的テストプロセス（ET：exploratoy Testing）
1. 探索的テストを担える技術者の養成をすること．
2. 利用時品質の検証と評価を行うこと．
ET1：テスト計画の策定
ET2：テスト計画の検証と承認
ET3：テストの実施
ET4：テスト結果の検証と報告3

第 38 年度 実践コース 品質技術の実践
表2

プロセス活動プロセス活動の説明
プロセス活動への入力
タスク

プロセス活動の出力
注記

プロセス活動プロセス活動の説明
プロセス活動への入力
タスク「第二段落」
ET1：テスト計画の策定
探索的テストの実施計画を作成する．
・ソフトウェアシステムテスト計画書
・テスト対象のソフトウェア要求仕様書
・システムテストのテスト仕様書（テストケースベースドテスト用）
a. 探索的テスト目的の設定
目的を決める上では，利用者の業務で具体的に何に困っていて，どうなれば解決するかを考え，誰がどのように使うかを想定するために，利用者の目的やニーズを把握して利用者像を特定する必要がある．そこで，ユーザー要求分析によって定義された要求事項に対し，システムがどのように具現化されているかの確認を行うことが重要である．また，ユーザビリティについて，探索的テストの目的を設定することで探索する方向性を決定する． 注 1
b. 探索的テスト範囲の設定
テスト対象の探索的テスト範囲を決定する ． 注 2 注 3c. 探索的テストマトリクスの作成決定した探索的テスト目的と探索的テスト範囲をマトリクス状に並べ変えることで，表 4 に示したように探索エリアを決定する．なお，探索的テスト範囲（機能と特別確認項目）に対する探索的テスト目的をチャーターと呼んでいる． 注 4
d. 探索的テスト計画の作成
探索的テスト計画を立てる．
・探索的テストマトリクス
・探索的テスト計画書
1. ユーザビリティについては SQuaRE 規格の ISO/IEC25010 で定義されている「利用時の品質モデル」を参考にしている．例として架空の「業務用帳票印刷サービス」の場合の探索的テストの目的 の導出方法を表3 に示している．
2. システムがサービス拡大により，複数存在して連携するような場合は，他システムに類似機能が存在するかもしれない．
3. 探索的テスト範囲については，特別確認したいような項目があるかもしれない（以下 特別確認項目）．探索的テスト目的の例と同じように，架空の「業務用帳票印刷サービス」の場合の特別確認項目には「帳票の種類」がある．
4. 探索的テストマトリクスを作るためには，高度な業務知識とテスト設計スキルが必要になる．そのため，実際には有識者や経験者とよく協議することで，探索的テストの目的を設定しやすくなる．
ET2：テスト計画の検証と承認
探索的テストの実施計画を，PM／PL によりレビューして問題があれば解消する．また，探索的テストの実施計画に，問題がなければ PM／PLにより承認する．
・探索的テスト計画書
・テスト対象の設計書一式
a. 探索的テスト計画書のレビュー
PM／PL により，探索的テスト計画書のレビューを実施する． 注 1
4

第 38 年度 実践コース 品質技術の実践

プロセス活動の出力
注記

プロセス活動プロセス活動の説明
プロセス活動への入力
タスク

プロセス活動の出力
注記

プロセス活動プロセス活動の説明
プロセス活動への入力

b. レビュー議事録の作成
探索的テストの担当者が指摘事項を記録する．また，指摘事項の是正を行い，PM／PL による是正後の承認を得る． 注 2・レビュー議事録
1. テスト目的の妥当性について問われることが多い ．
＜レビュー実施前に確認すること＞
・見積もりの具体的な内容
・テスト目的の内容はプロジェクト状況を踏まえているか
2. 同じ指摘を受けないように，レビュー議事録から確認すべきポイン
トを水平展開する．
ET3：テストの実施
探索的テストの実施前に，関係者全員で作戦会議「ブリーフィング」を行う．また，探索的テストを実施して，その結果を記録する．
・探索的テスト計画書
・テスト対象の設計書一式
a. ブリーフィング
探索的テストの関係者との間で，ブリーフィングを行う． 注 1
b. 探索的テストの実施
設定したセッション単位で，探索的テストを実施する． 注 2
c. 検出したインシデントの処理
探索的テスト実施中に検出した不明な動作や事象を記録し，必要に応じて障害票の起票，および修正された障害の是正確認をする．
d. 探索的テストの実施結果の記録
セッション単位で，実施した探索的テストの実施結果を記録する．
・探索的テスト結果
・インシデント一覧
・探索的シナリオ一覧
1. ブリーフィングは，探索的テストの価値を最大化するために， テスト後半にも実施して，アイデアが出尽くしているかどうかを確認し，探索的テストの実施計画の見直しも行うとよい．
2. 偶発的に思い付いたようなことは，すぐにメモを取るとよい．また，探索するやり方の例を以下に列挙した．
＜探索のやり方＞
・製品概要から深掘りしていくように進める・市場トラブルを基にテストで拾えそうなことやテスト設計書に記載していないようなことを分析してそこを探す
・類似製品の過去障害を基に同じような問題が潜んでいないかを分析してそこを探す・システムに起きたら嫌なことや類似製品の過去にテストで失敗したようなやり方がなかったかなどを考えてそこを探す
ET4：テスト結果の検証と報告
探索的テスト結果をレビューして，問題があれば解消する．また，探索的テスト結果を発注元に報告する．
・探索的テスト結果
・探索的テスト計画書
・インシデント一覧
5

第 38 年度 実践コース 品質技術の実践
タスク

プロセス活動の出力
注記

a.実施結果のレビュー
探索的テストを実施した担当者以外の熟練者が ，実施結果のレビューを行う．
b.レビュー後のフィードバック
実施結果の不明点や不足の有無について，探索的テストを実施した担当者へ即日のうちにフィードバックする．
c.探索的テスト結果報告書の作成目安として，週次に発注元へ報告する．
・レビュー議事録
・探索的テストレポート
なし
表3

品質特性
有効性 [5]効率性 [5]

満足性 [5]

リスク回避性 [5]

利用状況
網羅性 [5]

業務用帳票印刷サービスのテスト目的の導出方法
探索的テスト目的の導出方法
有効性とは，利用者が目標を達成する時の正確さや完全さの 度合いのことで，本サービスは多数存在する帳票に対し，用紙サイズや用紙種類などが帳票ごとに細かく異なっているため，目的には「 帳票の種類ごとに期待通りの帳票レイアウトで印刷されていること」と設定する．
効率性とは，利用者が目標を達成するための正確さや完全さに関連して，使用した資源の度合いのことで，本サービスはプリンタから排紙されるトレイを各種の帳票の用途により分けたい利用者のニーズを掴んで設定を行っているため，目的には「帳票の種類ごとに分別されてプリンタから 排紙されていること」と設定する．
満足性とは，ある利用状況でシステムおよびソフトウェアが使用されるとき，利用者ニーズが満足される度合いのことで，本サービスは利用者の繁忙期になるとプリント待ち状態が発生して業務が遅延することを回避する目的で利用頻度の少ないプリンタへの切り替えを利用者が簡単にできるようにしているため，目的には「プリンタの指定方法や印刷設定の変更が直感的でわかりやすいこと」と設定する．副特性として実用性／信用性／快感性／快適性があり，目的ごとに分類することで利用者の想定がしやすくなる．
リスク回避性とは，システム・ソフトウェアを使用する時の，潜在的なリスクを緩和する度合いのことで，本サービスはプリンタから目的の帳票が排紙されなくなるリスクを回避するため，目的には「印刷待ち・プリンタの用紙切れ・トナー切れ・紙詰まり・その他の故障が発生した際には代替プリンタから帳票が印刷されること」と設定する．副特性として経済リスク緩和性／健康・安全リスク緩和性／環境リスク緩和性があり，目的ごとに分類することでリスクの想定がしやすくなる．
利用状況網羅性とは，想定された利用状況および想定を超えた利用状況の両方においてシステムまたはソフトウェアが利用できる 度合いのことで，本サービスは利用者の業務の繁忙期にも耐えうるシステムであるが，業務に与える影響を踏まえて想定を超えた場合に備える必要があるため，目的には「 業務の繁忙期に想定を超えるような量の帳票が印刷された場合や業務中になんらかのエラーが発生した場合にもシステムが異常な状態とならずに復旧し，正しく印刷されること」と設定する．副特性として利用状況完全性／柔軟性があり，目的ごとに分類することで利用者が意図した利用状況の想定と意図していないような利用状況の想定がしやすくなる．
6

第 38 年度 実践コース 品質技術の実践
3.2. 探索的テストマトリクスについて
探索的テストマトリクス [6] （以下 マトリクス）とは，開発スケジュールの変更に応じて，テスト優先度の高い箇所を特定して関係者同士で共有することを目的としたものである．筆者が作成するマトリクスは，テスト対象の機能および特別確認項目 として利用時品質を検証することを主目的としており，表 4 に示すような探索エリアを正確に特定するためのものである．また，そのための入力情報として，テストケースベースドテストの結合／システムテスト仕様書のテストケースの内容から組み合わせパターンを確認 する．そして，組み合わせで網羅していないようなところを探索エリアとしている．なぜなら，特定した探索エリアを探索することで，テストケースベースドテストでは何を確認していないかをよく知ることに繋がるため，テストケースベースドテストのテスト設計の抜け漏れがわかることでテストの価値が向上するからだ．
マトリクスは，実施したセッション回数と検出したインシデントの数によって，探索エリアの怪しさを表現できる．例えば，インシデントの数は障害の多さを示すものではなく，探索している担当者の理解の深さに依存しているものと考え られ，仕様が不明瞭な点が多いことが想定できる．そのような場合には，実施したセッション回数が例え十分だとしても，別の担当者を割り当てることがテストの抜け漏れの観点で特に重要となる．また，検出されたインシデントの情報は，次に同じ探索エリアを探索する人の参考 情報としても有用である．なお，マトリクスの詳細は付録 1 に記載している．
利用時品質を検証するためのマトリクスの例を表 4 に，作成手順を以下に示す．
＜利用時品質を検証するためのマトリクスの作成手順＞
1. 探索的テスト計画書のテスト目的から探索的テスト対象とする利用時の品質特性を確認し，マトリクスのテスト方針欄の同じ利用時の品質特性に〇を付ける．
2. ソフトウェアシステムテスト計画書からテスト範囲を特定する ．
3. テスト範囲で指定された機能をシステムテストのテスト仕様書からすべて抜き出して，マトリクスのテスト範囲の機能欄に転記する．
4. テスト範囲で指定された機能以外の特別な確認項目をソフトウェアシステムテスト計画書から抜き出して，マトリクスのテスト範囲の特別確認項目欄に転記する．
5. テスト範囲に記入された各項目（機能／特別確認項目）に対して，手順 1 の探索的テス
ト対象の品質特性のみ，利用時品質のどこに該当するかを判定し，該当するところに〇を入れる．また，対象外の品質特性の欄には，N/A（適用外）を入れる．
6. 探索的テスト方針で決定した利用時品質のところに該当する機能および特別確認項目を探索的テスト対象とする．
7. 探索的テスト対象にチャーターを設定する．チャーターには探索的テスト対象に対して何を確認するかの簡単な説明を記載する．実施中は必要に応じてチャーターを更新し，セッション回数／インシデント数／不具合数を記録する．
表4

探索的テストマトリクス

探索エリア〇：該当，-：非該当，N/A：適用外，●：探索済み

7

第 38 年度 実践コース 品質技術の実践
3.3. 探索的テストプロセスおよびマトリクスの効果
表 1 と表 2 に示した探索的テストプロセスにより，探索的テストを実施する担当者に基本的な手順を支援することができる．そして，探索的テストを実施する担当者が，ET1 とET2 を経ることで，有識者と経験者の知見を得て利用者像の特定方法と業務知識を習得し，マトリクスを自らの力で作れるようにしていくことができる．ただし，考えられる課題として，有識者と経験者の知見を得る際に，だれがどのような知見を有しているかが不明瞭のため，プロセス活動に慣れるまでには実施経験をある程度積んでいく必要がある．
マトリクスの役割は，探索的テストの「道しるべ」であり，「製品」「市場」
「リスク」
「障害」
「 テストで失敗した方法」について学んだ重要なナレッジを蓄積 ／共有することである．
具体的には，チャーターに設定／入力した情報がナレッジとなり，紐付けられた探索的テスト結果に蓄積／共有することができる．また，生み出される効果については，探索的テストを実施する担当者の学習基盤となることだけでなく，複雑なシステムテストにおいて，合理的にテストのバラツキを抑制することで ，テストの価値を最大化することにある．
4. 結論
4.1. 成果
探索的テストの実施者不足の解消を実現するために， 探索的テストの実施経験を基に探索的テストプロセスを定義し，マトリクスの利用を提案した．定義したテストプロセスにならって探索することにより，熟練者がどのように探索を開始し進めているかを学ぶことができるようになる．また，マトリクスを利用することで，効果的な探索的テストの実施を期待できる．
4.2. 今後の進め方
今後，考案した探索的テストプロセスを探索的テストの経験の少ない初心者に使ってもらい，探索的テストプロセスの有効性を検証 ，改善していく．また，探索的テストプロセ
スのタスクに探索的テストパターン [1]リスト（熟練者から収集したパターンを定義したもの）を用いて，探索的テストの留意点を確認するようなタスクを追加するなどブラッシュアップしていく．
今後の課題として，今回提案したマトリクスを工夫し，ユーザビリティ以外への適用を検討していく．また，今回提案したプロセスは，エンタープライズ系のアプリ開発におけるテストケースベースドテストと探索的テストの併用を前提としているが，他の種類のやり方も検討していく．
5. 参考文献[1] 飯沼真一，“探索的テストを効果的に行うための留意点のパターン化 ”,株式会社 AGEST，
ソフトウェア品質シンポジウム，2022.
[2] Cem Kaner・James Bach・Bret Pettichord [著]，“Lessons Learned in SOFTWARETESTING”，Published by John Wiley &amp； Sons，Inc．，New York．，2002．
[3] 飯泉紀子・鷲崎弘宜・誉田直美[監修]SQuBOK 策定部会[編]，“ソフトウェア品質知識体系ガイド‐SQuBOK GuideV3‐第 3 班”，p.205，2020.
[4] 高橋寿一[著]，“ソフトウェア品質を高める開発者テスト‐アジャイル時代の実践的・効率的なテストのやり方‐初版”,翔泳社，第 11 章 探索的テスト，2021.
[5] 谷津行穂[著]，株式会社シンフォーム，“システム及びソフトウェアの品質測定量とその測定方法”，利用時の品質の特性の測定，p.41，2015.
[6] 上田和樹・丹場順次・工藤修悟[著]，日本ナレッジ株式会社，“短納期型開発プロジェ
クトのためのテスト手法「FaRSeT（Flexible and Rapid Software Test）の適用と効果」”，
探索的テストマトリクスの作成，2018.
8