ゆるっと♪どうやってる？探索的テストの世界！

こんにちは。まーくー＆くまねこです。

ゆるっとシリーズ第3弾です。 今回はくまねこからまーくーへ、探索的テストでより良い結果を出していくためのあれこれを会話形式でお話しさせていただきます。

最後まで楽しんで読んでいただければ幸いです！

第1回 ゆるっと♪ファームウェアテストよもやま話
第2回 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験

自己紹介

今回はいつもと逆の展開…!? それでは、二人のやりとりをお楽しみください。

探索的テストについて、改めて考えてみる

あっ、まーくーさん、お疲れ様です。JSTQB ALTMの勉強中ですね。(ニヤニヤ)

そうね・・・そろそろ具体的に試験に向けて勉強しなくちゃだから！（話を合わせておこう♪）。で、どうしたんだい？（ニヤニヤしてる…何かあるな？）

前の記事を投稿した後、探索的テストのことをあれこれ考えていまして…。まーくーさん、ちょっと意見を聞かせてもらえませんか？

もちろん良いよ！早速本題に入っていきたいところだけど、私もくまねこさんも探索的テストは経験してるけど、簡単に認識を合わせておこう。

探索的テストとは？ 探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。

テスト技術者資格制度 Foundation Levelシラバス Version 2018V3.1.J03

要するに経験ベースのテスト技法で、テスト対象を動作させながらテスト設計/実行/結果の確認まで行うものだったね。詳細は以下の記事に記載があるから、お互いこちらを理解している前提で話を進めていこう！！

探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説

はい！

探索的テストの取り組み例の紹介

じゃあ、どんな感じで進めようか？

そうですね。今まで第三者検証として僕が行った探索的テストの進め方・考え方をお伝えして、まーくーさんが気がついた点をコメントする形が良いです。

OK。探索的テストのプロジェクト開始から流れに沿って話していこう。

プロジェクト開始からですね。まず実際の製品を動作させながら、製品全体の理解・お客様と探索的テストのゴールを認識合わせをするための活動を行います。プロジェクトによって仕様書などのドキュメント有無・量が異なるため、お客様の製品紹介ページやマニュアルなども参考にして、機能や画面単位で分類していきます。この分類は、お客様とテスト内容を共有する際や、テストチームにとってもテスト対象の全体像を俯瞰するのに役立ちます。

ふむふむ。まずはテスト対象を俯瞰できるようにするってことね。

洗い出した機能や画面に対して、プロジェクトの状況・目的と、前述の作業結果(製品を動作させた感触/分類結果など)から、実施優先度をつけていきます。優先度については、テストを行う観点数や工数で重み付けをしていきます。ここでお客様のご要望も反映して、観点のカスタマイズや優先度の調整を行います。 テストチャーターを使った探索的テストをする場合には、テストチャーターも作成します。探索的テストはスクリプトテストのように手順などを詳細に記載したドキュメントは残さないことが多いですが、チャーターを作成すると、お客様にもテスト担当者にもテスト範囲の全体像・テストの実施状況を見える化できて便利です！

テストチャーターとは？
テストチャーターはテストの目的や観点を記載します。作成したテストチャーターをテスト担当者間で共有して、テストを実施することで経験のバラツキを軽減することができます。

探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説

プロジェクトや探索的テストの期間によって明確なフェーズとして表現しないこともありますが、本記事では「テスト計画（準備）」という表現で進めます。

ここまでが事前準備だね。特に気を付けていたことってあるかい？

プロジェクトの目的にもよりますが、最初からテスト範囲を絞り込み過ぎないこと、ですね。まずは全体的に触ってみることで、予測と実際の動作があっているかの感触を得る期間を作ります。その結果から、不具合が潜んでいそうな機能を絞り込んでいくようにする事で、いきなりある一部分だけ深く掘り下げてしまい、他の不具合が潜んでいる部分に時間をあてられなくなるということが無くなると思います。 全体の感触を得たのち機能を絞り込み、効率的に探索できるよう計画することで、より良い成果を出すことに繋げられると思っています。 技法としてセッションベースドテストを取り入れて、機能や画面単位で時間を区切ってテストを行うようにして、全体的なテストと掘り下げたテスト、状況によってどちらにも時間が割けるように心がけています。また、”時間”という単位であれば、お客様も作業ボリューム感を実感しやすいと思います。

なるほど。不具合が出そうなところをテストできないってのは探索的テストではいちばん避けたいことだよね。時間で作業ボリューム感を共有するってのも分かりやすいと思うよ。 あと、すぐに探索的テストに入れる環境が整っているのか？対象システムにテスト可能なデータがあるのか？などの確認もこのフェーズに含まれるね！ じゃ次はテスト開始！テスト中はどんなことを心がけているのかな？

