/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. — Objective: 1-2 lines, up to ~200 characters - what is checked and which defect it guards against ("Regression of PROJ-123"). For an automated case, a second line "Autotest: tests/…spec.ts". Defect history, why the data was chosen, browsers, the state "as of a date", what the autotest does not check - belong in the spec comment and the linked tickets, not in the objective. A decision recorded neither in the tracker nor in the code - one sentence. — 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. — Everything the tester copies goes into the step's Test Data (`testData`), ready to paste: • a GET request - as a full link that opens in the browser. GraphQL accepts GET too: `https://…/graphql?query=` + the query through encodeURIComponent. An unreadable encoded link gets a short link text ("GraphQL - fields of item 123"), the full URL lives only in href; • POST/PUT - `curl -i` on one line (without `-i` the status is not in the output, while the expected result requires it): full URL, the headers you need, the body (`-F` for multipart, `--form-string` for a JSON string inside a multipart field, `-H 'Content-Type: application/json' -d '…'` for JSON); a unique email via `$(date +%s)` right inside the curl; a chain of requests - through a shell variable in the same terminal; a boundary length - through `printf` (`'$(printf '%0101d' 0 | tr 0 A)'` gives 101 letters A), not a typed run of 101 characters: such a run comes out one off when copied, and the boundary stops being checked; • form field values - as "Field: value" lines separated by `<br />`; • a DevTools Console snippet - on one line, its output goes into the expected result. A heavy response or a check over a whole list - a snippet run on the opened link that prints the verdict itself: `fetch(location.href).then(r=>r.json()).then(d=>…)`.