Guide · environments
Which URL to test: local, preview, staging, or published
First published · Facts checked
Short answer
Test the URL that matches the decision. Use a preview or staging URL to judge a candidate, and the published URL to judge what visitors get. Write that environment on the result. A pass on one URL does not describe the others.
On this page
Context and limits
A QA result describes the URL you opened, not the site in general. Local, preview, staging, and the published site can disagree. Choose one environment for the decision you are making, name it on every row, and do not treat a pass on a different URL as the same fact.
Have a site ready to check? Test my site free. Add your URL and review a test plan before starting a run. See a sample report first.
Match the URL to the decision
Write the decision in one line before you pick a host. “Should we merge this preview?” needs the preview URL for that revision. “Can a visitor complete this journey today?” needs the published URL. A local server answers whether your machine can run the app.
- Local. Your computer. Useful while you build. It does not describe a shared preview or production.
- Preview. A temporary URL for one branch or commit. Useful before merge. Protection, seeds, and environment variables may differ from production.
- Staging. A shared pre-production host. Useful for a candidate the team can open. Data and integrations may be fakes. Say so.
- Published. The host visitors use. This is the only result that describes the live site.
The Next.js and Vercel preview guide is the specific case for those hosts. The authenticated preview guide separates a protection wall from the app behind it. This page is the choice of URL, for any stack.
Write the environment on the result
Put the full URL on the result, not the word “staging” alone. Add the build label if you have one, and say whether you verified it or only typed it. If a login wall or a deployment-protection page is what the browser showed, the result is about that wall, not about the app behind it.
| Field | Write this | Leave unknown if you do not have it |
|---|---|---|
| URL | The exact address the browser opened. | Never invent a host. |
| Kind | Local, preview, staging, or published. | If you are unsure, write Unknown and the URL only. |
| Revision | Commit, deploy id, or the label you were given. | Unknown, plus where you looked. |
| Data | Empty, synthetic, or a copy of production. | Unknown. Do not guess that it matches production. |
Do not borrow a pass from another environment
A preview pass does not mean production works. A production pass does not mean the unpublished branch works. When you promote a build, run the same claims on the URL visitors will use. The smoke test is that shorter follow-up. The release-candidate checklist is the gate before you call a build ready.
Keep blocked rows when the environment stopped you: a protection page, a missing seed, or a URL that 404s. Those rows are about access, not about the feature you meant to see. Do not mark them passed because the feature works somewhere else.
Common questions
Should a release check run on preview or on the published site?
On the preview or staging URL while you are judging the candidate. Repeat the same claims on the published URL after you ship if the decision is about visitors.
Does a passing local check mean the deployed site works?
No. It describes your machine. Deployed hosts can differ in data, environment variables, and protection.
What if the preview shows a login wall?
Record the wall. That result does not describe the app behind the wall. Use the authenticated preview guide if you need to separate protection from the product.
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.
Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.