Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.
78
93%
Does it follow best practices?
Impact
77%
0.81xAverage score across 10 eval scenarios
Passed
No findings from the security scan
{
"context": "Predicted baseline failure: the SQL comment block is the tidiest enumeration in the fixture, so the agent builds the model out of it - eight status codes as eight situations, sometimes with is_locked promoted to a ninth, and expected results phrased as 'status_code becomes 40' or 'is_locked clears'. It looks rigorous and it maps cleanly onto the code, but it produces a pack the outsourced testers cannot execute a single case of, and it splits queued_for_underwriting from with_underwriter into two situations that no screen can tell apart, so half the resulting cases have unverifiable expected results. The seven labels the portal and console display are the situations that matter; the internal codes and flags are how the service happens to store them. The discriminating output models the seven, notes the two codes that collapse into one, and phrases every expectation as something visible on one of the two screens.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Deliverable exists",
"description": "A file docs/loan-lifecycle-tests.md exists and contains a model plus numbered manual cases with per-step expected results.",
"max_score": 5
},
{
"name": "The model is built on the seven visible situations",
"description": "The situations in the model are the seven labels the portal and console display - received, documents needed, in underwriting, approved, declined, funded, withdrawn. A model built on the eight status codes scores zero. A model that lists the seven labels but carries is_locked, doc_reminder_sent, or funding_batch_id as an additional situation caps at half.",
"max_score": 26
},
{
"name": "MUST NOT assert on database state",
"description": "MUST NOT. Any expected result naming a column, a status code number, a flag value, or a row - 'status_code becomes 31', 'is_locked is set', 'funding_batch_id populated' - scores zero on this criterion. The testers who run this pack have no database access, which the prompt states twice.",
"max_score": 18
},
{
"name": "The two indistinguishable codes are called out",
"description": "The document states that the queued and with-underwriter codes present as one situation on both screens, treats them as one in the model, and says what that costs the pack - the handover between them cannot be verified by this team. Treating them as two testable situations scores zero; noticing them but modelling them separately anyway caps at half.",
"max_score": 14
},
{
"name": "Events that must be refused after the money moves",
"description": "Cases exist for withdraw on a funded application (the write-off finance described), and for approve, decline, disburse and document upload arriving on applications that are already funded, declined or withdrawn. Each expects a refusal with the displayed label unchanged. The withdraw-after-funding case is required: omitting it caps this criterion at half. No refusal cases at all scores zero.",
"max_score": 20
},
{
"name": "All 42 situation/event combinations accounted for",
"description": "The model covers 7 situations against 6 events - 42 combinations - each either producing a result or explicitly marked as producing none. Thirty-six or more accounted for earns full marks; 26 to 35 caps at half; recording only the twelve or so that do something scores zero.",
"max_score": 14
},
{
"name": "Transitions that keep the same label are modelled",
"description": "Requesting documents again while already waiting for them (another reminder, label unchanged) is recorded as a transition with its own case, rather than dropped because the displayed label does not move.",
"max_score": 12
},
{
"name": "Each case is runnable from the two screens alone",
"description": "Preconditions describe how to put an application into the required situation using the portal and console only, and steps are actions available on those screens. Preconditions that require seeding a row or running SQL score at most half.",
"max_score": 10
}
]
}