SERIES: AI-POWERED DEV WORKFLOW · POST 7 OF 10
Test cases written from memory miss things. Not because developers are careless — but because memory does not reliably surface edge cases, role boundaries, or the exact conditions the FRD specified. You end up testing the happy path thoroughly and discovering the rejection flow, the concurrency case, or the permission boundary only when QA finds it — or worse, when a client does.
The FRD already contains everything a test case needs: user stories, acceptance criteria, business rules, edge cases, role-based access rules. Claude reads the FRD and structures all of that into a complete, importable test case set. This post shows the workflow, the prompts, and the full output for ClientHub’s Deliverable Approval Workflow.
The 7 Fields Every Test Case Needs
Before generating anything, it helps to know what a complete test case looks like. These seven fields are the minimum. TestRail, Jira, and most spreadsheet templates use some variation of them:
| Field | What it means |
|---|---|
| Test ID | Unique identifier. e.g. TC-DAW-01. Lets you reference it in Jira, TestRail, or a spreadsheet without ambiguity. |
| Feature | Which FRD feature this test covers. One test = one feature. |
| Preconditions | What must be true before running the test. e.g. “User is logged in as Client role. At least one deliverable exists in Pending Review state.” |
| Test Steps | Numbered, specific actions. “Click the Approve button” is good. “Interact with the UI” is not. |
| Expected Result | What the system must do if working correctly. Binary — either it happens or it does not. |
| Actual Result | Filled in during test execution. Leave blank in the template. |
| Pass / Fail | Set during execution. Never pre-fill this. |
The most commonly skipped field is Preconditions. If you do not specify that the test requires a deliverable in “Pending Review” state, half the team will run the test against the wrong state and get inconsistent results. Preconditions are not optional.
The Four Test Types — and Why You Need All of Them
Every feature needs coverage across four test types. Most manual test case writers cover the positive path and one or two negatives and call it done. The role-based and edge case tests are where bugs actually hide:
| Type | What it covers | ClientHub example |
|---|---|---|
| Positive | Happy path. All inputs valid, user has permission. System does the right thing. | Client clicks Approve on a pending deliverable. Status changes to Approved. |
| Negative | Invalid input or wrong state. System must reject gracefully, not crash. | Client tries to approve a deliverable that is already approved. Should show error. |
| Edge Case | Boundary conditions, empty states, large inputs, timing issues. | PM uploads a 0KB file as a deliverable. System should reject with a clear message. |
| Role-Based | Same action performed by different roles. Access control must hold. | Developer tries to approve a deliverable (not their permission). Must be blocked. |
Feeding the FRD to Claude: Step by Step
Step 1 — Load the FRD and Set the Scope
PROMPT 1 - Set Scope
Read docs/ClientHub-FRD-v1.md.
I want to generate test cases for the "Deliverable Approval Workflow" feature.
Before generating anything, confirm:
1. Which FRD sections cover this feature
2. How many user stories exist for it
3. What roles interact with this feature
Then wait for my confirmation before generating test cases.Waiting for Claude to confirm scope before generating is worth it. For ClientHub, Claude identified three FRD sections (upload, review, notification), four user stories, and three roles (PM, Client, Developer). That framing shapes every test case that follows.
Step 2 — Generate the Full Test Case Set
PROMPT 2 - Generate Test Cases
Generate a complete test case set for the Deliverable Approval Workflow.
Requirements:
- Cover all four test types: positive, negative, edge case, role-based
- Minimum 10 test cases
- For each test case, include:
Test ID (TC-DAW-XX format)
Type (positive / negative / edge case / role-based)
Description (one sentence)
Preconditions (what must be true before running)
Steps (numbered, specific)
Expected Result (what the system must do)
- Base all acceptance criteria directly on the FRD
- Do not invent behaviour not specified in the FRDThe Full Test Case Set: Deliverable Approval Workflow
Here is the complete output for ClientHub’s Deliverable Approval Workflow. Ten test cases, all four types covered, based directly on the FRD:
| ID | Type | Description | Preconditions | Steps | Expected Result |
|---|---|---|---|---|---|
| TC-DAW-01 | Positive | Client approves a pending deliverable | Logged in as Client. Deliverable in “Pending Review” state. | 1. Open project. 2. Open deliverable. 3. Click Approve. 4. Confirm dialog. | Status changes to “Approved”. PM receives email notification. |
| TC-DAW-02 | Positive | Client rejects a deliverable with a comment | Logged in as Client. Deliverable in “Pending Review” state. | 1. Open deliverable. 2. Click Reject. 3. Enter comment. 4. Submit. | Status changes to “Rejected”. Comment saved. PM notified with reason. |
| TC-DAW-03 | Negative | Client tries to approve an already-approved deliverable | Logged in as Client. Deliverable already in “Approved” state. | 1. Open deliverable. 2. Attempt to click Approve. | Approve button is disabled or hidden. No state change. |
| TC-DAW-04 | Negative | Client submits rejection with no comment | Logged in as Client. Deliverable in “Pending Review” state. | 1. Click Reject. 2. Leave comment blank. 3. Click Submit. | Validation error shown: “Please provide a reason for rejection.” Form not submitted. |
| TC-DAW-05 | Role-Based | Developer cannot approve a deliverable | Logged in as Developer. Deliverable in “Pending Review” state. | 1. Navigate to deliverable. 2. Look for Approve/Reject controls. | Approve and Reject buttons are not visible to Developer role. |
| TC-DAW-06 | Role-Based | PM cannot approve their own uploaded deliverable | Logged in as PM. PM uploaded the deliverable being reviewed. | 1. Open the deliverable. 2. Look for Approve control. | Approve button not shown for self-uploaded deliverables. System enforces separation. |
| TC-DAW-07 | Edge Case | PM uploads a deliverable with 0KB file size | Logged in as PM. Deliverable upload form is open. | 1. Attach a 0KB file. 2. Add title. 3. Click Upload. | Upload rejected. Error: “File cannot be empty.” No deliverable record created. |
| TC-DAW-08 | Edge Case | Client approves deliverable when another approval is in progress | Two clients both have the deliverable open simultaneously. | 1. Client A clicks Approve. 2. Client B clicks Approve at the same time. | Only one approval is recorded. No duplicate status entry. System handles concurrency. |
| TC-DAW-09 | Positive | PM re-uploads after rejection — deliverable resets to Pending Review | Logged in as PM. Deliverable in “Rejected” state. | 1. Open rejected deliverable. 2. Upload new version. 3. Submit. | Status resets to “Pending Review”. Client receives notification to re-review. |
| TC-DAW-10 | Negative | Unauthenticated user attempts to access approval endpoint directly | User is not logged in. | 1. Navigate directly to /api/deliverables/{id}/approve via browser or curl. | Returns 401 Unauthorized. No state change. Approval action not performed. |
Three things worth noting about this output. First, TC-DAW-06 (PM cannot approve their own upload) came directly from the FRD business rule: “A user cannot approve a deliverable they uploaded.” That is the kind of test that gets missed when you write from memory. Second, TC-DAW-08 (concurrent approval) is an edge case Claude surfaced from reading the system description. Third, TC-DAW-10 (unauthenticated endpoint access) is a security test Claude added because the FRD specifies role-based access.
Exporting for Jira, TestRail, or Google Sheets
Once the test cases look right, get them in a format you can actually import. Claude can reformat the same output as a CSV-ready table:
PROMPT 3 - Export as CSV-Ready Table
Reformat the test cases above as a CSV-ready table.
Columns: Test ID, Type, Description, Preconditions, Steps, Expected Result
Rules:
- Use a pipe character | as the column separator (not comma)
- Replace any line breaks within cells with " / " (space-slash-space)
- First row is the header
- Wrap the entire output in a code block
I will paste this into Google Sheets using Data > Split text to columns.Importing into Jira: Save the CSV and use the Jira CSV importer (Project settings > Import issues > CSV). Map columns: Summary = Description, Description = Steps + Expected Result, Labels = Type. Or use the Atlassian MCP from Post 6 to push each test case as a Jira issue with issue type “Test” and link it to the relevant Story.
Ask Claude to Find What You Missed
After generating the initial set, run one more prompt. Ask Claude to review its own output and find gaps. It will not find everything, but it reliably catches categories of scenarios that were not represented:
PROMPT 4 - Surface Coverage Gaps
Review the test cases you just generated for the Deliverable Approval Workflow.
Identify any missing coverage:
- Scenarios the FRD mentions that have no test
- System states not covered (e.g. what if no client is assigned?)
- Missing negative tests (rejection paths not tested)
- Missing security tests (unauthenticated access, cross-role access)
- Anything the FRD specifies as a business rule with no corresponding test
List each gap as: [Gap name] — [Why it matters]For ClientHub, Claude surfaced four gaps in the Deliverable Approval set:
| Gap | Why it matters |
|---|---|
| Session timeout during review | No test covers what happens if a client’s session expires while the approval dialog is open. The approval could fail silently. |
| Email delivery failure | The FRD says PM and client are notified on status change, but there is no test for when the email service is unavailable. Does the approval still succeed? Does it retry? |
| Deliverable with no assigned client | What happens when a PM submits a deliverable but no client has been assigned to the project yet? The FRD does not cover this state. |
| Audit log on approval | The BRD requires all user actions to be logged. There is no test verifying that an approval or rejection creates an audit log entry. |
The audit log gap is the one I would treat as highest priority. The BRD explicitly requires that all user actions are logged for compliance — that was a client requirement, not a nice-to-have. The fact that we had ten test cases and none of them verified the audit log means we would have shipped that feature with unverified compliance coverage. That is exactly the kind of thing Claude’s gap analysis is for.
What Is Next
You have test cases. Before handing them to QA, run a structured review pass — not of the feature, but of the test cases themselves. Are the preconditions precise? Are the expected results binary? Are there duplicate tests that could be merged?
Post 9 covers that review pass in detail. But first, Post 8 is about the CLAUDE.md file — the context file that makes every coding prompt you write significantly more accurate. If you are about to start building ClientHub, read that one first.
Next in this series: Post 8 — The CLAUDE.md File: Your Secret Weapon for AI-Assisted Coding
Found this useful? Share it with your QA lead — they will appreciate the test case format.