Writing test cases and scenarios

Writing test cases is daily work for most testers, so interviewers often ask you to write a few on the spot, or to fix a weak one. They want to see that your cases are clear enough for someone else to run, and that you think beyond the happy path (the normal flow where everything goes right). This article covers the vocabulary, the parts of a good test case, and a simple way to turn a user story into tests.

Scenario, case and script

The three words differ in how much detail they hold.

• A test scenario is one line that says what to test: "a user can apply a coupon at checkout". Scenarios are quick to write, and business people can review them for coverage.
• A test case makes a scenario runnable. It has preconditions, steps, test data and an expected result. One scenario usually becomes several cases: a valid coupon, an expired coupon, a coupon below the minimum order value, the same coupon used twice.
• A test script is the detailed set of instructions that runs a test. In automation it is the code, for example a Selenium test (Selenium is a tool that controls a web browser from code) that applies the coupon and checks the total.

What a good test case holds

Here is one complete case:

Field	Example
ID and title	TC-031: Registered user signs in with a valid email and password
Requirement	Story LOGIN-12 (the ID of the user story in the team's task tracker)
Preconditions	Account qa.user01 exists and is active; the user is signed out
Steps	1. Open the login page. 2. Enter the email. 3. Enter the password. 4. Click Sign in.
Test data	qa.user01 from the test data sheet
Expected result	The dashboard opens and shows "Hello, QA User"; no error appears
Priority	High

After you run it, you add the actual result and a status: passed, failed or blocked (blocked means you could not run it, for example because the login page is down). The requirement link lets anyone trace which requirements are covered. The expected result is exact, so two testers reach the same verdict. "Should work properly" cannot be checked; "subtotal 1,000.00, tax 180.00, total 1,180.00" can. Work out the expected result from the requirement before you run the test, never from what the screen happens to show.

Two habits make cases much better. Keep one condition per case, so a failure points to one cause. Keep cases independent of each other, so they can run in any order, which matters as soon as they are automated.

Positive and negative cases

Positive cases use valid input and normal use, and check that the system works. Negative cases use invalid input or wrong actions, and check that the system rejects them safely. For a 10-digit mobile number field, 9 digits, letters and an empty value are negative tests. A negative test passes when the system shows a clear message, does not crash, saves no bad data and leaks nothing useful to an attacker. Boundary values give natural negative cases just outside each valid range. Many real bugs live on the negative side.

From a user story to test cases

1. Read the user story (a short description of a feature, written from the user's point of view) and its acceptance criteria (the conditions that must be true for the story to be done). Each criterion becomes at least one positive and one negative case.
2. Apply techniques: boundary values for limits, decision tables for combined rules, state transitions for workflows.
3. Add what the criteria forget, such as repeating an action, pressing the browser's Back button, refreshing the page, or security.
4. Write down questions for the product owner (the person who decides what the product should do).
5. Ask a peer, developer or business analyst (the person who writes and explains the requirements) to review the cases.

Example: a password reset story says the link is valid for 30 minutes, the new password must be 8 to 64 characters with a digit, and a link works only once. You would test the happy path, the link just before and after 30 minutes, passwords of 7, 8, 64 and 65 characters, a password with no digit, the link used twice, and an unknown email that must not reveal whether the account exists. Then you would ask: if a user requests two resets, does the first link stop working?

How to answer in an interview

When asked to write cases, say the scenario first, then list cases grouped as positive, negative and boundary, with exact data. When shown a weak case such as "Title: Check login. Steps: login and check. Expected: should work fine", name what is missing (preconditions, actionable steps, data, a checkable result, a requirement link), rewrite it, and split other conditions such as a wrong password into their own cases.

Common mistakes

• Vague expected results like "works as expected".
• Several conditions in one case, so a failure does not say what broke.
• Only happy-path cases.
• Real customer data in test data.

Recap

A scenario says what to test, a case says exactly how, and a script runs it. Good cases have preconditions, steps, data and an exact expected result, one condition each. Cover negative and boundary cases, and raise gaps in the story early.