みんなでワイワイやる探索的テスト - コドモン Product Team Blog

こちらは「コドモン Advent Calendar 2025🎄」および「ソフトウェアテスト・QAの小ネタ Advent Calendar 2025」の13日目の記事になります。

はじめに

みなさん、こんにちは。QAエンジニアの砂川です。

今回は、「いつでも請求」*1の下書き機能をリリースする直前に行った探索的テストの様子を紹介します。

探索的テストに関して

以前は、探索的テストは他のテストケースを作成しない "モンキーテスト" や "アドホックテスト" と同様のものと言われることが多かったですが、近年これらのテストとは異なる活動であると言われ始めました。

実際に、JSTQB Foudation Level シラバス 44ページにも下記の通り記載されています。

探索的テストは、テスト担当者がテスト対象について学習しながら、テストケースを同時に設計、実行、評価する。探索的テストは、テスト対象についてより深く知り、注力したテストでより深く探索し、まだテストしていない領域のテストを作成するために使う。

(中略)

テスト担当者はテスト目的を含むテストチャーターに従ってテスト実行をする。テストセッションの後には、通常、テスト担当者とテストセッションのテスト結果に関心を持つステークホルダーとの間で議論を行うデブリーフィングを行う。このアプローチでは、テスト目的はハイレベルのテスト条件として扱われることがある。カバレッジアイテムはテストセッション中に識別して確認する。テスト担当者はテストセッションシートを使用して、実行した手順や発見した事象を文書化する場合がある。

また、昨年末に日本でも「探索的テストの考え方　ソフトウェア開発のテスト設計とテクニック」も販売されたことは記憶に新しいところかと思います。

チームで探索的テストを行うまで

今回、「いつでも請求」の下書き機能のリリースのタイミング前に、探索的テストをチームで行いました！

探索的テストを行った背景として、以下の状況がありました。

E2EテストやAPIテストは、自動テストとして準備しており、日時実行でも問題なく動いている状況
チームにQAとして入っていたものの、他チームとの兼務でなかなか時間を割くことができなかった
以上の状況から、スクリプトテストを準備するよりも、チーム全体で探索的テストを行い、バグを取り切る活動をする方が効果的だと考えた

このような状態を整理して、チームに実施したいという旨をデイリーミーティングの場で連携し、全員揃う日を決めて、最大1時間のタイムボックスを定めて、探索的テストを実行しました。

探索的テスト実施！

探索的テストを始めるにあたり、テストチャーターとしてスプレッドシートやマインドマップを準備することもありますが、プロダクトマネージャーやデザイナーも参加していたので、堅苦しくせずにMiroで探索的テストを行う場を下記の図のように準備して、実施しました。

テストは、下記のような流れで実施しました。

1. 探索的テストの目的を定める。今回の場合は「バグを取り切る」ということでみんなでコンセンサスを取りました
2. まずは5分くらいでアプリを触ってみて「触ってみて思ったこと」エリアに付箋を出していく
3. もしその場でこういうテストしてみるといいのかな？というアイデアが出てきたら、「やってみたいこと＝テストケース」エリアに付箋を出していく
4. 探索的テスト実施！不具合を見つけたら「🐛(bug)」エリアに付箋を出していく(このときは最大で40分くらいテストしました)
　4.1 「やってみたいこと」エリアもテストケースとして組み立てられそうであれば、設計〜実施まで行う
5. タイムボックスや区切れがいいタイミングで、実施した内容をみんなで確認する
　5.1 不具合もバグとするか、仕様とするかはこのタイミングで話し合いを行う
6. みんなで感想を言い合って終わり！！

その結果が下記の通りになります。