SERIES: AI-POWERED DEV WORKFLOW · POST 9 OF 10
Finding a gap in your test cases during QA is expensive. The feature has been built, reviewed, and deployed to staging. Now QA finds a scenario that was never tested, the developer has already moved to the next ticket, and the fix goes into a mini-cycle that delays the release.
Finding that gap during test case review is cheap. You add one row to a spreadsheet. The feature is not built yet. Nothing is broken. The gap costs thirty seconds to fix instead of half a day.
Claude can do this review. Feed it the test cases and the FRD section they came from. Ask it to cross-check. It finds the scenarios that were missed, the duplicate tests that wasted effort, and the business rules with no test coverage. This post shows the exact workflow, using the Deliverable Approval test cases from Post 7 as the input.
Six Things to Look for in a Test Case Review
These are the categories where gaps most commonly hide. A well-prompted Claude will check all six automatically, but it helps to know what you are looking for:
| # | Review item | What to look for |
|---|---|---|
| 1 | Missing negative tests | Happy path is covered; what about wrong credentials, missing fields, invalid states? Most suites undertest the “no” path. |
| 2 | Boundary values not tested | File size limits, character limits, date ranges, count maximums. If the FRD specifies a limit, there should be a test at that limit. |
| 3 | Role-based access not fully covered | Each significant action should be tested from the perspective of a role that should succeed AND at least one that should be blocked. |
| 4 | Notifications not verified | If the FRD says “user receives an email when X happens”, there must be a test that confirms the notification is triggered. Not just that X happened. |
| 5 | Integration points missing | What happens when a downstream dependency fails? Email service down, payment gateway timeout, file storage unavailable. |
| 6 | Acceptance criteria without tests | Every acceptance criterion in the FRD should map to at least one test case. If a criterion has no test, it is unverified by definition. |
The Four-Step Review Workflow
Step 1 — Load the Test Cases and the FRD Together
PROMPT 1 - Load Context
I am going to give you two things:
1. A set of test cases for the Deliverable Approval Workflow
2. The FRD section that specifies that feature
Read both. Do not start the review yet.
Confirm that you have read them and summarise:
- How many test cases you received
- How many FRD acceptance criteria exist for this feature
- How many FRD business rules exist for this featureGetting this confirmation step right matters. If Claude misses a section of the FRD or only reads part of the test cases, the review is incomplete before it starts. For ClientHub, Claude confirmed: 10 test cases, 6 acceptance criteria, 3 business rules.
Step 2 — Cross-Check FRD Against Test Cases
PROMPT 2 - FRD to Test Case Cross-Check
Cross-check the FRD acceptance criteria and business rules
against the test cases.
For each FRD item, tell me:
- Which test case covers it (by ID)
- If no test case covers it, flag it as GAP
Output as a table: FRD item | Covered by | StatusStep 3 — Find Duplicates and Redundant Coverage
PROMPT 3 - Find Redundant Tests
Review the 10 test cases for overlap and redundancy.
Flag any tests where:
- Preconditions are identical to another test
- The expected result is already verified by a different test
- The test adds no unique coverage
Suggest which tests to merge or remove.Step 4 — Generate New Test Cases for the Gaps
PROMPT 4 - Generate Gap-Filling Test Cases
Based on your review, write new test cases to fill the gaps you found.
Each new test case must:
- Use TC-DAW-XX format, continuing from TC-DAW-10
- Include: Type, Description, Preconditions, Steps, Expected Result
- Be grounded in the FRD (do not invent behaviour)
Write only the missing tests. Do not rewrite existing ones.What Claude Found: Four Gaps in Ten Test Cases
Running Prompts 2 and 3 against the ten Deliverable Approval test cases from Post 7 returned four findings — three missing scenarios and one redundancy:
| Gap | What Claude flagged |
|---|---|
| File size boundary | None of the 10 tests check what happens when a file exceeds the upload size limit. The FRD specifies a 50MB maximum — that boundary has no test. |
| Email delivery failure | TC-DAW-01 and TC-DAW-02 both assume the notification email is sent successfully. There is no test for when the email service is down. The approval flow should succeed regardless of email status. |
| Audit log verification | The BRD requires all user actions to be logged. The 10 test cases verify what the user sees, but none query the AuditLog table to confirm an entry was actually written. |
| TC-DAW-01 and TC-DAW-09 overlap | TC-DAW-01 (approve pending deliverable) and TC-DAW-09 (re-upload after rejection) both end with an approval. The approval assertions are duplicated. TC-DAW-09 can be simplified to focus only on the re-upload reset behaviour. |
The redundancy finding on TC-DAW-01 and TC-DAW-09 is worth acting on. Duplicate assertions create false confidence in coverage numbers and maintenance overhead when the feature changes. TC-DAW-09 was trimmed to focus only on the re-upload state reset, removing the approval assertion already covered by TC-DAW-01.
The Three New Test Cases Claude Generated
From the three genuine gaps (file size boundary, email failure, audit log), Claude wrote the following test cases:
| ID | Type | Description | Preconditions | Steps | Expected Result |
|---|---|---|---|---|---|
| TC-DAW-11 | Edge Case | File exceeding max upload size is rejected | Logged in as PM. Upload form is open. | 1. Attach a file larger than 50MB. 2. Click Upload. | Upload rejected. Error: “File exceeds maximum size of 50MB.” No deliverable record created. |
| TC-DAW-12 | Negative | Approval succeeds even if email service is temporarily unavailable | Email service returns 503. Deliverable in Pending Review state. | 1. Stub email service to return 503. 2. Client approves deliverable. 3. Check system behaviour. | Approval status updates to Approved. Email queued for retry. No error shown to client. |
| TC-DAW-13 | Positive | Audit log entry created on approval | Logged in as Client. Deliverable in Pending Review state. | 1. Client approves deliverable. 2. Query AuditLog table for this deliverable ID. | AuditLog contains: action=APPROVED, userId=client.id, timestamp within 1s of action. No missing fields. |
TC-DAW-12 is the one I would have been most likely to miss on my own. Testing that an approval succeeds even when the email service fails requires stubbing the email provider — it is an integration test, not a UI test. Without this, you discover the behaviour only when the email service has an actual outage in production.
The Reusable Test Review Checklist
Use this prompt to generate a review checklist for any feature. The output below is what Claude produced — copy it into your test plan template and run it against every feature before handing off to QA:
PROMPT — Generate Reusable Review Checklist
Generate a reusable test case review checklist.
Format it as a checkbox list grouped into six categories:
negative paths, boundaries, role-based access,
notifications, integration points, FRD coverage.
Each item should be a specific, binary check — not vague guidance.
Someone should be able to run through this list in under 5 minutes.REUSABLE TEST REVIEW CHECKLIST
[NEGATIVE PATHS]
[ ] At least 2 negative test cases per feature
[ ] Invalid input tested (missing fields, wrong format, wrong state)
[ ] Error messages verified (not just that failure occurs)
[BOUNDARIES]
[ ] Every FRD-specified limit has a test at the boundary
[ ] Empty state tested (no records, 0KB file, blank input)
[ ] Maximum value tested (max file size, max characters, etc.)
[ROLE-BASED ACCESS]
[ ] Each action tested from at least one permitted and one blocked role
[ ] Self-action restrictions enforced (e.g. cannot approve own upload)
[NOTIFICATIONS]
[ ] Every FRD notification trigger has a test confirming it fires
[ ] Notification failure tested — does core action still succeed?
[INTEGRATION]
[ ] External service failure tested (email, storage, payment)
[ ] Concurrent access tested where relevant
[FRD COVERAGE]
[ ] Every acceptance criterion maps to at least one test case
[ ] Every business rule maps to at least one test case
[ ] No duplicate tests (same preconditions + steps + assertion)What Is Next
The last post in this series is Post 10: AI-Powered Code Review with Claude. That is where Claude reviews actual code — checking correctness, security, performance, naming, and test coverage against a realistic Next.js API route. It is the final quality gate before you merge.
Next in this series: Post 10 — AI-Powered Code Review with Claude: What to Check and How to Prompt
One post left. If this series has been useful, sharing it is the best way to support it.