Guide · vibe testing
Vibe testing: check AI-built sites with evidence
Vibe testing uses natural-language instructions and AI-assisted exploration to check software. The term is still used in different ways. This guide uses it for a concrete workflow: choose a visitor task, define its expected outcome, collect browser evidence and retest the same claim after a fix. Start with one journey on an AI-built website, rather than asking an agent whether everything works.
Facts checked
What vibe testing adds to a quick click-around
An AI assistant can suggest paths and edge cases you did not write down. That makes exploration useful, but a confident summary is not a test result. Treat a suggestion as a lead until you can name the expected behavior, reproduce the problem and retain evidence.
Start with the website launch checklist to choose an area. This page shows how to investigate one item; the checklist covers the wider release inventory.
| Broad request | Bounded check | Evidence to retain |
|---|---|---|
| Test my app | A signed-out visitor can reach the pricing page from the home navigation at 390 px. | Start URL, navigation steps, final URL and screenshot. |
| Check the form | Submitting an empty required field displays the specified validation message. | Field selector, exact expected message, observed result and screenshot. |
| See if checkout works | In an authorized test environment, the agreed checkout journey reaches its confirmation assertion. | Approved test data, steps, confirmation evidence and any separately verified provider outcome. |
A five-step vibe testing workflow
- Choose scope. Name the URL, environment, visitor state and one journey. Use a site you own or are authorized to test. Say whether writes are allowed.
- Define the outcome. Write the expected final URL, visible control or exact message before the run. Keep an assertion that another person could check.
- Review and run. Inspect the generated steps and prerequisites, then execute in a real browser. Save the route, viewport and completed-step count alongside available screenshots.
- Hand off the observed failure. Include reproduction steps, expected and actual behavior, and retained evidence. Separate a possible cause from an observed fact.
- Retest the same claim. Keep the target, plan, assertions and viewport equivalent after deploying the fix. Record a passing recheck as a scoped result that still needs resolution review.
A prompt you can adapt
Replace the URL and selectors with controls from your own app. Give the assistant a defined outcome and permission boundary, then review its proposed plan.
Playwright documents assertions that retry against an expected UI state. That is different from an agent deciding that a page looks plausible. In a Sybqa plan, review the final expectVisible, expectText or expectUrl step; confirm it expresses the outcome you intended.
Practice on a fictional checkout
In the Sybqa console, Try it on our demo store fills the URL and goal for a fictional shop. Review the plan before starting it. The store uses synthetic details and makes no real purchases. The following is an illustrative review exercise, not a measured run or a claim that every test will reach the final step.
| Part of the claim | What to record |
|---|---|
| Start | The demo shop URL, viewport and initial visitor state. |
| Sequence | Open a product, add it to the cart, open checkout, enter approved synthetic details and select Place order. |
| Expected | The final assertion checks that [data-testid="order-confirmation"] is visible. |
| Observed | Record whether that assertion passed, failed, was blocked or was not reached. Include the completed-step count and available evidence. |
| Separate business proof | This fictional browser confirmation is not evidence of a real payment, order database write or email delivery. |
The fixed demo lives at a different URL. Checking it can demonstrate a separate working example, but changing targets makes a like-for-like fix comparison inconclusive. For your own application, retest the fixed deployment at the same reviewed target and preserve the original assertion.
See the QA report example for how passed, failed, blocked and not-run evidence is presented. The sample report is illustrative, not a live test of your app.
Give your coding agent a reproducible failure
- Where: target URL, route, browser and viewport; include release labels as declarations unless independently verified.
- How: the reviewed steps, approved synthetic input requirements, prerequisites and where execution stopped.
- Expected versus observed: the original assertion and the recorded failure, with links or files that were actually retained.
- What remains unknown: missing evidence, blocked actions and possible causes that have not been investigated.
- Retest: the same check after the fix, plus nearby regression checks that you choose separately.
Review screenshots, logs and traces before sharing them. Copy only the context you intend to send to the coding tool. Sybqa does not edit your code or deploy a fix. Learn how to run a reviewed QA plan on every deploy.
Use builder tests, independent checks and owned suites where they fit
Lovable already documents browser interactions, screenshots and multiple screen sizes. desplega.ai also offers natural-language testing and flow discovery. AI exploration and URL onboarding are shared capabilities; they do not establish an exclusive Sybqa advantage.
Use builder tests while developing. Add an independent check when you want to review the deployed URL and keep a scoped release record. If you need a fully owned scripted suite, consider the Playwright comparison. Use the testing-software guide to compare ownership and maintenance requirements.
Sybqa can create a reviewed plan and return an evidence report. Its free plan provides 10 runs a month after sign-up without AI review; AI-assisted review uses the paid offer. Check pricing before choosing the workflow. No head-to-head accuracy, speed or cost advantage is claimed here.
What a passing vibe test does not prove
- A screenshot does not prove a database write, inbox delivery or payment settlement.
- One viewport does not prove the other screen sizes, browsers or authenticated roles work.
- A failed setup or unavailable session is blocked coverage, not a confirmed product defect.
- A passing recheck does not erase earlier failures or establish that an intermittent issue cannot return.
- AI exploration does not replace manual accessibility review, security testing or a release owner’s decision.
Keep a record of what ran and what remains open. The false-positive guide explains how to separate model observations, environment failures and reproducible defects.
Common questions
What is vibe testing?
The term describes testing with natural-language instructions and AI assistance. In this guide it means a bounded browser workflow with a defined expected outcome, retained evidence and an equivalent fix retest; the term alone does not guarantee those practices.
Is vibe testing the same as asking AI whether my site works?
A broad opinion is not enough. Review the proposed journey, define its expected outcome, execute it in a browser and retain the actual result. Keep blocked, not-run and model-only observations separate from confirmed failures.
Should I use Lovable browser testing or Sybqa?
Lovable includes browser testing inside its development workflow. Sybqa provides a separate reviewed check and report for a supplied URL. Choose around the scope and evidence you need; using both is an option, and no measured superiority is established here.
Can I verify a fix by changing the target URL?
A run against a different target can be useful, but it is not an equivalent comparison with the original failure. Preserve the reviewed target, plan, viewport and assertions when retesting; record changed context and remaining coverage explicitly.
Sources
Related
Try Sybqa on your site
Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.