Guide · release candidate
Website QA checklist for a release candidate
First published · Facts checked
Short answer
A release-candidate checklist records the build, the journeys you agreed to check, and the evidence for each result. Call the build ready only when failed, blocked and not-run checks are listed and accepted. It does not prove the whole product works.
On this page
Context and limits
A release candidate is a build you might ship if the checks you agreed on hold. This checklist is the list you write before that decision: which URL, which journeys, which widths, and what evidence each result must carry. It is a planning list. The rows below are not results from a run, and finishing the list does not mean every visitor path works.
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.
Name the candidate before you check it
Write the URL a visitor would open and the build label you were given. Say whether that label came from your release notes or from something you verified yourself, such as a response header or a deploy log. A label you typed is not the same fact as an identifier you observed.
State the question this pass answers. A useful question is narrow: “On this URL, can a signed-out visitor open pricing from the home page and see the plan heading?” “Is the site ready?” is too wide to pass or fail.
Keep this list separate from a first-launch pass. The website launch checklist is for a site you have not shared yet. A smoke test is a smaller check after publication. This page is the gate for a candidate you might ship.
Write the checks before anyone runs them
| Check | Write this down first | Keep with the result |
|---|---|---|
| Candidate identity | URL, build label, and where the label came from. | The same URL and label on every row. |
| One primary journey | Start route, each action, and the visible outcome that must hold. | Steps, expected outcome, actual outcome. |
| One changed area | The route or control this candidate was meant to change. | What you compared it with, if anything. |
| Phone width | One recorded CSS width and the content that must stay usable. | Width, height, and a capture if you have one. |
| Stopped checks | Where the pass must stop: no payments, no real customer data, no deletes. | The step that was not attempted, marked not run. |
Agree the list with the person who will read it. A check that exists only in your head cannot be repeated. If a row needs an account, say which approved role, and do not put a password in the checklist.
Read every row as its own result
- Passed: that row’s assertion held on this attempt. Other routes stay unchecked.
- Failed: the assertion was checked and did not hold. Keep the observation. Do not guess the cause in the same sentence.
- Blocked: a prerequisite stopped the check. A login wall or a missing fixture is not a pass.
- Not run: the row was not attempted. Time, scope or a decision to stop belongs here, not under passed.
The report example shows those states side by side. A candidate can ship with open rows only when someone records that those rows were accepted, and why. Silence is not acceptance.
For a repeated set across many candidates, use the small-team regression guide. This checklist is one candidate, not the whole suite.
Say what ready means for this candidate
Ready means the agreed rows were run, each result is written down, and any failed, blocked or not-run row has an owner and a decision. It does not mean the product is bug-free, accessible, secure or fast.
After you ship, repeat the same rows on the URL visitors use. A pass on the candidate does not describe production until you check production. The smoke test guide is that smaller follow-up.
The free plan includes 10 browser runs a month after you sign up, with no card and no AI review. Review the plan before a run starts. Current figures are on the pricing page.
Common questions
What belongs on a release-candidate QA checklist?
The URL, the build label, the journeys you agreed to check, one look at a phone width, and a place to mark passed, failed, blocked and not run. Leave out checks you do not intend to run.
Does a finished checklist mean the website works for every visitor?
No. It means the rows you wrote were answered for that candidate. Paths you did not list stay unknown.
Can this checklist replace a regression suite?
No. Use it to decide on one candidate. A suite you keep and repeat is a different practice, described in the small-team regression guide.
Sources
Related
Related reading
- Website launch checklist: 30 checks for AI-built sites
- How to smoke-test a published website and retest a fix
- Regression testing for small teams: a practical routine
- Automated QA for web apps: build a repeatable release check
- How to file a QA result someone else can reproduce
- Which URL to test: local, preview, staging, or published
- How to write expected results before a website QA run
- What is website QA? A plain definition with examples
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.