/test-cases

name: test-cases
description: Test case authoring per QA best practices, with CSV export for Zephyr Scale import (Option 1) or direct creation via your TMS MCP. Use when the user asks to generate, write, or prepare test cases, checklists, or CSV for TMS import.
allowed-tools:
  — Read
  — Write
  — AskUserQuestion

Write test cases per the rules below. First prepare them in an md file for validation, then produce the CSV for import (or create directly via MCP, section 13).

Account for the requirements logic and existing mockups. On mismatch between mockup and implementation — log a question for the analyst.

0. Source completeness and honest limitations: — Before generating, collect ALL sources and track their status explicitly. In the final report include a source table: ticket / ticket attachments / linked issues / wiki (Confluence) / Figma node dump / visual review of ALL frames / Figma comments / implementation (if any) — for each: studied | not studied | what blocked it. "Not studied" with no reason and no workaround plan is an unacceptable report state. — Hit a tool limitation (truncated MCP response, unreachable file, crashed subagent)? Do NOT degrade silently: tell the user immediately and propose a workaround. Typical example: tracker MCP truncates ticket attachments by response size — the same files often live on linked wiki pages, where a tool that saves the file to disk in full can fetch them (for Confluence — `confluence_download_attachment`). — A subagent's self-report ("read everything, no gaps") is not evidence: spot-check the facts your expected results are built on (texts, field sets, labels, NUMBERS — sizes, spacing, gap) against the primary source (frame visual, file, live system). — Figma comments are not available via MCP (`get_figma_data` does not return them): BEFORE generating test cases, explicitly ask the user for the mockup comments (as text or screenshots) — they often carry corrections on top of the mockup (error texts, removed fields, final wording). Until you have them, that source stays open, and the report says so. — When the scope is defined by a spec document — tie every test case to a specific spec item (a "spec item" column in the coverage table). A check born only from the mockup or a heuristic does not become a test case — it goes to "Questions for the analyst" / "observations outside the spec". The mockup is a source of exact values for spec items, not a generator of new checks.

1. Test case format: — Name — short and clear (object: essence of the check, e.g. "Calendar opening", "List pagination"). No URLs, selectors, or technical details in the name (they belong in steps/objective). Do not put TC-(test case number) in the name. — Test case preconditions (if applicable) — Steps (maximally detailed, atomic) — Expected result (state it only after logically significant steps) — Priority (High / Normal / Low) — Type (UI / Functionality / Integration — or the values used in your project) — Reference (link or mockup name from Figma/PDF, specific element) — if applicable — Use the EXACT names of fields, buttons, headings, placeholders as in the implementation/mockups/spec — If the mockup labels a field "Issued by?" — write "Issued by?", not "Issued by (ID document)" — Check: colons, question marks, letter case, spaces in labels — If names differ between requirements and mockups - log it as a question for the analyst

2. Steps: — One action per step — Always spell out: • "Click the "Button name" button" • "Enter the value "…" in the "Field name" field" • "Select the value "…" from the "Name" dropdown" • "Hover over the "…" element" • "Open the page at URL …" — Avoid shorthand references: ❌ "similarly", "repeat the steps", "as in the previous test case", ❌ "select values per the test case name" Each step must read independently of other test cases.

3. Expected result: — By default — a separate Expected Result after significant steps, not one shared block at the end — State the result after steps where: • validation occurs • UI state changes • data is submitted • an error/message is displayed, etc. — Wording: • "The system displays…" • "The field is highlighted with an error…" • "The button becomes enabled/disabled…", etc. — Source of the expected result — requirements/spec, then mockups. The implementation/environment is NOT a source: take only exact element names from the implementation; the expected BEHAVIOR comes from requirements and mockups. If the implementation diverges from the requirements — that is a bug or a question for the analyst, not a basis for the expected result. — FORBIDDEN in test cases: wording like "capture on the first run", "clarify against the implementation", "verify with the implementation" — it turns testing into documenting whatever was built. An unknown text/behavior is a question for the analyst BEFORE the run (section 11); the expected result states the observable expected meaning. The only exception is taking a reference from a working PROD implementation of the same requirement (e.g. the same validation text on a live form), when the analyst has explicitly confirmed the requirement is unchanged.

4. Coverage: **Negatives are a required artifact, not optional.** Add a dedicated "Negative/Boundary" group; in the coverage assessment (section 12) list which negative classes are covered and which are consciously skipped (with a reason). A positive-only set is incomplete, even if the object looks simple/navigational. **A heuristic is not a requirement.** A check from the negative/overlay pack with no backing in the spec/mockup (popup closing, cursor, anti-spam and the like) is marked "heuristic" as it