SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsqa-write-test-cases

qa-write-test-cases

Testing & quality

View repository

Updated 10-16 01:08

About this skill

Test Case & Checklist Generator

Generates test cases and checklists for software testing from the context the user provides.

References:

  • Test Case Format — markdown format for suites, tests, and steps (Testomat.io-friendly)
  • Writing Rules — rules for suites, tests, preconditions, steps, and AI writing patterns to avoid
  • Testomat.io TMS Guide — Testomat.io conventions and MCP tools

Prerequisites

  • Project structure checked (source code, e2e tests, test cases) via the /scan-automation-project skill.
  • Existing Testomat.io tests pulled via the /sync-test-cases-with-tms skill.
  • PLAN mode enabled, if available, for the interview steps.

User interaction

  • Always generate a checklist before test cases, even if the user asks for test cases directly.
  • Do not skip steps. Get user approval at each gate before moving to the next step.
  • Strictly recommend PLAN mode. Switch to Edit mode only on the last step — writing test cases to md files.
  • Use the Ask tool for choices when available.
  • Fill input fields with suggestions when asking the user for input.
  • Mark questions with ❓ and numbered options:
❓ Do you want to:

1. action 1
2. action 2
3. type something else

Workflow

  1. Gather context and show sources — approval gate
  2. Ask for coverage scope — approval gate
  3. Ask for role — approval gate; skipped for smoke
  4. Generate checklist — approval gate
  5. Generate detailed test cases
  6. Show summary

Step 1: Gather context

Understand:

  • the feature/functionality under test and its business goals
  • main testing flows and user journeys
  • specific areas of concern

Information sources:

  • User prompt
  • Task tracking systems (Jira, etc.)
  • Requirements documents (Confluence, etc.)
  • Design mockups (Figma, Miro, etc.)
  • Existing test cases (TestRail, Testomat.io, etc.)
  • Source code:
    • manual test files: .test.md or .md in folders like manual-tests, tests, manual, qa, spec
    • automated test files (spec, test, cy files, etc.)
    • project structure

Sources may come as pasted text, links, or MCP tools. Ask the user for MCP configuration if needed.

Analyzing source code:

  • Usually this skill runs from an automation project without application code. Check which case this is.
  • Automation-only project: scan briefly, focus on test files.
  • Application + automation project: scan the application code thoroughly; skip unit-test depth unless the user asks.

Testomat.io TMS detection

Detect if this is a Testomat.io project. Two options:

Option 1 — MCP. If the testomatio MCP is available, gather context:

  • suites_list, suites_search — existing structure
  • tests_search, tests_list — existing tests, avoid duplicates
  • steps_list, steps_search — reusable shared steps
  • tags_list, labels_list — project conventions

Option 2 — sync-test-cases-with-tms skill (with check-tests lib). Run it with the pull action, then analyze the downloaded files for:

  • existing structure and suites
  • current test cases (to avoid duplicates)
  • project conventions (tags, labels, priority levels)

If existing test cases intersect with the feature under test, report them to the user and suggest expanding them or creating a new suite.

Approval gate

Show the list of sources (names only, no content) and ask:

I've gathered information from the following sources:

- Jira issue ABC-123
- Confluence
- Figma

❓ Do you want to:

1. ➡️ Go to next step
2. ✏️ Type changes

Step 2: Ask for coverage scope

The scope sets the initial checklist size; the user can still fine-tune it in Step 4.

  • Compute approximate test counts per tier from your Step 1 analysis. Do not use generic or hardcoded ranges — the numbers must reflect the specific feature under test.
  • If you can't reasonably estimate (feature too vague, context too thin), say so and either omit the numbers or go back to Step 1.
  • If the user picks ✏️ Other, accept a number ("around 10") or a free-form description ("just the API contract, no UI") and size the checklist from it.

Show each option as a block: bold label with test count on the first line, description on the next. Replace <N> with your estimates:

❓ **How much coverage do you want?**

**1. 🚀 Smoke** ~<N> tests
Critical-path only

**2. ⚖️ Balanced** ~<N> tests
Happy path, key negative and common edge cases

**3. 🧨 Exhaustive** ~<N> tests
Full coverage incl. error states, boundaries, and security/perf/i18n where relevant

**4. ✏️ Other**
Proceed to specific role selection, type a number of tests, or describe scope in your own words

Step 3: Ask for role

  • If the user picked 🚀 Smoke in Step 2: skip this step — auto-apply ⚙️ default and go straight to Step 4. A smoke suite is too small to benefit from a specialized role.
  • Otherwise show the roles (markdown table with name and short description) and ask the user to pick one. Recommend a role based on context.
  • Use ⚙️ default if the user does not specify a role.
  • If the user selects 🔧 other, ask them to define a custom role.
  • If you show only some roles, add a "Show all available roles" option:
