← ClaudeAtlas

test-caseslisted

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.
akovalion/paranoid-qa · ★ 13 · Testing & QA · score 78
Install: claude install-skill akovalion/paranoid-qa
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 no