実際にテストを行ってみると、不具合の検出状況やテストのための工数が想定と異なる場合があります。そのため、計画通り全体的な確認が終了したところで中間報告の場を設けて、後半の進め方を検討していきます。例としては以下のようなケースですね。 ・ これまでに検出した不具合の発生状況から、該当機能のテストをより掘り下げていくか ・ 類似の機能/画面で問題が起きないか、対象範囲を広げてテストを行うか 探索的テスト期間中でも、テスト内容を柔軟に調整して、テストの効果を最大化できるようにしています。

適宜、テストの状況をお客様と共有しながら進めているんだね。掘り下げるか？広げるか？それが問題だ！(笑)探索的テスターの腕の見せ所だね！ 他にもテスト実施のときに気を付けていることっていったら何かあるかい？

対象製品の目的やユーザーの利用シーンを想像しながらテストを行うこと、ですね。 「ユーザーはこの機能を使ってこういうこともやりたいのではないか」と考えたり、「どういう状態になるとユーザーが困ってしまうか」など、エラーを推測しながらテスト実施しています。

ふむふむ、ユーザー目線でのエラー確認は特に大事だよねぇ。探索的テストはイマジネーションが命！で、テスト報告はどのようにしているのかしら？

チャーターから概算実施ケース数やテスト工数を集計したり、検出した不具合のまとめ（件数や重大度の高かった不具合）をご報告する形です。これらのテスト結果を元に、プロジェクトの目的に対して探索的テストの成果をお話ししていきます。また、お客様の課題に対する情報提供や、今後の品質向上に向けたアイデアをご報告します。

ありがとう。探索的テストの一連の流れはこんな感じかな？

そうですね。まとめるとこんな感じです。

きれいにまとめたねぇ！何を気にして作業を進めたのかが分かりやすい！！！

Yeah! \🐼/

まとめ -より良い結果のために必要な事とは？-

この作業の中で、まーくーさんだったら、どのようなところを工夫しますか？

この中で言ったら、テスト計画(準備)の所だね。お客様のプロジェクト内で探索的テストの立ち位置(取り扱い)や、テスト結果をどんな情報として求めているかをしっかりヒアリングするかな。つまりお客様が「探索的テスト」に「何を」求めているか？目的とゴールをしっかり把握するところが大事だと考えているよ。

ふむふむ。

とにかく不具合を見つけて欲しいのか、不具合が無いことをスクリプトテストの補完的に確認するのか、時間的な制約で準備の期間が取れないから、探索的テストでもある程度網羅的に見て欲しいとか・・・その目的とゴールをはっきりさせることで、その後の動きも変わってくるよね。

ふむふむふむふむ。

また言葉の定義もお客様と認識合わせしておくことも必要だよね。例えば、”ケース数”という言葉を使ってやり取りをする場合、同じ”1ケース”と言ってもスクリプトテストとは粒度が異なったりするし。もっともこれは、機能テストとユースケーステストとかでも同じだけど😅

ふむふむふむふむふむふむ。

（あ、ふざけ始めた・・・飽きてきたのか？？？気を取り直して）こういった探索的テストの定義をお客様としっかり認識を合わせた上で、必要であればスクリプトテストとの比較や一般的な指標(テスト密度/バグ密度etc）との比較、お客様内の指標があれば、その指標との比較なども使いながら、お互いに理解しやすい形でテスト結果をアウトプットできるようすると良いと考えているよ。

ふむふm…あっ！ありがとうございます！なるほど…ここまでの話だと、『探索的テストの内容』についてフォーカスが当たっていましたが、『目的に対する最終的な成果（何がアウトプットされるか、そこで何がわかるか）』を最初にしっかりと共有しておくことで、より良い成果を出していけるようになりますね！

そうだね、コメントした内容は探索的テストだけに限らない部分もあるけれど、上記を考慮しつつ探索的テストのメリットである、『少ない工数でのテスト』や『スピード感を持ったテスト』という特性を活かしながら進めていけると良いね！これからも心のアクセルふかしていこう！

Yeeeeeeeeeeaaaaaaaaaah! \🐼/

次回予告

今回はここまでにして、JSTQB ALの学習に戻ろうかな！（😅）次回の記事はどんな感じにしようか？

次回のまーくー＆くまねこは、 ・まーくー、JSTQB ALTM試験、いったいいつ受けるの？まだでしょ！（仮） ・くまねこ、JSTQB FL試験を振り返る！（仮） の2本でーす。

最後まで読んでいただき、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー🐻ﾉｼ 🐼ﾉｼ

🐻ゆるっと♪シリーズ🐼

第1話 ゆるっと♪ファームウェアテストよもやま話
第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験
第3話 ゆるっと♪どうやってる？探索的テストの世界！
第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！
第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！②
　　　～あきらめてしまわないでね 難しさ感じても～
第6話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂
　　　～きっとそこに信じていた、バグ管理の姿があるはずさ♪～