Test case builder

How to use the builder

Fill in the form for one test case and press Add test case. The case joins the table below the form with an automatic ID (TC-001, TC-002 and so on), and the form clears for the next one. Title, steps and expected result are required, because a test case without any of them cannot be run or judged. When the list is complete, download it as CSV.

The CSV adds three empty columns for you to fill in while testing: the result, who tested, and the date. Open it in Excel, LibreOffice, Numbers or Google Sheets. Steps are kept together in one cell, numbered, so each test case stays on one row.

Nothing is saved between visits. If you reload the page, the list is empty again, so download before you leave.

Writing a test case that works

A good test case lets two different people run it and reach the same verdict. That comes down to three habits.

• One purpose per case. "Contact form sends with valid details" and "Contact form rejects a missing email address" are two cases, not one. Splitting them means a failure points at one thing.
• Steps a stranger could follow. Start from a known state, such as a fresh page load while logged out, and write each action as a separate line: open the page, enter a name, press Send.
• An expected result that can be judged. "Works correctly" cannot be judged. "The thank-you message appears and the enquiry arrives at the sales inbox within five minutes" can.

The priority field is there so that, when time runs short, the high-priority cases are run first. Base it on what a failure would cost: a broken payment step is high; a misaligned footer icon is low.

The template, for use without JavaScript

If the builder does not run in your browser, set up a spreadsheet with these columns, one row per test case:

About the CSV file

The file is UTF-8 encoded with a byte order mark, so accented characters such as the fada in Irish names display correctly in Excel. Any cell that begins with a character a spreadsheet might treat as a formula (an equals sign, plus, minus or at sign) is prefixed with an apostrophe, a precaution against spreadsheet formula injection. If you see an apostrophe at the start of a cell, that is why.

Questions about the builder

Can I edit a case after adding it?

Not inside the builder. Remove the case and add it again, or edit it in the spreadsheet after export. Keeping the builder simple keeps it fast and reliable.

How many cases can I add?

There is no set limit. The cases live in your browser's memory while the page is open, so a few hundred is no problem. For very large suites, a spreadsheet or a test management tool is the better home.

Can several people use it at once?

Each person's builder is separate, because nothing is stored on a server. If several testers write cases, have each download a CSV and combine the files in one spreadsheet, then renumber the IDs.

Why are the steps in one cell?

So each test case stays on one row, which makes sorting, filtering and recording results straightforward. The steps are numbered inside the cell, and spreadsheet programs show the line breaks when the cell is set to wrap text.

Naming conventions that help

Consistent titles make a long list easy to scan. A pattern that works: the feature, then the action, then the condition, such as "Booking form: submit with a date in the past" or "Search: query with no matches". Sorted alphabetically, all the booking cases then sit together. Keep the ID stable once a case exists, even if the title changes, so reports and logs that mention it stay correct.

From test cases to a test run

Once the cases exist, a test run is simple: work down the sheet, run each case, record the result, and write a bug report for every failure. The bug report generator produces reports in a format that pairs with these cases; put the test case ID in the report summary so the two link up. Our guide to writing test cases for a small website covers how many cases a site needs and which flows to start with.