Expected vs actual result
The expected result is what the software should do for a given input, written before the test runs and taken from the specification or another oracle; the actual result is what the software did when the test ran. A test passes when the two match, and a bug report is the record of a case where they did not, so both halves belong in every test case and every report.
The longer version
Every test case ends in a comparison. The expected result is the right-hand side of it, decided in advance: after a valid card is entered, the confirmation page shows the order number, an email is sent, the basket is empty. The actual result is the left-hand side, observed during the run: the confirmation page showed, no email arrived. Writing the expected side first is what makes the comparison honest; an expected result written after the run tends to describe what happened, and the test then passes by construction.
The pair is distinct from the steps to reproduce, which are the instructions that get somebody to the point where the comparison is made. In a bug report the three sit together: the steps, what should have happened, what did happen. A report that says checkout is broken carries an actual result without an expectation, and the developer has to guess what the reporter wanted. A report that quotes the specification carries an expectation without an observation, and nobody knows what was seen. The expected result is also where the acceptance criteria meet the test: the criterion is the expected result in its general form.
Most reports fail on the actual side: it does not work, the page looks wrong, nothing happens. Each is a claim that the results differed, without the observation that would let somebody else check. The expected side fails when the expectation is one nobody could have known: a tester expects the behaviour of the previous version, the product owner changed it on purpose, and the report is a dispute about the specification filed as a bug. Triage separates those by asking where the expectation came from.
Common questions
What is the difference between expected result and actual result?
The expected result is what should happen, written before the test from the specification or another oracle. The actual result is what did happen when the test ran, recorded as an observation. A test passes when they match; a bug report documents a case where they did not, and needs both so that somebody else can confirm the mismatch.
Who writes the expected result in a test case?
The person designing the test, before it runs, from the specification, the acceptance criteria or whatever oracle the team has agreed on. Writing it afterwards, from what the software did, turns the test into a description of current behaviour. When the expected result is disputed, the dispute is about the specification and goes to the product owner.
What should a bug report say under actual result?
The observation, in enough detail that a reader can tell it apart from the expected one: which page showed, which message appeared, which value was displayed, what was in the console. Phrases like 'it does not work' state that a difference exists without saying what it was, and the report then depends on somebody reproducing it to find out.
Can expected and actual results differ without there being a bug?
A mismatch proves that the expectation and the observation disagree, not which one is wrong. The expected result can be stale, copied from a version the product owner has since changed on purpose, or derived from a misread specification. Triage settles it by asking where the expectation came from, and a mismatch traced to the expectation is a specification dispute rather than a defect.
Where do expected and actual results go in a test case?
The expected result sits beside each step or at the end of the case, filled in when the case is written. The actual result is a separate column or field that stays empty until the run, when the tester records what was observed and marks the step passed or failed. Keeping them apart is what stops the expected column from being edited to match what happened.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.