jsdlc-test-case

# Test Case Specification (テスト仕様書) Request / arguments: $ARGUMENTS Mode is the first word: `create` (default), `review`, `modify`. Test phase is the second: `UT`, `IT`, or `ST`. Read before acting: - `docs-jsdlc/templates/test-case.md` - `docs-jsdlc/rules/review-checklist.md` §2 and §6 ## V-model binding — pick the right parent | Phase | Parent document | Proves | |---|---|---| | UT 単体テスト | Detail design | Each component behaves as internally designed | | IT 結合テスト | API spec + detail design interfaces | Components agree across boundaries | | ST 総合テスト | Basic design | The system does what was externally specified | Never trace a test case to a level other than its own. A UT case tracing to a basic design item is a level-skip defect (rule 3 of the traceability rule). --- ## Mode: create ### Step 1 — Read the parent and enumerate obligations Extract, mechanically, everything that must be tested: - every business rule in the design - every abnormal case and its error code - every boundary condition and its inclusivity - every state transition, both permitted and prohibited - every optional field's null / empty / zero behaviour This enumeration is the coverage obligation. Build it before writing any case; cases written first and mapped afterwards always leave gaps. ### Step 2 — Derive viewpoints (テスト観点) Group the obligations into viewpoints and classify each as 正常系, 異常系, or 境界値. Record the rationale — a reviewer asks why a viewpoint exists. ### Step 3 — Write the cases **正常系** — the designed path, including each significant variation (e.g. each branch of a conditional that still succeeds). **異常系** — one case per error code, minimum. Every code in the design must appear (T-05). Also test: prohibited state transitions, missing required fields, malformed input, and each external failure mode the design names. **境界値** — for every limit, three cases: just below, at, just above. State the position explicitly. Where the design declares an interval half-open (`[start, end)`), test that the touching case passes and the overlapping case fails — this pair catches the most common off-by-one in scheduling logic. Quality bars for every case: - **Precondition** — a concrete state, not "system is ready". Name the data. - **Operation** — concrete values, not "enter valid data". - **Expected result** — observable and specific. "Returns 409 with code E1004 and message naming the conflicting record" — not "returns an error". An expected result containing "correct" or "as designed" is NG (T-04). ### Step 4 — Build the coverage matrix §5, one row per design item. Any row with no case is a gap: leave it `No` and report it rather than quietly dropping it. Gaps are findings about the design or the test, and hiding them defeats the document's purpose. ### Step 5 — Self-check and save Run §6 checks. Confirm all three categories are non-empty, or that an empty one carries a written reason. Save to `docs-jsdlc/output/test-case/<UT|IT|ST>-<DOM>-<nnn>.md`. ### Step 6 — Report Case counts by category, coverage rate, uncovered design items, error codes not yet exercised, questions raised. --- ## Mode: review Do not edit. Run §2 and §6 checks with evidence. Highest-value checks: - **T-02 coverage** — rebuild the obligation list from the parent design yourself, then compare against the matrix. Do not trust the document's own matrix; it is the thing under review. - **T-05 error coverage** — list every error code in the design, then find its case. Missing ones are NG. - **T-06 boundary completeness** — for each limit, confirm all three positions. Two-of-three is the usual defect. - **T-04 expected-result specificity** — flag every vague expectation. - **T-01 category balance** — an 異常系 section far smaller than 正常系 usually means the abnormal paths were not enumerated from the design. If the implementation and its automated tests exist, cross-check: a documented case with no corresponding automated test is 要確認 (it may be manual); an automated test asserting behaviour absent from the design is NG. Write to `docs-jsdlc/output/review/<UT|IT|ST>-<DOM>-<nnn>-review-<YYYYMMDD>.md`. --- ## Mode: modify 1. Fix every NG: add missing cases, sharpen vague expected results, complete boundary triples, fill coverage gaps. Every NG you close carries the follow-through its class requires — see `docs-jsdlc/rules/review-checklist.md` §9. Closing the symptom without the follow-through leaves the defect class open, and the next review will find it again. A deferral counts as closed only with a `Q-NNN`, a named decider, and a due phase. 2. Promote 要確認 to `Q-NNN` — especially test data that depends on a business decision, and cases whose expected result the design does not settle. 3. When a gap traces back to a design defect rather than a test omission, say so and report it against the design document. Do not invent design intent to close a test gap — that is guessing, and it is NG. 4. Bump the revision history naming the findings addressed. 5. Report: cases added by category, coverage before and after, design defects discovered, questions promoted.