test-management git:20260807.4fb0cddA

Immutable. This exact content is served forever at /api/v1/blob/89385bf53be8b351.

---
description: Organize, classify, and trace Katalon True Platform/TestOps test assets. Use when you need to structure test cases into folders and suites, move or reorganize cases, search and find existing assets at scale, link or unlink requirements to test cases, or produce a requirement-to-test traceability report (which requirements have coverage, which cases are orphaned, coverage percentage). Prefer this skill for inventory hygiene and traceability audits. For authoring new cases use create-test-cases; for coverage quality verdicts use test-review. Written for the test lead doing inventory hygiene on a repository nobody has curated in months.
alwaysApply: false
---

<!-- GENERATED by scripts/build-adapters.mjs from skills/. Do not edit by hand. -->

# Katalon Test Management

Use this skill for the **management** stage: keep the test inventory organized, findable, and fully traceable to requirements. Traceability is the platform's differentiator, so the headline output is a **requirement <-> test case <-> suite** map, not just folder tidying.

## Availability Boundary

- **Available via MCP:** folders (`find_test_folders`, `manage_test_folder`), suites (`find_test_suites`, `manage_test_suite`, `read_test_suite`), case organization (`move_test_case`, `duplicate_test_case`, `delete_test_case`), search (`find_test_cases`), and requirement links (`link_requirements_to_test_case`, `unlink_requirements_from_test_case`, `find_test_cases_by_requirement`, `fetch_requirement_data`).
- **Not directly available:** custom fields and tags authoring, dynamic test suites, Git repository configuration, script-repo upload, and project governance/notifications — these are TestOps-UI or Studio operations. Name them as boundaries; do not claim MCP writes for them.
- **Naming charset:** test case names allow only letters, numbers, spaces and `( ) . , _ -`. Folder paths allow `/`. Prefer `update`/`move` over delete-and-recreate (`delete_test_case` has been unreliable).

## Traceability Workflow

```text
+---------------------+     +-----------------------+     +----------------------+
| Read requirements   | --> | Map cases <-> reqs    | --> | Find orphans + gaps  |
+---------------------+     +-----------------------+     +----------------------+
        |                             |                              |
        v                             v                              v
+---------------------+     +-----------------------+     +----------------------+
| Link/unlink to fix  | --> | Organize into suites  | --> | Report traceability  |
+---------------------+     +-----------------------+     +----------------------+
```

## Steps and tool rules

1. **Establish scope.** `list_projects` -> `list_repositories`. Resolve one target from context.
2. **Build the trace map.** For each requirement key, `find_test_cases_by_requirement`; use `fetch_requirement_data` for coverage status. Classify each requirement as: covered, partially covered, or orphan (no case).
3. **Find loose assets.** `find_test_cases` by feature/folder/keyword to surface cases with no requirement link (orphan cases) and duplicates.
4. **Fix links (only when known and requested).** `link_requirements_to_test_case` after requirement IDs are confirmed; `unlink_requirements_from_test_case` for wrong links. Never guess a link.
5. **Organize inventory.** `manage_test_folder` and `move_test_case` for structure; `manage_test_suite` to group runnable cases. Reuse before creating; summarize bulk moves and get approval before executing them.
6. **Report the traceability matrix.** requirement -> case(s) -> suite(s), coverage %, orphan requirements, orphan cases, and duplicate candidates. This is the deliverable.

## Prompt recipes

- `Audit requirement-to-test traceability for project X and list every requirement with no test case.`
- `Reorganize the smoke suite: move all P0 login cases into Test Cases/Auth/Smoke and report the new structure.`
- `Link test cases TC-1042 and TC-1043 to requirement CEL-6 and confirm the coverage.`
- `Find duplicate test cases in the Checkout folder and propose which to keep.`

## Hand-offs

- Coverage gaps found -> `create-test-cases` (author) or `test-plan` (schedule).
- Quality verdict on the organized suite -> `test-review`.

Read `references/traceability.md` before running an audit. Consult the orchestrator's `references/unavailable-capabilities.md` for the full boundary list.

---

## Bundled references

_The reference material the skill points to is inlined below so this file is self-contained._


### references/traceability.md

# Traceability reference

## The trace map (the deliverable)

```text
Requirement  ->  Test case(s)   ->  Suite(s)      Coverage
CEL-6            TC-1042, TC-1043   Auth/Smoke     covered
CEL-7            TC-1050            (none)         covered, not in a suite
CEL-8            (none)             (none)         ORPHAN requirement
—                TC-1099            (none)         ORPHAN case (no requirement link)
```

Coverage % = requirements with >=1 linked case / total in-scope requirements.

## Tool sequence for an audit

1. `find_requirements` (or the supplied keys) — the in-scope requirement set.
2. `find_test_cases_by_requirement` per key — the linked cases.
3. `fetch_requirement_data` — platform coverage status to reconcile against the link map.
4. `find_test_cases` by folder/feature — surface cases that never appear in step 2 (orphan cases).
5. Diff: requirements with no case = orphan requirements; cases with no requirement = orphan cases.

## Classification rules

- **Covered:** requirement has >=1 linked, current test case.
- **Partially covered:** linked cases exist but leave known behavior untested (defer the judgment to `test-review`).
- **Orphan requirement:** no linked case — the top gap; route to planning/design.
- **Orphan case:** case with no requirement link — either link it (if a requirement is known) or flag for review; do not delete without approval.

## Safe-mutation rules

- Prefer `update_test_case` / `move_test_case` over `delete_test_case` (delete has been unreliable, HTTP 500 observed).
- Test case name charset: letters, numbers, spaces, `( ) . , _ -` only. No `@ : /` in titles.
- Summarize any bulk move/link/delete and get approval before executing.
- Never fabricate a requirement<->case link; link only confirmed IDs.