Test Case Writing Exercise
Draft structured test cases for a feature.
Pick a feature, then write positive and negative test cases for it.
About Test Case Writing Exercise
The Test Case Writing Exercise helps you draft structured test cases for a feature — each with an id, title, type (positive, negative or boundary), steps and expected result — and exports them as a Markdown table for wikis, PRs or test plans. It turns "I'll test the login form" into an explicit, reviewable list.
Writing cases down forces coverage thinking: once three happy-path rows are on the table, the gaps (boundaries, errors, permissions) become visible. Add and remove rows freely as the design evolves.
How to use
- Name the "Feature under test".
- Fill in each test case row: what it checks, its type, the steps and the expected result.
- Click "+ Add test case" for more rows; remove ones that no longer apply.
- Copy the "Test cases (Markdown table)" output into your wiki, ticket or PR description.
Frequently asked questions
How granular should a single test case be?
One verifiable behavior per case: "rejects password under 8 characters" rather than "test password validation". Small cases give precise failures — a red row tells you exactly what broke.
How many cases does a typical feature need?
Cover the happy path, each boundary, each error state and each permission level that applies. For a login form that lands around 8–12 cases. Fewer usually means missing error paths, not efficient testing.
Why Markdown tables?
They render everywhere your team already works — GitHub, GitLab, most wikis and issue trackers — and they diff cleanly in version control, unlike spreadsheets.