Writing test cases for a small website

A test case is a written instruction for checking one thing: what to set up, what to do, and what should happen. Writing them down before testing feels slow, but it is what makes testing repeatable. Without test cases, each tester checks what occurs to them on the day, and "we tested it" means something different every time.

Start from tasks, not pages

Going page by page produces a long list of cases that check whether pages load and very few that check whether visitors can do anything. Start instead from the tasks the website exists for.

For a small organisation's website, the task list might look like this:

• Find out what the organisation does and whether it serves my area.
• Find a phone number, address or opening hours.
• Send an enquiry or request a quote.
• Book an appointment or a place on an event.
• Sign up for a newsletter.
• Buy something, if there is a shop.

Each task becomes a group of test cases. The pages come into it naturally, because tasks pass through pages.

Then add the rules

Every website has rules, written or not. A booking form should not accept dates in the past. A quote form should insist on a phone number, or should not. Delivery might be free over a certain amount. A discount code might expire. Each rule needs at least two cases: one where the rule is met and one where it is broken.

Asking the site owner "what should never be possible?" is a quick way to find the rules nobody wrote down.

The anatomy of a test case

One purpose per case

A mistake that undermines test cases is trying to check several things in one. "Contact form works" hides at least five questions: does it send, does it reject an empty email, does it reject a malformed email, does the confirmation appear, does the message arrive? Write five cases. When one fails, the report points straight at the problem, and when four pass and one fails, the result is clear.

Steps a stranger could follow

Imagine handing the case to someone who has never seen the site. They should be able to run it without asking a question. That means naming buttons and fields as they appear on screen, giving the exact values to type where values matter, and starting from a state anyone can reach, such as a private browser window.

Keep steps short. If a case needs more than ten steps, it is probably two cases, or it needs a precondition that sets up the starting state.

Expected results that can be judged

"The form works" cannot be judged; one tester's working form is another's broken one. An expected result should describe something observable: a message with specific wording, an email arriving at a specific inbox, a page address changing, a number being calculated correctly. If the expected result depends on a business rule, quote the rule.

How many test cases?

There is no correct number, but a rough guide helps with planning:

• A brochure site with a contact form and a few key pages: twenty to forty cases, mostly around the form, navigation, contact details and content.
• A site with bookings or sign-ups: add ten to twenty cases per flow, depending on how many rules it has.
• A small shop: add cases for product options, the basket, delivery rules, discount codes, payment in test mode, confirmation emails and account features. This is where the count grows quickly.

These ranges are a planning aid drawn from the structure of the flows, not a measured average. The right number is whatever covers every task and every rule at least once.

Priorities when time is short

Mark each case High, Medium or Low based on what a failure would cost. When the launch date arrives before testing is finished, run the high-priority cases first. A useful test: if this case failed after launch, would anyone notice within a day? If yes, it is probably high.

Negative cases: testing what should not happen

Some of the most useful rules to test describe what should be refused. A booking form should refuse a date in the past; a quote form should refuse a missing email address; a discount code should refuse to apply twice. These negative cases find defects that positive cases never touch, because a form that accepts everything passes every positive test.

For each rule, write at least one case that breaks it and check that:

• the site refuses the action;
• the message explains what is wrong and how to put it right;
• nothing is created, sent or charged as a side effect;
• what the visitor already entered is kept.

The last two points matter more than they look. A refused booking that still sends a confirmation email, or a rejected form that empties itself, is a defect even though the rule itself was enforced.

Cases for content, not just features

Test cases are not only for forms and flows. Content that must be right deserves cases too:

• Phone numbers on every page match the number the business answers.
• Prices on product or service pages match the price charged at checkout or quoted on the price list.
• Opening hours, holiday closures and event dates match the source of truth.
• Legal pages such as the privacy notice and terms are the approved versions.
• Contact addresses in the footer, the contact page and confirmation emails agree with each other.

These cases are quick to run and easy to forget, and an error in any of them does direct harm. They are also good candidates for the regression set, because content can change without any change to the code.

Reviewing cases before testing starts

Share the test cases with the site owner before anyone runs them. The owner knows the business rules, and a case with a wrong expected result produces a false failure or, worse, a false pass. A short review, even fifteen minutes going through the list together, catches the cases where the tester assumed something the business does not do.

Keep the cases for next time

Test cases are an asset. After launch, the same cases become a regression suite: the set you run after updates to check nothing that used to work has broken. Store them somewhere the next person can find them, with a note of which ones were run when. Our guide to testing after CMS and plugin updates shows how to choose a short regression set from the full list.

Tools for writing cases

A spreadsheet is enough. The free test case builder gives each case the same structure and exports a CSV with empty columns for results, tester and date. When a case fails, the bug report generator turns the failure into a report; put the test case ID in the summary so the two link up.

A short worked example

The example is illustrative; the wording of messages will depend on your own site.