AIエージェントでウェブサイトをテストし、再現可能なバグ報告を作成する
エージェントにウェブサイトのテスト計画を渡し、期待される動作と実際の動作を記録して、失敗したチェックを別の開発者が再現できるバグ報告にまとめます。
ページは正常に表示されても、フォームが誤ったデータを送信したり、ナビゲーションによって入力内容が失われたりすることがあります。試してほしい操作と、期待される動作をエージェントに具体的に伝えましょう。役立つ成果物は、テスト記録と各失敗を再現するための十分な証拠です。
ユーザーの操作の流れをテストするための概要を書く
Beeuniにアクセス可能なプレビューURLを渡し、テストする操作の流れを説明します。エージェントはブラウザーでサイトを開き、ページ間を移動し、フィールドに入力して、結果を確認できます。お問い合わせフォームの場合は、入力値の検証ルールと期待する確認メッセージを伝えます。テスト用アカウントを使い、送信内容の送信先を指定してください。支払いと実際の顧客へのメッセージは、このテストの対象外にします。
Open the preview URL in your browser and navigate to the contact form.
Use the supplied test account and synthetic form data.
Try required fields, invalid email, successful submission, and repeated clicks.
Record the browser and viewport used.
For each check, report expected behavior, observed behavior, and evidence.
Capture screenshots of failures and save a reproduction report.
Mark checks you cannot complete as blocked. Do not report them as passed.ページにノートパソコンからしかアクセスできない場合、エージェントのブラウザーがアクセスできるプレビューを用意するか、接続できるよう明示的に設定する必要があります。
テスト記録を確認してから概要を読む
以下は、お問い合わせフォームのテスト記録の例です。各行は個別のチェック項目です。ページが正常に読み込まれたからといって、フォームが動作するとは限りません。
| チェック | 期待される結果 | 観察された動作の例 | ステータス |
|---|---|---|---|
| フォームを空のまま送信する | 必須項目にエラーが表示される | 必須項目の横にエラーが表示される | 合格 |
| 無効なメールアドレスを送信する | 送信が拒否される | 代わりに確認メッセージが表示される | 不合格 |
| 確認リンクを開く | 遷移先のページが開く | テスト用アカウントでは遷移先にアクセスできない | ブロック |
ほかの人が再現できるバグ報告
失敗ごとに、URL、分かる場合はページのバージョン、開始時の状態、正確な手順、テストに使った入力値、期待される結果、実際の結果を記録します。可能であればスクリーンショットを添付してください。目に見えるエラーと、その原因についての説明は区別しましょう。確認メッセージが表示されただけでは、サーバーが無効なデータを受け入れたとは証明できません。
新しいページまたはセッションから、失敗した手順をもう一度実行します。失敗が断続的に起こる場合は、どの試行が失敗したか、何が変わったかを記録します。ブラウザーのエラーは補足的な証拠として扱い、警告をすべて原因と決めつけないでください。
以下は、無効なメールアドレスで失敗した場合の報告例です。テストしたプレビューURLとページのバージョンに合わせて、環境の詳細を置き換えてください。
Title: Contact form shows success for an invalid email
Environment: supplied preview URL; record deployed version
Starting state: fresh page, signed out, empty form
Steps:
1. Enter Test user in the name field.
2. Enter test@ in the email field.
3. Enter Test submission in the message field.
4. Click Send once.
Expected: email error appears; form stays available for correction.
Observed: confirmation replaces the form.
Evidence: screenshot of confirmation; record browser and viewport.
Unknown: whether a contact record or email was created.成功メッセージが表示されたにもかかわらず、サーバーが入力を拒否したかどうかは、開発者が引き続き確認する必要があります。エージェントがテスト用受信トレイや送信ログへのアクセスを許可されている場合は、そこで確認するよう指示してください。そうでなければ、サーバーが受け入れたかどうかは不明のままにします。
変更内容に応じて回帰チェックを選ぶ
メールアドレスの検証を変更した場合は、有効なアドレス、空欄、無効なアドレスをチェックします。製品が明示的に対応している形式も含めてください。たとえば、プラス記号を含むアドレスが該当します。その後、無効な入力を正しい内容に直して、もう一度送信します。エラーを解消できない場合は、別のユーザビリティ上の問題です。
送信時の状態に影響する変更なら、連続クリックと復旧に注目します。リクエストが失敗したあと、ボタンは再び使えるようになりますか。確認画面から戻ったとき、以前の値が残っていますか。変更の影響を受ける動作に応じてチェックを選びましょう。小さな変更のたびに長いチェックリストを繰り返すと、注意が必要なケースを見落としやすくなります。
実行できなかったチェックは、ブロックとして記録しておきます。ログインに失敗してフォームテストを開始できなかった場合でも、フォームに問題があるとは限りません。ラベルやレイアウトが変わった場合は、テスト手順の更新が必要になることがあります。再テストの記録とともに変更内容を記録すれば、後から読む人が、テストの改訂と製品の修正を区別できます。
新しいページのバージョンを記録し、以前の報告も残しておきます。これは機能を絞って確認するテストです。アクセシビリティ、セキュリティ、負荷、クロスブラウザのテストには、それぞれ別の範囲とツールが必要です。
お使いの開発ツールからチェックを実行する方法については、エージェントバックエンドガイドを参照してください。手動での依頼からインテグレーションに移行しても、同じテスト概要と報告項目を使います。