Test a website with an AI agent and get reproducible bug reports

A page can load correctly while its form sends the wrong data or its navigation loses your work. Give an agent specific operations to try, along with what should happen. The useful output is a test record and enough evidence to reproduce each failure.

Write a test brief for one user journey

Give Beeuni a reachable preview URL and describe the journey. The agent can open the site in its browser, navigate between pages, fill fields, and inspect the result. For a contact form, provide the validation rules and expected confirmation. Use test accounts and specify where submissions may go. Keep payments and live customer messages outside this test.

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.

If the page is reachable only on your laptop, the agent’s browser needs an accessible preview or an explicitly configured connection to reach it.

Read the test record before the summary

Here is a sample contact-form test record. Each row covers a separate check; loading the page successfully says nothing about whether the form works.

A bug report another person can follow

For each failure, ask for the URL, page version if known, starting state, exact steps, test input, expected result, and actual result. Attach a screenshot when available. Distinguish a visible error from an explanation of its cause: a confirmation message alone does not prove that the server accepted invalid data.

Repeat the failing steps from a fresh page or session. If the failure is intermittent, record which attempts failed and what changed. Keep browser errors as supporting evidence rather than treating every warning as the cause.

Here is a sample report for the invalid-email failure. Replace the environment details with the preview URL and page version you tested.

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.

The developer still needs to check whether the server rejected the input despite the success message. If the agent has authorized access to a test inbox or submission log, ask it to check there. Otherwise, leave server acceptance unknown.

Choose regression checks around the change

If the fix changes email validation, check a valid address, an empty address, and an invalid address. Include formats your product explicitly supports, such as an address with a plus sign. Then correct the invalid input and submit again. An error that cannot be cleared is a separate usability problem.

If the change affects submission state, focus on repeated clicks and recovery. Does the button become available again after a failed request? Does returning from the confirmation screen leave old values behind? Choose checks from the affected behavior. Repeating a long checklist after every small change can bury the case that needs attention.

Keep a check marked blocked when it could not run. A login failure may prevent the form test from starting; it does not establish that the form is broken. A changed label or layout may require updating the test instructions. Record those updates beside the rerun so a later reader can distinguish a revised test from a product fix.

Record the new page version and retain the earlier report. This is a focused functional check. Accessibility, security, load, and cross-browser testing each need their own scope and tools.

To trigger checks from your own development tool, see the agent backend guide. Keep the same test brief and report fields when you move from manual requests to an integration.