探索的テスト90分の進め方とチャーターの書き方

手順書どおりのテストは全部通っているのに、リリース後に「ここを押すと固まる」という報告が届く。多くの場合、その操作は誰のテストケースにも書かれていませんでした。この記事はテスト工程の話で、スクリプトに書けないバグを見つけるための「探索的テスト」を、90分のセッションとして回す方法をまとめます。

探索的テストとは「時間を区切った実験」

探索的テストは、テストの設計と実行を同時に進める手法です。画面を触って気づいたことをその場で次の操作に反映します。気ままに触るのとの違いは、目的・時間・記録の3つを先に決めておくことです。

セッションの設計：チャーターを1行で書く

セッションごとに「チャーター」と呼ばれる短い指示書を書きます。形式は次の1行で足ります。

【対象】を、【やり方・観点】で探索し、【知りたいこと】を明らかにする

良いチャーターの例

• 注文フォームを、途中で戻る・更新する・別タブで開くという操作で探索し、入力内容が失われる条件を明らかにする
• プロフィール画像のアップロードを、巨大・極小・非対応形式のファイルで探索し、エラー表示の抜けを明らかにする

悪いチャーターの例

• 「アプリ全体を触る」（広すぎて終わりが決まらない）
• 「バグを見つける」（観点がなく、毎回同じ操作に偏る）

90分の進め方

タイマーは必ずかけます。90分を超えると集中が切れ、同じ操作の繰り返しが増えます。

記録の残し方：3種類のメモを分ける

探索中のメモは、混ぜずに3つに分けると後で使えます。

1. バグ：再現できた不具合。操作手順と画面を添える
2. 疑問：仕様なのかバグなのか判断できないもの。後で担当者に聞く
3. 課題：試せなかった、時間が足りなかった、環境が用意できなかった項目

「何件バグが出たか」より、どこまで試したかが残っていることが大切です。課題の欄が空なら、次のセッションのチャーターはそこから作れます。

失敗例と対策

• 気づいたバグを調べ始めて原因を追ってしまう：原因調査は開発者の仕事です。再現手順を残して次へ進みます
• いつも同じ人が同じ画面を触る：担当を入れ替えます。新しく入ったメンバーや非エンジニアは、慣れた人が避ける操作を平気でやります
• 報告が「なんか変です」で止まる：画面と操作の流れが残っていないと、開発者は再現できません

Bugoon での実践

探索中に見つけた不具合は、その場で報告まで済ませると記憶が薄れません。Bugoon のウィジェットを検証環境に埋め込んでおけば、画面上でスクリーンショットを撮って注釈を書き込み、そこに至る操作ステップも一緒に記録できます。報告は GitHub Issue として登録され、カンバンボードでも状況を確認できます。

セッション中の報告をまとめて印を付けたり、セッション単位で振り返れたりすると、探索的テストの成果をさらに追いやすくなりそうです。いまは Issue のラベルなどでセッション名を揃えておく運用が現実的です。

まとめ

チャーターを1行書き、90分のタイマーをかけ、メモを「バグ・疑問・課題」に分ける。この3点だけで、手順書にないバグを拾う確率は大きく変わります。まずは次回のリリース前に、1画面だけで試してみてください。