fix

2026-04-06 17:54:07 +03:00
parent 6d4e45d407
commit d00f858d98
15 changed files with 1319 additions and 0 deletions
@@ -0,0 +1,102 @@
+---
+name: testlink-decompose
+description: "Decompose a TestLink test case into autonomous mini-tests for AI processing and autotest generation. Use when: user provides a TestLink test case number or ID and wants to split it into independent end-to-end mini-tests. Triggers: 'decompose test', 'split test case', 'mini-tests', 'generate autotests from test case', 'TestLink test number', 'break down test', 'разбей тест', 'декомпозируй тест-кейс', 'мини-тесты из TestLink'."
+argument-hint: "TestLink test case ID — numeric (e.g. 99) or external (e.g. PRJ-5)"
+---
+
+# TestLink Test Case Decomposer
+
+Fetches a test case from TestLink via MCP and breaks it down into autonomous mini-tests,
+each ready for AI processing and automated test generation.
+
+## When to Use
+
+- User provides a TestLink test case number
+- A large test needs to be split into independent scenarios
+- Preparing a test case for autotest generation
+- Analyzing scenario coverage within a single test case
+
+## Procedure
+
+### Step 1 — Fetch the Test Case from TestLink (MCP)
+
+Call `mcp_testlink_get_test_case` to retrieve the full test case.
+
+Determine the correct parameter from what the user provided:
+- **Plain number** (e.g. `99`, `1234`) → pass as `test_case_id` (integer)
+- **PREFIX-NUMBER** (e.g. `PRJ-5`, `KMD-42`) → pass as `external_id` (string)
+
+If the user's input is ambiguous (no prefix, but looks like it could be external):
+1. First try `test_case_id`
+2. If not found, ask the user for the full external ID (e.g. `PRJ-99`)
+
+Fields to extract from the response:
+- `id` and `external_id` — identifiers (use `external_id` as the display ID in output)
+- `name` — test case title
+- `summary` — description / objective
+- `preconditions` — preconditions
+- `steps[]` — array of steps: `step_number`, `actions`, `expected_results`
+- `importance` — priority (1=Low, 2=Medium, 3=High)
+- `status` — design status
+
+If MCP returns an error or the test case is not found — report to the user and stop.
+
+### Step 2 — Analyze the Content
+
+Analyze the test case steps and identify logical groups using these criteria:
+
+1. **Change of tested function** — steps test a different feature, API, or screen
+2. **Change of scenario** — steps describe an independent user journey
+3. **Execution independence** — the group can run without the other steps
+
+Each logical group becomes one mini-test.
+
+Rules:
+- Setup/Teardown steps (data creation, login) → `preconditions` of the mini-test
+- If all steps are inseparable → one mini-test equals the original test case
+- Minimum number of mini-tests: 1
+
+### Step 3 — Decompose into Mini-Tests
+
+For each logical group, create a mini-test strictly following the format in
+[references/mini-test-format.md](./references/mini-test-format.md).
+
+Numbering and reference rules:
+- Mini-test ID: `{ORIGINAL_ID}-MT{N}` — e.g. `TC-1234-MT1`
+- `source_steps` — step numbers from the original that are included in this mini-test
+- Step numbering inside a mini-test starts from 1 (do not preserve original numbers)
+
+### Step 4 — Output the Structure
+
+Output in the following order:
+
+```
+# Decomposition of Test Case {ORIGINAL_ID}: {ORIGINAL_TITLE}
+
+> Original test split into {N} mini-test(s).
+> Priority: {High/Medium/Low} | Status: {status}
+> Original preconditions: {preconditions or "None"}
+
+---
+
+{mini-test 1 per format from references/mini-test-format.md}
+
+---
+
+{mini-test 2 per format from references/mini-test-format.md}
+
+---
+```
+
+### Step 5 — Summary Table
+
+After all mini-tests, append a summary table:
+
+| Mini-Test ID | Title | Original Steps | Ready for Autotest |
+|---|---|---|---|
+| TC-XXXX-MT1 | ... | 1–3 | ✅ |
+| TC-XXXX-MT2 | ... | 4–6 | ⚠️ Needs clarification |
+
+Readiness markers:
+- ✅ — steps are atomic, expected results are measurable
+- ⚠️ — ambiguous steps or vague expected results
@@ -0,0 +1,64 @@
+# Mini-Test Format
+
+Every mini-test must strictly follow this structure.
+
+## Template
+
+**ID:** `{original_id}-MT{N}`
+**Title:** {short title — what exactly is being tested}
+**Description:** {what this mini-test verifies, 1–3 sentences}
+**Priority:** {High / Medium / Low}
+**Preconditions:**
+- {system state required before execution}
+- {or "None" if no preconditions}
+
+**Steps:**
+
+| # | Action | Expected Result |
+|---|--------|-----------------|
+| 1 | {user or system action} | {expected behavior} |
+| 2 | {action} | {expected result} |
+
+**Final Expected Result:**
+{overall outcome after all steps of this mini-test complete}
+
+**Link to Original Test Case:**
+- Original test case: `{original_id}` — {original_title}
+- Original steps covered: `{e.g. 1–3, 5}`
+- Check type: `functional` | `boundary` | `negative` | `scenario`
+
+---
+
+## Field Rules
+
+### ID
+Format: `{ORIGINAL_ID}-MT{N}`, where N is a sequential number starting from 1.
+Examples: `TC-1234-MT1`, `TC-1234-MT2`.
+
+### Title
+- Must answer: "What is being tested?"
+- Format: verb + object. Example: "Login with valid credentials"
+
+### Description
+- 1–3 sentences about the goal of this mini-test
+- Do not repeat steps — describe the essence of the check
+
+### Preconditions
+- List the system, user, and data state required before execution
+- Include setup steps from the original that are not part of the verification logic
+
+### Steps
+- Each step = one atomic action
+- Action: specific ("Click the 'Login' button"), not abstract ("Log in")
+- Expected result: measurable ("A 'Welcome' message is displayed")
+
+### Check Type
+- `functional` — verification of core functionality
+- `boundary` — boundary/edge values
+- `negative` — invalid input or error scenarios
+- `scenario` — end-to-end user journey
+
+## Autotest Readiness Markers
+
+- ✅ `Ready` — all steps are atomic, expected results are unambiguous and measurable
+- ⚠️ `Needs clarification` — vague wording or dependency on external/dynamic data