Guide · Published website smoke test
How to smoke-test a published website and retest a fix
To smoke-test a published website, open the URL visitors use, choose a small set of approved pages and one important journey, and write down the expected result before you run it. Record what actually happened and which checks could not run. After a fix reaches that URL, repeat the same checks and compare the evidence. A passing smoke test covers those checks on that run; it does not establish that the whole website works.
Have a site ready to check? Test my site free. 10 browser runs a month after sign-up, without AI review. See a sample report first.
First published · Facts checked
On this page
1. Choose a small, safe post-publication scope
Start with the public address your visitors open. A result from a local build or preview describes that environment; it does not establish what happened on the published site. Record the target URL and when you checked it. If you record a release identifier, distinguish a label you supplied from a deployment identity you independently verified.
Choose the few pages that lead to the next useful visitor action: for example, the landing page, pricing page and a route reached from the main call to action. State the expected destination or visible result. If your scope ends at a sign-up page, say so; reaching that page is not evidence that account creation works.
Need a broader release checklist? Use the website launch checklist. This guide focuses on a small check after publication and a comparable retest after a fix.
2. Write the smoke-test checklist before running it
| Check | Expected outcome to define | Evidence to retain when run |
|---|---|---|
| Published landing page | The intended page loads and its main content is visible. | Exact URL, time, observed result and an available capture. |
| Primary call to action | The link reaches the intended route; state where the check stops. | Starting route, action, expected destination and actual destination. |
| One important journey | A short sequence reaches a specific visible result without changing real data. | Ordered steps, final assertion, completed steps and any blocked step. |
| Narrow layout | The chosen page keeps its important text and controls usable at the recorded viewport. | Actual width and height, affected route and available screenshot. |
| Keyboard path | The chosen link or control can be reached and used with visible keyboard focus. | Keys used, focus destination and observed behavior. |
Write expectations narrowly enough that another person can repeat the check. “The site works” is too broad. “The main pricing link opens the pricing route and the plan heading is visible” gives you a destination and an observable outcome. A screenshot can support that observation, but cannot by itself establish that a payment settled, an email arrived or a database update persisted.
For more on screen sizes, see responsive design testing. A phone-sized browser viewport is not a test on every physical phone or a native mobile app.
3. Review the Sybqa plan, then start the check
Sybqa starts from a link and an optional goal. Paste the published URL and describe the narrow journey you want checked. Review the generated plan before starting: confirm the target, pages, steps, assertions and intended limits. If the plan does not express the journey you need, revise it before you approve a run.
The free plan provides 10 browser runs a month after sign-up, without AI review. Use the existing Test my site free action on this page to start. Check pricing for the current offering. This guide does not demonstrate that a hosted account, checkout or paid run completed successfully.
A plan is proposed work. A running check is unfinished work. Open the resulting report to see what actually executed and what evidence was retained. To learn the format before signing up, open the sample report; it is illustrative, not a result from your site.
4. Separate observed failures from unfinished coverage
Read the result for each check, not just the summary. Look for the target, route, viewport when recorded, steps or assertion, observed result and available evidence files. Keep the original run ID with the issue so the next person can find the same observation.
- Passed: the recorded check met its assertion in that run. Untested routes and outcomes remain unverified.
- Failed: inspect the observation and evidence before deciding the cause. Repeated appearances at different widths can belong to one underlying issue.
- Blocked or not run: the expected result was not established. A login barrier, unavailable target or stopped run must not become a pass.
- Review lead or inconclusive: further review is needed. A missing screenshot or incomplete journey limits what you can conclude.
For the report vocabulary and coverage limits, see how to read a website QA report. Do not turn a bounded smoke test into a claim of security certification, clinical readiness, compliance or complete accessibility coverage.
5. Hand off the finding and publish the reviewed fix
For a finding with a fix brief, use Copy fix brief or Download instructions. The brief identifies the target and run, the observed issue, affected contexts and retained evidence references when available. Journey findings can also include reproduction steps and the expected assertion.
Read the brief before sharing it. It can include URLs, routes, selectors and quoted page text. Typed form values are omitted, so supply approved synthetic test data through an appropriate private channel if reproduction needs it. Do not paste real credentials or customer details into a coding chat.
Review and deploy the change through your normal release process. Sybqa does not edit or deploy your code. The fix must be available at the URL you will retest; keep deployment evidence separate from the QA observation. For the builder-specific handoff example, see testing a published Lovable site and sending back a fix brief.
Retest the original failure with comparable evidence
Open the original run and choose Retest after a fix when it is available. Sybqa restores the retained plan for review; opening it does not start a test. Keep the target, plan and assertions equivalent, supply required test credentials again through the intended product flow, and start the retest yourself. If the retained plan is unavailable, record that limit and prepare a new reviewed check; do not describe it as an automatic comparison.
Compare the original evidence with the new run. Sybqa can assess eligible deterministic journey assertions with retained evidence. A changed target, plan, browser context or evidence mode can make the comparison inconclusive. Review leads and checks without comparable captured evidence are not automatically verified fixes.
- Passing recheck: the same configured journey assertions passed on this attempt. Review whether that evidence addresses the original issue; an intermittent failure can recur.
- Still failing: keep the original failure and use the new observation to investigate the remaining issue.
- Inconclusive, blocked or not run: retain the unresolved state and the reason. Do not label the issue fixed.
Record the baseline run ID, retest run ID, relevant check, evidence references, comparison outcome and your resolution decision. These are fields for your issue record, not a promise that every report automatically proves them. Operator-supplied revision and environment labels do not establish deployment identity or persisted business outcomes.
If the change affected other pages or behavior, review those separately. Repeating one failed journey is not a complete regression test. To reuse a reviewed plan from a pipeline, see run website QA on every deploy.
Common questions
What is a smoke test for a published website?
It is a small check of selected pages and an important visitor journey on the published URL. Define the expected result first, record what executed and retain evidence. It does not cover the whole website.
Does a passing preview test prove the published site works?
No. It describes the preview environment. Check the URL visitors use after publication, and keep deployment identity evidence separate from operator-supplied release labels.
Can I smoke-test my website with Sybqa for free?
The free plan provides 10 browser runs a month after sign-up, without AI review. Start with Test my site free, paste your link and review the plan before starting. See pricing for the current offering.
Does a passing retest mean a bug is resolved?
A comparable passing recheck means the same configured journey assertions passed on that attempt. Resolution still requires review of the original issue and retained evidence. Intermittent failures can recur, and untested behavior stays unverified.
Are the checklist and sample report actual results from my site?
No. The checklist is an illustrative planning aid and the sample report demonstrates the format. Actual results require a run against your approved target, with recorded outcomes and available evidence.
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.