| name | multica-test-design |
| description | Test design function: produce feature cases and API cases from the requirement / design / API contract, execute automation-first, and deliver a test report mapped item by item to the acceptance criteria. Used for feature cases / API test cases / test execution / test reports. |
Test Design
What this is
Test design is a function, not a role. It answers one question:
Have the acceptance criteria actually been verified? What is the evidence?
The key: testing shifts left — cases are prepared during the design / coding stage, not after the code is done. When implementation finishes, cases are ready and testing can run immediately.
Who executes it
- Production and execution: the Tester triggers this Skill — feature cases at the design stage, API cases at the contract stage, then execution and a test report after implementation.
- Gatekeeping: the test report is reviewed by the Leader at G3 (mapped item by item to the acceptance criteria); the Tester doesn't self-certify.
Process
- Feature cases (design stage; inputs: requirement + design):
- Cover every acceptance criterion (each criterion → at least one case)
- Add edge / exception / regression scenarios
- API test cases (coding stage; input: API contract):
- Positive / negative / boundary / auth / idempotency
- Each marked with: method, path, parameters, expected status code and response
- Execution (after implementation):
- Automation first: scriptable cases become automated tests (merged into the repo's test suite, runnable by CI)
- Only cases that can't be automated run manually, and manual cases must give reproducible steps
- Test report:
- Mapped item by item to the acceptance criteria: PASS / FAIL / BLOCKED
- A FAIL must provide: repro steps, expected behavior, actual behavior, evidence, severity
Result
PASS — every acceptance criterion met with sufficient evidence.
FAIL — at least one criterion unmet. Must provide: repro steps, expected behavior, actual behavior, evidence, severity.
BLOCKED — missing environment / data / dependency, cannot verify. Report honestly; never turn it into PASS.
Relationship to the verification skill
multica-verification: gatekeeping (the Leader reruns at gate points / checks the CI verdict)multica-test-design: produces cases + executes + reports (the Tester)
The test report is the input to the G3 gate; the automated versions of the cases are part of the CI hard gate. They complement each other: this Skill defines how cases are produced and run; the Leader defines the gate.
Why this works
Testing is easiest to treat as "homework after the fact": only think about how to test once the code is written, and "ran it" equals "tested it." The three rules — shift left, item-by-item mapping, automation first — turn testing from "proof after the fact" into "part of the design," and give the gate rerunnable machine evidence.
