Guide · expected results
How to write expected results before a website QA run
First published · Facts checked
Short answer
Write one observable outcome before the run, plus the start state and the step where the check stops. A pass means that sentence held. It does not cover outcomes you left unwritten.
On this page
Context and limits
An expected result is the sentence you can check. Write it before the run, as something a second person could see: a heading, a URL, a message, or a control that stays usable. “The page works” is not an expected result. A later pass or fail is only about the sentence you wrote.
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.
One sentence a stranger can see
Name the page, the action, and the thing that must be true afterward. “From the signed-out home page, the pricing link opens /pricing and the plan heading is visible” can pass or fail. “Pricing feels clear” cannot, until you name what visible evidence would count.
- Use words for things on screen or in the address bar.
- Say the start state: signed out, a named test role, or an empty cart. Do not put a password in the sentence.
- Say where you stop: before submit, before payment, or at a confirmation heading.
- Keep one outcome per sentence. A second outcome is a second claim.
After the run, the same sentence goes in the result. How to file a QA result is that later record. The bug report template is the form when the sentence failed.
Weak sentences and tighter ones
| Too vague | Writable expected result |
|---|---|
| The signup works. | Submitting the empty form shows the email error and does not leave the page. |
| It looks fine on mobile. | At 390 CSS pixels, the plan heading and the primary button are both visible without horizontal scrolling. |
| Checkout is good. | The check stops on the test-mode review step. Paying is out of scope. |
A screenshot can support the sentence. It does not replace it. If you cannot say what the picture is supposed to prove, you do not have an expected result yet.
Put the sentence in the plan you review
When you review a generated plan, check that each step’s assertion matches a sentence you wrote. If the plan asserts something you did not ask for, remove it or add it to your list on purpose. A goal you typed is not evidence that those boundaries were kept. The plan you approve is the list that will run.
The free plan includes 10 browser runs a month after you sign up, with no card and no AI review. Nothing starts until you review the plan. Current figures are on the pricing page.
Common questions
What is an expected result in website QA?
A sentence, written before the run, that names an observable outcome. Pass means that outcome held on that attempt. Fail means it did not.
Can one check have several expected results?
Give each outcome its own sentence and its own pass or fail. A bundle of outcomes hides which part held.
Does a passing expected result mean the feature is finished?
No. It means the sentence you wrote held. Behavior you did not write down stays unchecked.
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.