Test Cases Design¶
All test cases should be logged as tasks in ClickUp under Trove > Test Cases. Every test case will be saved as a checklist template in ClickUp.
Organisation tip
Create a task or folder per feature to make cases easy to locate. For example: Trove > Test Cases > Login, Trove > Test Cases > Dashboard, Trove > Test Cases > Vendors.
The goal is to create test cases and scenarios that will be used during testing. Each test case includes steps, expected results, and test data.
Format of a good test case¶
| Field | Description | Example |
|---|---|---|
| Test Case ID | Unique ID to track, manage, and reference individual cases | 86d2xc8uj |
| Title | Short but descriptive | Valid Credentials - Success |
| Preconditions | State of the system before testing begins | User should have an existing registered account |
| Detailed Steps | Clear, numbered actions to perform | 1. Open App 2. Enter email 3. Enter password 4. Click Login |
| Expected Result | The exact outcome if the feature works correctly | User is redirected to the Dashboard page |
| Actual Result | Filled in during test execution | Page has been redirected to Dashboard page |
Automated vs manual test cases¶
For API endpoints and customer checkout flows, automated tests in the codebase serve as living test cases — they run on every PR and don't need to be re-executed manually. When writing manual test cases in ClickUp, note whether the scenario is already covered by automation to avoid duplication.
- If the feature is an API endpoint, check Writing API E2E Tests to see if a spec exists.
- If the feature is a customer-facing browser flow, check Writing Playwright Tests.
Manual test cases should focus on areas automation doesn't cover: visual layout, cross-browser behaviour, exploratory flows, and edge cases specific to real content and data.
Guide to writing good test cases¶
One feature per case Focus on a single feature — don't combine different features into one test case.
Use action verbs Always start steps with action verbs: Click, Select, Verify, Open.
Be specific
| Example | |
|---|---|
| Good | Enter a password with 10 characters |
| Bad | Enter a long password |
Always include the negative flow Don't only test the happy path. Include cases for invalid inputs, edge cases, and error states (e.g. include invalid passwords, empty fields, expired links).