CaseWriter Best Practices
Guidance for getting useful test cases out of CaseWriter and keeping them useful.
Writing Test Cases
Titles
A good title says what is done and to what.
| Good | Poor |
|---|---|
| Login with valid email and password | Test 1 |
| Add product to shopping cart from product page | Login test |
| Delete user account with admin privileges | Check functionality |
Avoid abbreviations and internal jargon, and keep the format consistent across the team.
Steps
- One action per step. Split "Click login and verify dashboard" into two steps.
- Be specific. "Enter
[email protected]in the Email field" beats "Enter data". - Give every step an observable expected result. "Dashboard loads with the user's name in the header" beats "User logged in".
Preconditions
State them precisely enough that someone else can set them up.
Good preconditions name the account, the starting screen, the data that must exist, and the environment state. "User exists" and "Page loaded" are not verifiable.
Priority
Choose priority by asking what happens if this fails in production.
| Priority | Typical use |
|---|---|
| Critical | System-breaking paths — sign-in, payment |
| Very High | Essential features with high business impact |
| High | Major functionality |
| Medium | Standard features |
| Low | Nice-to-have behavior |
Set complexity to reflect the effort a case takes to set up and run, so estimation and automation planning have something to work from.
Labels
Labels cut across the test set hierarchy. Use them for the things a folder cannot express at once — test type, platform, release, or feature area — and agree on the vocabulary before it sprawls.
Generating With AI
Give the Model Something to Work With
Detailed input produces better tests. A user story with acceptance criteria, the platforms in scope, and the relevant screens beats a one-line summary.
Combine sources when it helps: a requirements document plus screenshots, or a PBI plus the page URL.
Set the Configuration Deliberately
- Narrow the platforms. Fewer, focused platforms produce sharper tests than selecting everything.
- Match the testing focus and level to what you actually want — a regression pass and an acceptance pass are not the same set.
- Save a configuration you keep re-typing as a preset.
Use the Mindmap for Big Inputs
AI-Analyze shows the feature and test-area breakdown before any cases are written. Correcting the structure there is cheaper than fixing dozens of generated cases afterwards.
Read the Target Count Honestly
If a run produces fewer cases than you asked for, the session says so: duplicates were dropped to keep the set distinct. Extend or change the inputs rather than rerunning to chase a number the source cannot support.
Always Review What the AI Wrote
Generated cases are a draft. Read them, fix the wording, and use Regenerate with specific instructions when a case is close but not right.
Reviewing
- Filter the results to Pending Review so you work through a shrinking list.
- Approve in bulk once you have read a batch; approve runs immediately and does not interrupt you.
- Leave a comment when you reject, so the review history explains itself later.
- Use Re-review rather than editing around a decision you no longer agree with.
- Remember that regenerating or duplicating a case sends it back to Pending Review.
Organizing the Repository
- Give test sets descriptive names in a consistent format.
- Keep each set to a single clear purpose instead of mixing unrelated tests.
- Nest sets where it helps navigation, but do not build a hierarchy deeper than people will actually expand.
- Group by whatever your team searches by — feature area, test type, or release — and use labels for the dimensions that cut across it.
Maintaining
- Run Scan Duplicates periodically, especially after several generation sessions have landed in the same set.
- Bind fast-moving test sets to their source repository with GitHub Scan so code changes surface as updated, new, or obsolete cases.
- Review cases marked obsolete after a scan instead of leaving them in the tree.
- Export to Excel before large restructuring, so you have a snapshot to fall back on.
Common Pitfalls
- Vague titles and steps that cannot be followed
- Expected results that are not observable
- Approving generated cases without reading them
- Duplicate cases spread across several test sets
- Hierarchies so deep nobody navigates them
- Treating a large target count as a quality setting