❓ Choose role:

1. default (or recommended role based on context)
2. ☰ Show all available roles
3. ✏️ Type role name

Roles

Role Description
⚙️ default balanced approach
🌈 optimist positive flows, happy path
🤓 nerd details, dependencies, perfectionist
🔪 psycho edge cases
🔐 pentest security
🎨 picasso ui/ux
⚖️ lawyer texts, error messages, typos, etc.
🌐 polyglot localization, translations
📈 performance performance, load, stress, etc.
🔧 other specify your own role

Step 4: Generate checklist

Create a hierarchical, categorized checklist from the gathered context.

Size it to the Step 2 tier:

  • 🚀 smoke — only critical paths
  • ⚖️ balanced — happy path, key negative, common edge cases
  • 🧨 exhaustive — full coverage
  • ✏️ other — follow what the user described

Example:

- Signup
  - Signup with valid email
  - Signup with valid phone number

- Login
  - Login with valid email
  - Login with valid phone number
  - Login with invalid password

Approval gate

  • If a multi-select/checkbox Ask tool is available: present leaf items as checkboxes, prefixed with their category (e.g. Login: valid email), with the recommended subset for the chosen tier pre-checked. The ticked items become the test cases in Step 5.
  • Otherwise: show the markdown checklist and ask the user to add/remove/change items.

Always ask about the amount of cases / level of detail:

❓ Do you want to:

1. 👍 Keep as is
2. ➖ Less details
3. ➕ More details
4. ✏️ Type anything you want to change
  • More details → enable the 🤓 nerd role.
  • User modifies the checklist → regenerate (Step 4).
  • User not satisfied → go back to Step 1 for more context.
  • Approved → Step 5.

Step 5: Generate detailed test cases

If the user originally asked only for a checklist, first ask: "Do you want to generate test cases for this checklist?"

Where to store test cases:

  • Empty or manual-tests-only workspace → project root
  • End-to-end testing project → manual-tests/ directory
  • Any other case → .testeiya/manual-tests/ (ensure .testeiya/ exists and is git-ignored)

Generation rules:

  • Name files feature-name.test.md (always the .test.md extension).
  • Multiple features or whole product → one file per feature.
  • Don't change the user's source code. Only generate *.test.md files.
  • Keep scope: test only the functionality under test; don't test linked features unless the user explicitly asks.

Format rules:

  • Strictly follow Test Case Format for suites, tests, and steps. Only exception: the user specifies their own format in the prompt.
  • Strictly follow Writing Rules for suite/test descriptions, preconditions, steps, expected results, and anti-patterns.
  • Follow the Testomat.io TMS Guide for conventions (priority levels, tags, labels), especially when using the testomatio MCP.
  • Wrap test cases in <!-- suite ... --> and <!-- test ... --> blocks.
  • If required, put tags: and labels: inside each <!-- test ... --> metadata block (see test metadata), not only on the suite block.
  • Reuse existing tags and labels obtained via MCP or from other test cases.
  • Do not use labels if you are not aware of any existing ones.
  • If reasonable, add test metadata (priority, preconditions, test data, labels, tags) based on the analyzed context.
  • Use concrete, executable values. Do NOT introduce ${...} placeholders in first-pass generation. Parametrize only genuinely reused or data-driven values; format them as ${variable} in backticks.
  • NEVER generate test or suite IDs of any kind:
    • Do NOT include Testomat.io IDs (id: @T*, id: @S*, e.g. @T12345678, @S380c64db).
    • Do NOT include custom/random IDs (e.g. TC-001, TC-R001, SUITE-01) in id: fields, titles, or anywhere else.
    • Testomat.io IDs are server-generated and assigned when the user runs check-tests push with --update-ids (or via the sync-test-cases-with-tms skill). Never add IDs at generation time.

Matching existing test case formats

When the user provides an existing test case example or asks for "similar" test cases:

DO match:

  • writing style and level of detail
  • field structure (Priority, Preconditions, Type, Test Data, etc.)
  • additional fields like labels and tags
  • original case language

DON'T copy:

  • any IDs from the example — neither Testomat.io IDs (@T..., @S...) nor custom prefixes (e.g. TC-R001, TC-001)
  • original test case intent

Step 6: Show summary

  • Show a concise summary (markdown table works well): number of test cases and suites, generated files, destination folder.
  • Ask the user to review the files and request changes if needed.
  • Suggest uploading the test cases to Testomat.io via the sync-test-cases-with-tms skill.