Start with one workflow, not an entire website
A request such as “check the website” leaves too many decisions unstated. Which environment? Which account? Is clicking Pay allowed? A useful first browser task has a known starting page, a small set of expected outcomes, and a point where the agent must stop.
This walkthrough uses a fictional storefront running locally. The product, accounts, and results are illustrative, not a record of a customer deployment. The goal is to verify checkout behavior without contacting real customers or making a real payment.
Prepare the environment before asking for clicks
Open the project in Onevium and make the intended browser surface available. Start the preview using your project's documented command, or ask the agent to inspect that command first. A running process is not proof that the correct page loaded: verify the URL and environment label.
Use a test account and the payment provider's sandbox. Keep production tabs out of scope. Log in yourself when needed; do not put passwords or payment details into a prompt. A written instruction is not a security boundary, so retain appropriate tool permissions and use an account that cannot perform production actions.
- Name the permitted origin and starting path, for example http://localhost:3000/cart.
- State whether submitting a form, creating a test order, or sending a notification is allowed.
- List the expected result of each check, including the negative cases.
Give the agent a test brief it can actually finish
Use a brief like the one below after you have prepared the test environment. Adapt the selectors, account, and acceptance criteria to the application; the example does not assume a particular framework or payment provider.
Check http://localhost:3000/cart using the test account I have opened.
1. Empty cart: checkout is unavailable and the next action is clear.
2. Add one test item: quantity and total agree on cart and checkout.
3. Leave a required field empty: show a useful validation message.
4. At a narrow viewport, verify labels, totals, and the submit button.
Do not make a payment or submit the final order.
Return expected versus observed behavior and evidence for each case.
Stop if redirected outside localhost or if real customer data appears.Read the evidence, not just the completion label
As the agent navigates and inspects the page, check that the visible browser is still the intended test surface. Ask for a screenshot of a layout failure, or the relevant console or network result when diagnosing a failed request. Capture only what is needed and remove account details before sharing.
The final summary should distinguish passed checks, failures, and checks that were not run. If the payment button was deliberately not pressed, payment completion is not verified. If a request timed out, the result is inconclusive rather than a successful test.
Turn a useful run into a repeatable check
When a failure is found, save the reproduction steps before requesting a fix. Repeat the same failing case after the change, then test adjacent behavior. For release-critical paths, keep deterministic automated tests alongside the exploratory browser run; the two approaches answer different questions.
Only schedule the workflow after the manual run has a clear environment, safe credentials, and a recipient for results. A scheduled run still needs the desktop, network, and connected tools to be available. Avoid duplicate test orders or repeated notifications by defining what happens when the task retries.