利益:
- 人間の好奇心に基づく探索的テストの性質を理解し、人工知能をパートナーとして使用してテスト憲章と直感的な手がかりを生成する能力
- 入力、タイミング、フォーマット、認可、中断などの発見軸を多様化し、各異常を生産ステップで再記録する機能
- 検出セッション自体は人間が実施するものの、準備と仕上げにのみ AI を使用するという制限を適用する機能
書かれたすべてのテスト ケースは、すでに考えられたことをチェックします。しかし、最も危険な間違いは、これまで誰も思いつかなかった場所に隠れていることがよくあります。探索的テスト (事前に作成されたスクリプトに依存せず、テスト担当者が製品を探索することで製品の学習、設計、実行を同時に行うテスト アプローチ) は、まさにこのギャップをターゲットにしています。探索的テストでは、専門家が製品を自由に操作し、「これを実行したらどうなるか」を検討し、システムの予期せぬ動作を捉えます。これは人間の直感と好奇心に最も依存するタイプのテストです。だからこそ、ここでの人工知能 (AI) の役割は「置き換える」ことではなく、好奇心を増幅し、盲点を呼び起こし、アイデアを生み出すことなのです。
この単元では、テスト憲章の印刷、ヒューリスティックの呼び出し、セッション後のメモの要約まで、AI を探索的テスト パートナーとして使用する方法を学びます。
なぜ探索的テストは依然として人間の作業なのでしょうか?
スクリプト化されたテスト (事前に手順を記述し、逐語的に繰り返すテスト) は、既知のことを確認します。探索的テストは未知のものを探索します。探索的テストの価値は、テスターが製品を見て「何かおかしい」と感じた瞬間に生まれます。 AI は、ユーザーが見ているように製品を見ることはできません。実際のユーザーを悩ませるものを感知することもできません。「このボタンは間違った場所にあります」と言って混乱させることもできません。しかし、AI は次の 3 つの点で非常に強力な助けとなります。(1) テストのアイデアの体系的なリストを作成する、(2) 忘れていたテスト軸を思い出させる、(3) 散らばった発見メモを整理されたレポートに変える。
ヒント: ディスカバリーセッションを開始する前に、AI に「テストアイデアのウォームアップ」を依頼します。セッション中は画面をAIに任せないでください。 AI はセッションの前後に役立ちます。セッション自体はあなたの好奇心によって動かされます。
ヒューリスティックとAI
探索的テスターはヒューリスティックを使用します。ヒューリスティックは、バグ探索の方向性を提供する短いリマインダーです。 AI は、コンテキストに合わせてこれらを思い出させることができます。古典的なものをいくつか:
- CRUD: データごとに作成、読み取り、更新、削除のフローを試します。誰かの邪魔をする。
- ゴルディロックス (リトル/フル/ロット): フィールドに非常に少ないデータ、完全なデータ、および大量のデータを入力します (0 文字、1 文字、10,000 文字)。
- CRUD + スケジュール: 2 つのタブで同じレコードを一度に編集し、両方を保存します。
- 中断: アクションの途中でページを更新し、ネットワークを切断し、Backspace キーを押します。
- 逆の順序: 手順を逆の順序で実行します (最初に支払い、次にカートに追加します)。
AI に「その画面にこれらの直感的な手がかりを適用して具体的なトライアルを提案する」ように指示すると、現場ですぐに使えるチェックリストが得られます。
試験条件の作成（憲章）
探索的テストは歩き回ることではありません。これは、テスト憲章 (探索セッションで何を探索するのか、またその目的を定義する短い指令) に焦点を当てています。優れた憲章は次のパターンに従います。「[ツール/データ] を使用して [ターゲット ドメイン] を探索し、[どの情報/リスク] を明らかにする」。 AI はこれらの条件をすぐに起草します。
スクリプト化されたテストと探索的テストのバランスをとる
健全なテスト戦略では、スクリプト化された (自動化された反復可能な) テストと探索的テストを組み合わせて使用します。スクリプト化されたテストは、バージョンごとに既知の動作が壊れていないことを安価に検証します。一方、探索的テストでは、これらのスクリプトでは考慮されていなかった新しいリスクを探します。両者は競合するものではなく、補完するものです。よくある間違いは、「すべてを自動化して、検出する必要がないようにしよう」と考えることです。一方、自動化はすでに知っていることだけをチェックし、知らないことを見つけることはできません。もう 1 つの間違いはその逆です。自動化を設定せずにリリースごとに手動検出に依存することです。これにより、同じ基本的なバグが繰り返し忍び寄ることになります。
AI はこのバランスを確立するのに役立ちます。検出セッションで見つかった異常を AI に与えることで、永続的なスクリプト化された回帰テストに変えることができます。したがって、ディスカバリで一度発見されたエラーは、二度と検出されずに戻ることはありません。ディスカバリーは「新しいリスクを見つける」ことを担当し、自動化は「見つかったものを手放さない」ことを担当します。 AI は両者の間の橋渡しを加速します。
ヒント: 各検出セッションの出力を、「すぐに修正するバグ」と「永続的な自動化に変えるシナリオ」の 2 つのバケットに分けます。 2 番目のバケットは、検出の長期的な価値を回帰パッケージに組み込みます。
弱いプロンプト / 強いプロンプト
弱者: 「この画面で何をテストすればよいでしょうか?」
Strong: 「『プロフィール写真のアップロード』機能については、90 分間の探索的テスト セッションを 3 つのテスト条件に分割します。条件ごとに、ターゲット、使用するための直感的なヒント (ファイル サイズ/形式/ゴルディロック/切り捨て)、試すべき 5 つの具体的なアクション、および注意すべきリスク信号 (速度の低下、画像の破損、セキュリティ) を提供します。特に、悪意のあるファイルのアップロード (大きすぎるファイル、間違った拡張子) のリスクに防御的に対処します。」
強力なプロンプト。期間、構造、手がかり、リスクの焦点を提供します。その結果、セッション中常に手元に置いておきたいロードマップが作成されます。
探索軸テーブル
軸
尋ねるべき質問
サンプルエッセイ
入力制限
極値ではフィールドは何をするのでしょうか?
10,000文字の名前
タイミング
同時処理/中断処理では何が起こりますか?
同じレコードを 2 つのタブに保存する
フォーマット
予期せぬ形式にどう対処するか?
絵文字、右から左へ記述するテキスト、HTML
権威
権限のないユーザーはアクセスできますか?
URLを手動で変更する
ステータス
無効な状態遷移は可能ですか?
キャンセルされた注文の支払いを試みる
控除
ネットワーク/セッションが中断された場合でも、データは一貫していますか?
録画中にネットワークを切断する
コピー可能な 4 つのテンプレート
1) テスト条件ジェネレーター:
あなたの役割: 上級の探索的テスター。 [期間] 分間の探索セッションを、機能:[機能] の 3 ～ 4 つのテスト条件に分割します。各条件: 目標、使用する直感的なヒント、試すべき 5 つの具体的なアクション、注意すべきリスク信号。条件パターン: 「[リスク/情報] の [ツール/データ] を使用して [ドメイン] を探索します。」
2) 直感的なキューアダプター:
これらの直感的な手がかりを次の画面の具体的な実験に変換します: CRUD、ゴルディロック (少ない/多い/多い)、割り込み、逆順、承認のバイパス。画面: [画面/フローの説明]。手がかりごとに 2 つの画面固有の実験を作成します。
3) 死角リマインダー:
次の機能をテストしています: [機能]。経験豊富なテスターがこのタイプの機能を最も見逃している 10 のケースをリストします。アクセシビリティ、ローカリゼーション (言語/日付/通貨)、同時実行性、セキュリティ、パフォーマンスの軸が含まれます。
4) セッションノートの要約:
以下は、私の発見セッションの生のメモです。これらを次の構造で整理します。 - 見つかった異常 (推定重大度) - 既知の再現ステップがあるもの - さらなる調査が必要なもの - 次回のセッションへの提案 生のメモ: [メモを貼り付け]
ミニケース3個
ケース 1 — 死角リマインダーが動作中。専門家は多言語アプリケーションの検索機能をテストしていました。 「ローカリゼーション軸を忘れないでください」という AI の注意に従って、彼はトルコ語特有の「i/I」文字変換を試しました。 「イスタンブール」を検索しても結果は得られませんでした。小文字変換エラーが検出されました。 AI 軸を思い出させ、専門家が試して見つけました。
ケース 2 — 憲章の焦点。新しいテスターは、支払い画面を 2 時間「サーフィン」してみましたが、構造化されていなかったため、小さなメモを 2 つ作成しただけでした。 AI を 3 つのテスト条件に分けてセッションを計画したところ、同じ期間に 11 件の異常が記録されました。そのうちの2人は真剣でした。この構造のおかげで、同じ時間が5倍効率化されました。
ケース 3 — 防御的なファイルのアップロード テスト。あるチームは、YZ が提案した「間違った拡張子/大きすぎるファイル」を自社の製品内でプロフィール写真をアップロードする際に試してみました。 50 MB のファイルによりサーバーが 40 秒間クラッシュし、サイズ制限とタイムアウトが追加されたことが判明しました。テストは防御目的で自社製品のみに対して行われた。
よくある間違い
- AI をセッションに置き換えます。発見の価値は観察と直観にあります。 AI が準備と回復を支援します。
- 予約なしで閲覧できます。集中力を欠いて何時間も過ごし、ほとんど何も見つかりません。テスト条件に焦点を当てます。
- メモを集めていない。検出で見つかった異常を本番ステップで再度保存しないと、その検出結果は失われます。
- 一つの軸にこだわってしまうこと。入力の限界を常にテストします。権限、スケジュール、ローカリゼーションの軸をバイパスします。
- 無許可のセキュリティテストを実施する。ファイル/URL の操作は、許可を得た上で自分の製品に対してのみ試みてください。
要約すれば
探索的テストは、人間の好奇心に最も依存し、書かれていないものを探すタイプのテストです。ここでは AI があなたの代わりになるわけではありません。テスト条件の概要を示し、直感的な手がかりを状況に合わせて調整し、盲点を思い出させ、乱雑なセッションメモを整理されたレポートに変えます。価値はあなたの観察と直感から生まれます。 AI はこの価値に焦点を当てて増大させます。条件を書き込み、軸を変更し、製造ステップでの結果を再度記録し、許可された範囲内でのみセキュリティ テストを実行します。
アプリケーションタスク
独自の製品から機能を選択します。 AIによる「テスト条件生成」テンプレートを使用して、60分のセッションを3つの条件に分割します。セッションを実行し (AI を使用せず、手動で探索します)、生のメモを保存します。完了したら、「セッション ノート サマライザー」テンプレートを使用してノートを整理します。結果: 少なくとも 5 つの異常、それぞれの再生ステップ、および重大度の推定。どのテスト条件と直感的な手がかりが、発見した最も貴重な異常をもたらしたかに注目してください。
チェックリスト
- [ ] セッション前にAIでテスト条件を作成し、焦点を決定しました。
- [ ] 少なくとも 4 つの異なる検出軸 (入力、タイミング、フォーマット、認可、中断) を試しました。
- [ ] 私は自分自身の好奇心からセッションを手動で実施しました。 AIを置き換えたわけではありません。
- [ ] 各異常をその再現ステップと重大度の推定とともに記録しました。
- [ ] 自分のメモをAIで定期レポートにしてみました。
- [ ] 私は、承認を得て、自分の製品に対してのみセキュリティ/操作を試みました。