Expected Result

The expected result defines what should happen when a test case is executed correctly. It's the benchmark against which actual results are compared to determine pass or fail. Without a clear expected result, testing becomes subjective opinion rather than objective verification — two testers could execute the same test and reach different conclusions about whether it passed.

Characteristics of good expected results:

• •Specific: "Dashboard displays user name 'John Doe' in the top-right corner" not "Page looks correct"
• •Measurable: Can be objectively verified by any tester — no room for interpretation
• •Unambiguous: Only one possible interpretation of what "pass" looks like
• •Complete: Covers all relevant outcomes including visual state, data changes, and system behavior
• •Observable: The tester can actually see or measure the result (not just "database updated correctly" unless they can verify it)
• •Time-bound when relevant: "Email arrives within 5 minutes" or "Page loads in under 2 seconds"

Expected results can be defined at different levels:

• •Per step: What should happen after each individual action — useful for complex workflows where intermediate states matter
• •Per test case: The final outcome after all steps are completed — useful for simpler tests where only the end state matters
• •Implicit: Some expected results are understood (e.g., "no error messages appear") but it's better to make them explicit

The comparison of expected vs. actual results is the core mechanic of test execution:

• •Match → Pass: The actual behavior matches the expected result
• •Mismatch → Fail: The actual behavior deviates from the expected result — log a defect
• •Cannot Determine → Blocked: Something prevents the tester from reaching the point where the comparison can be made

Vague expected results are one of the most pervasive problems in test case quality. Results like "system works correctly," "no errors," "page displays properly," or "data is saved" are nearly useless because they mean different things to different testers. What does "correctly" mean? What counts as an "error"? What does "properly" look like? These vague statements lead to inconsistent testing — one tester might pass a test that another would fail — and missed defects that hide behind ambiguous acceptance criteria. The fix is straightforward but requires discipline: every expected result should be specific enough that two different testers would independently reach the same pass/fail conclusion.

Another common mistake is writing expected results that only cover the happy path. A good expected result for a form submission should cover not just what happens when the form is submitted (e.g., "Success message appears"), but also observable side effects: was the data actually saved? Did the confirmation email get sent? Was the user redirected to the correct page? Did the page URL change? Testers who only check the most obvious outcome miss subtle defects. For example, a form might show a "saved successfully" message but silently fail to write to the database — if the expected result only says "success message appears," the tester marks it as Pass and the defect slips through.

In practice, teams that write excellent expected results do a few things consistently. They reference specific text, values, and UI elements rather than general descriptions. They include negative expectations where relevant ("no error messages in the browser console," "no duplicate records created"). They state timing expectations for asynchronous operations. And they review expected results as part of test case peer review, asking "would a new tester know exactly what to look for?" The time invested in writing precise expected results pays off many times over through more consistent, reliable testing.