Test case vs test scenario

A test scenario is a statement of intent at the level of behaviour: verify that a customer can recover access to a locked account. A test case is one concrete execution of that intent, with preconditions, specific inputs, ordered steps and a single expected outcome. One scenario normally yields several cases, because the interesting variations sit underneath it — the correct code, the expired code, the code entered three times wrongly, the account that was never verified in the first place.

Keeping the two levels distinct is what makes coverage discussable. Scenarios are the vocabulary for talking to people who do not test for a living: a product owner can read forty scenarios and tell you the one you have missed. Cases are the vocabulary for execution and automation, and nobody outside the team will ever read them in bulk. Teams that only write cases end up unable to answer what is covered without reciting three hundred rows, and teams that only write scenarios cannot tell whether two people testing the same one did the same work.

Getting the split right

• Write scenarios first and in business language, then derive cases from them. Deriving in the other direction produces scenarios that are simply case titles with the detail removed.
• Give a case exactly one expected result. A case asserting six things fails as one line, and the report says nothing about which of the six was actually wrong.
• State preconditions and data explicitly, because a case that assumes the tester knows which account to use is reproducible only by its author.
• Expect the ratio to be uneven. A login scenario may need a dozen cases and a static page scenario one, and forcing a uniform depth wastes effort on the shallow end.

Detail in a case is for repeatability, not for insurance: steps written so exhaustively that nobody maintains them decay into a set of instructions everybody quietly ignores.