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": "Two predicted baseline failures, both of which read as careful work. First, the agent builds the grid, reaches the submitted row, and fills its four cells with 'not applicable - the controls are not rendered', producing no executable case for any of them. That is the reasoning that let all three support tickets happen: the button is gone, the route is not, and every ticket arrived through history, a bookmark or a stale tab. A cell with no behaviour still needs an attempt and an assertion that nothing moved. Second, the fixture says outright that post-timeout behaviour was never written down; the agent, wanting a complete grid, quietly invents an answer - usually 'returns to the first step with the draft intact' - and states it as expected behaviour, which turns an open question into a test case that will be graded against whatever the code happens to do. With 6 states and 4 events there are 24 combinations, 4 of which are the submitted row and 4 of which are the undefined one.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Deliverable exists",
"description": "A file docs/onboarding-wizard-tests.md exists and contains a model plus numbered manual cases with per-step expected results.",
"max_score": 5
},
{
"name": "The submitted application is attacked through routes the UI does not offer",
"description": "There are executable cases for next, back and save-and-exit applied to an already submitted application, and the steps say how the tester gets there - browser Back, typing or bookmarking the step URL, the app's swipe-back gesture, or a stale second tab. Each expects the application to remain submitted with no second application and no reference reused. All three covered with a stated route earns full marks; one or two caps at half; none scores zero.",
"max_score": 30
},
{
"name": "MUST NOT record 'the button is not shown' as the expected result",
"description": "MUST NOT. Any combination dismissed as not applicable, not reachable, or impossible because the control is not rendered scores zero on this criterion. The frontend note in the fixture states that hiding a control removes the button and not the route, and all three support tickets came in through the route.",
"max_score": 16
},
{
"name": "Undefined behaviour is raised as questions, not answered",
"description": "The combinations involving the expired state appear in the labelled list of things the spec does not settle, as specific questions - which step does an applicant land on after signing back in, does the draft survive, what does Back mean there. Inventing an expected result for them and presenting it as testable behaviour scores zero. Noting the gap vaguely without a question the BA could answer caps at half.",
"max_score": 20
},
{
"name": "All 24 state/event combinations accounted for",
"description": "The model covers 6 states against 4 events - 24 combinations - each either producing a result, marked as producing none, or marked as undefined by the spec. Twenty or more accounted for earns full marks; 15 to 19 caps at half.",
"max_score": 14
},
{
"name": "Back is exercised from every step that has one",
"description": "Cases cover Back from address, income and review, each expecting the preceding step with answers still populated, and Back on the identity step where there is nothing behind it, expecting the applicant to stay put. Covering only one Back caps this at half.",
"max_score": 12
},
{
"name": "Save and exit is modelled as a transition on every step",
"description": "Saving and exiting - which stores the draft and returns the applicant to the same step - is recorded as a transition per step rather than dropped because the step does not change.",
"max_score": 10
},
{
"name": "Expected results are observable to the applicant",
"description": "Expectations name the URL, the screen, the reference number, or whether compliance received a second application - things the tester can see - rather than internal wizard state.",
"max_score": 10
}
]
}