🕵️♂️ 探索的テストの極意（完全版）：記録と再現性を確保し、属人化を防ぐ方法
1. はじめに：探索的テスト、軽視していませんか？
皆さんの開発現場では、こんな声が聞こえてきませんか？
- 「ユニットテストは整備されてるから探索的テストは不要」
- 「バグが出たら直せばいいでしょ」
- 「QAチームに任せてるし、開発者はやらない」
しかし、探索的テスト（Exploratory Testing）は、予測できないバグやユーザー視点での欠陥を発見する、極めて実務的で強力な手法です。
ただし──
このテストが「再現できない・記録が残らない・属人化しがち」なのも事実。
本記事では、実務エンジニア向けに、探索的テストの記録と再現性をどのように担保するかを体系的に解説します。
- 🧪 テスト戦略（セッションベース・自由探索）
- 🧰 便利な記録ツールとコード例
- 🧠 記録フォーマットとログ整理のコツ
- ⚠️ 失敗例とその回避策
- 🚀 AIとの統合や再現自動化の最前線
2. 探索的テストとは？ 〜知識と直感でバグを狙い撃つ〜
🔍 定義
ISTQBによると、探索的テストは以下のように定義されています：
「テスト設計、テスト実行、テスト分析を同時並行で行うアプローチ」
つまり、仕様ベースに縛られない、リアルタイムでの問題発見活動です。
🧠 特徴
| 特徴 | 説明 |
|---|---|
| 動的 | スクリプト化されていない即興性 |
| 経験依存 | 熟練度によって質が変わる |
| 柔軟性が高い | 思いつきや疑問をすぐ試せる |
| 記録が命 | 再現性がないと価値が薄れる |
📌 活用されるシーン
- 新機能リリース前のテスト
- プロダクト全体の “違和感” 探し
- 自動化でカバーできないUIの検証
3. 現場で使える探索的テスト記録術
✅ 方法1：セッションベース（Session-Based Test Management）
💡 基本構造
| 項目 | 内容例 |
|---|---|
| チャーター | 会員登録機能の異常系チェック |
| 時間枠 | 90分 |
| テスター名 | Linh Mai |
| 結果 | 3件のバグ報告、1件の改善提案 |
📝 テンプレート（Markdown）
# 探索セッションログ
## チャーター
- 会員登録画面のバリデーション動作を確認
## 観察・発見
- 全角英数字でエラーにならない
- CAPTCHA 表示が崩れるケースあり
## バグ
- メール欄に `hoge@.com` で登録できてしまう（ID:BUG-1234）
## 学び・改善点
- バリデーションルールが画面とAPIで一致していない可能性
✅ 使用ツール
✅ 方法2：スクリーンと操作を「録画・ログ化」する
🎥 スクリーン録画＋操作キャプチャ
| ツール | 機能 |
|---|---|
| Loom | 操作の録画・音声付き説明 |
| Screencastify | 軽量なブラウザ録画 |
| QA Wolf | 自動テストの記録・再現 |
| Playwright | 操作をコードとして記録 |
💡 コード例（Playwright でテスト操作ログを保存）
import { test, expect } from '@playwright/test';
test('会員登録の異常系テスト', async ({ page }) => {
await page.goto('https://example.com/signup');
await page.fill('#email', 'invalid-email');
await page.click('#submit');
const error = await page.textContent('.error');
expect(error).toContain('メールアドレスが不正です');
});
🔍 Logを残すには？
page.on('console', msg => {
console.log(`[Browser Log]: ${msg.text()}`);
});
4. よくある課題とその対処法
| 課題 | 解決策 |
|---|---|
| テストが属人化する | チャーターを事前に明文化し、チームで共有 |
| 再現できないバグが増える | 常時スクリーン録画 or 操作ログを取得 |
| 改善サイクルが回らない | セッションごとのレトロスペクティブを行う |
| テストログが肥大化・散在する | Notion や Obsidian で一元管理する |
🧠 実践Tip
- Slackの#test-reportチャンネルを作成し、定期的にログを共有する
- テストセッションごとに**「自己評価」**を記入（例：気づけたか？再現できたか？）
5. 発展編：AIや再現ツールとの連携
🤖 GPTでテストログからバグチケットを生成
- テストログをChatGPTに渡す
- 「再現手順」「期待動作」「実際の動作」などを自動整形
- JIRAやBacklogに貼り付けて活用
🧪 入力例
入力：名前：12345、エラーなしで通過
期待：数字のみは禁止
結果：バリデーションがスルーされる
出力（ChatGPTによる自動整形）
【再現手順】
1. 名前欄に「12345」を入力
2. フォーム送信
【期待結果】
- エラーメッセージが表示され、登録できない
【実際の結果】
- エラーなしで登録が完了する
【考察】
- 名前欄に数字制限バリデーションが未実装
⏺️ テストの「録画」→「再生」→「自動テスト化」
npx playwright codegen https://example.com
- 実際の操作を記録して
.spec.tsに変換 - テストシナリオのテンプレ化が容易に
6. まとめ：探索的テストは「知的行動 × システム化」
探索的テストを有効にするカギは、以下の3つです：
- 思考を記録する（チャーター＋観察）
- 行動を記録する（録画＋ログ）
- 再現可能にする（コード or 手順）
記録のない探索的テストは、明日のチームには伝わりません。
仕組み化することで、チームのナレッジになります。
🔮 今後の展望と可能性
| 技術連携 | 可能性 |
|---|---|
| LLM × テストログ | 類似バグの自動分類・分析 |
| Exploratory Bot | テスト候補の提案 |
| ChatOps連携 | Slackでのテスト実況・報告 |
💬 最後に
探索的テストは、コードカバレッジには現れない「人間ならではの感覚」から生まれる価値があります。
しかし、それをチームで共有できる知識資産に変えるには記録と再現性が不可欠です。
ぜひ、次のテストからは 「記録して、振り返る」 を意識してみてください。
探索は自由。
でも、品質はチームで守るものです。