create-test-cases · git:20260807.4fb0cdd · 2026-08-07 · sha256 8b126f2230a2ccf0

create-test-cases git:20260807.4fb0cddA

Immutable. This exact content is served forever at /api/v1/blob/8b126f2230a2ccf0.

---
description: Create, update, organize, and link Katalon True Platform/TestOps manual test cases from a synced requirement key such as CEL-6, a read requirement, or free-text product behavior. Use when you need to analyze requirements, design manual test cases using ISTQB techniques as a reference, check existing Katalon coverage, avoid duplicate test cases, import only missing cases, update or link existing cases, or create/reuse a test suite for newly designed cases. For full requirement-to-execution workflows, combine with or defer to true-platform-testing. Written for the manual tester who has a written requirement in hand and no cases for it yet.
alwaysApply: false
---

# Katalon Create Test Cases

Use this skill for the test design and import portion of Katalon True Platform work. Keep the larger `true-platform-testing` skill available as the end-to-end orchestrator; this skill is only the focused create/update/link workflow.

## Availability Boundary

State the Katalon MCP boundary before promising writes:

- Available: list projects/repositories, find/read requirements, create/read/update/move test cases, find/manage folders, find/read/manage test suites, and link requirements to test cases.
- Not directly available: create requirements, create a formal Test Plan entity, inspect the live AUT UI, or guarantee downstream AI execution.
- Workaround for a test plan: create or reuse a named test suite/folder as the executable planning structure.

Read `references/capability-boundaries.md` when the user asks whether Katalon can do a specific operation.

## Resolve Context First

Before mutating Katalon data:

1. Call `list_projects`.
2. Call `list_repositories`.
3. Resolve the repository/Test Project from the user's wording, requirement key, or unique available repository.

Rules:

- Treat repository and Test Project as the same resolution target.
- If exactly one repository exists, use it.
- If multiple equally plausible repositories remain, ask the user to choose.
- If the user says "Katalon Cloud" or "cloud repo", prefer a repository named `Katalon Cloud` when present.
- Do not scan every repository just to avoid asking.

## Analyze Requirement

If the user provides a requirement key, use `find_requirements` or `read_requirement`. If the user provides free text, analyze it locally and only link requirements when a real requirement ID is known.

Output or internally track:

- Requirement intent
- Personas
- Main flows
- Alternate and negative flows
- Data and environment assumptions
- Risk areas
- Coverage recommendations

Read `references/requirement-analysis.md` before analyzing non-trivial requirements.

## Design Coverage

Design manual cases using ISTQB techniques as a reference for coverage (the techniques guide the design; the deliverable is plain platform test cases, not an ISTQB certification):

- Equivalence partitioning for input classes, statuses, roles, filters, and product states.
- Boundary value analysis for ranges, quantities, prices, dates, pagination, and text lengths.
- Decision tables for business rules with multiple conditions.
- State transitions for lifecycle flows such as cart, checkout, status, and execution.
- Use-case scenarios for realistic end-to-end user journeys.
- Error guessing for ecommerce, account, permissions, environment, and data risks.

### Make each case atomic

Each test case targets **one validation condition (one acceptance-criteria line)** — but it must still be a **complete, independently runnable flow**, not a single bare assertion.

- "Atomic" describes the *scope under test* (one rule per case), not the step count. Every case walks the real path to that condition: precondition/navigation -> enter the surrounding valid data -> perform the action under test -> verify the expected result. A case that is a lone step like "count the columns" is too thin; lead with the steps to reach and exercise that state so the case runs on its own (and so Run with AI can execute it).
- Split each input class, each required field, each boundary value, and each error message into its own case. Example: a password rule of "min 8 chars, has a letter, has a number, no spaces" becomes separate cases for too-short (7), exactly-8 valid, letters-only, numbers-only, and contains-space — each one a full fill-the-form-and-submit flow, differing only in the field under test.
- Cover both the happy-path flow and its edge cases. For every feature, include at least the main success flow plus the boundary and negative variants around it; do not stop at the positive path.
- Reserve genuinely combined multi-feature cases for true end-to-end scenarios (e.g. register -> log in -> land on dashboard), never as a container for unrelated checks.
- Why: a case mixing several *conditions* fails as a whole, so the result cannot tell you which rule broke and you lose 1 requirement-line -> 1 test-result traceability. Atomic-scope cases pinpoint the failing rule and map cleanly back to the requirement.
- Quote expected error and UI strings **verbatim** from the requirement, including any source typos. Flag suspected typos separately; never silently "correct" them in the expected result, or the test will assert behavior the app does not produce.

Read `references/istqb-coverage.md` before creating cases from requirements, and `references/manual-test-case-format.md` before importing several cases.

## Platform Constraints

- Test case **names** accept only letters, numbers, spaces, and `( ) . , _ -`. Avoid other symbols (such as `@`, `:`, `/`) in titles; keep them in descriptions or steps instead. Folder paths may use `/`.
- Prefer `update_test_case` over delete-and-recreate when adjusting an existing set. Deletion can fail server-side, and updating in place keeps IDs, links, and history intact.

## Check Existing Cases

This step is mandatory before every create/import attempt, including retries after partial failure:

1. If requirement IDs are known, call `find_test_cases_by_requirement`.
2. Search by requirement key, title keywords, feature area, and target folder with `find_test_cases`.
3. Read likely matches with `read_test_case` when the title alone is not enough to judge coverage.
4. Reuse, update, move, or link existing cases when they already cover the behavior.
5. Create new cases only for uncovered behavior, missing coverage classes, or clearly obsolete/incorrect cases.

Never create a duplicate just because a previous create call failed.

## Create Or Update Cases

Use Katalon tools in this order:

1. `create_test_case` only for uncovered manual cases.
2. `update_test_case` for revisions, passing all intended updates in one call.
3. `link_requirements_to_test_case` only after requirement IDs are known.
4. `read_test_case` after creation or update when verification matters.
5. `manage_test_folder` or `move_test_case` only when organization is requested or clearly needed.

Use this manual case shape:

- Title
- Description
- Pre-condition
- Steps
- Expected results
- Test data
- Priority
- Requirement links

## Test Suite Handling

When the user asks to create a test suite/test plan from the cases:

1. Search existing suites with `find_test_suites` before creating anything.
2. Read likely matching suites with `read_test_suite`.
3. Reuse the matching suite and add missing cases instead of creating a duplicate.
4. Create a new suite with `manage_test_suite` only when no suitable suite exists.
5. Verify the final suite with `read_test_suite`.

Report what was reused, updated, newly created, linked, and left uncovered.

---

## Bundled references

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

### references/capability-boundaries.md

# Katalon MCP Capability Boundaries

## Available

- Project discovery: `list_projects`.
- Repository/Test Project discovery: `list_repositories`.
- Requirement discovery: `find_requirements`, `read_requirement`.
- Requirement coverage: `fetch_requirement_data`.
- Test case operations: `create_test_case`, `read_test_case`, `update_test_case`, `duplicate_test_case`, `delete_test_case`, `move_test_case`, `find_test_cases`.
- Test folder operations: `find_test_folders`, `manage_test_folder`.
- Test suite operations: `find_test_suites`, `read_test_suite`, `manage_test_suite`.
- Requirement links: `link_requirements_to_test_case`, `unlink_requirements_from_test_case`, `find_test_cases_by_requirement`.
- Manual execution: `read_auts`, `create_manual_test_run`, `create_manual_ai_session`, `read_manual_ai_session`.
- Automated execution: `find_execution_profiles`, `list_test_cloud_environments`, `build_run_configuration`, `build_schedule`, `schedule_test_run`.
- Execution results: `read_execution`, `read_execution_test_results`, `read_test_result`, `find_test_results`.
- Quality data: requirement, defect, test case, test stability, and configuration coverage fetch tools.
- ALM defects: `find_alm_integration_projects`, `create_defect`.

## Not Directly Available

- Create requirements in Katalon True Platform. Requirements are synced from Jira/Azure and can be found/read/linked.
- Create a formal Test Plan entity. Use test suites/folders/executions as the executable planning structure.
- Guarantee Run with AI completion. The platform may block, fail, or require AUT/account state.
- Inspect AUT pages through Katalon MCP. Use Browser/Playwright for website exploration.
- Create defects without a failed test result ID and ALM integration details.

## Recommended Workarounds

- Requirement creation: create in Jira/Azure first, then sync/find/link in Katalon.
- Test plan: create a named folder and/or test suite, link to sprint/release, and create execution from that suite.
- AUT exploration: use Browser/Playwright to understand the product, then import manual cases into Katalon.
- AI execution blocked: report blocked state with required fixture, AUT, account, or environment action.

### references/istqb-coverage.md

# Coverage Guide (ISTQB techniques as reference)

Use this guide before writing or importing test cases. ISTQB is the **reference toolkit** for designing coverage here, not the deliverable: the output is plain platform test cases designed *using* these techniques, not "ISTQB cases" certified against the standard. The goal is enough risk-based coverage, not maximum case count.

## Technique Selection

- Equivalence Partitioning: use for valid/invalid classes such as product categories, brands, stock states, payment methods, account roles, and form input classes.
- Boundary Value Analysis: use for numeric or ordered values such as price range, quantity, pagination, character limits, dates, and timeout thresholds.
- Decision Table Testing: use when outcomes depend on combinations of conditions, such as selected variant + stock + quantity, checkout field validity, shipping eligibility, or payment availability.
- State Transition Testing: use when behavior depends on prior state, such as empty cart -> item added -> quantity updated -> removed, checkout step progression, or execution TODO -> IN_TESTING -> PASSED/FAILED.
- Use Case / Scenario Testing: use for end-to-end journeys that represent user goals, such as browse -> select variant -> add to cart -> checkout.
- Error Guessing / Checklist-Based Testing: use for likely failures based on domain knowledge, such as broken images, stale cart totals, invalid email, unavailable product, duplicate submission, or navigation loss.
- Pairwise / Combinatorial Testing: use when many variables interact, such as browser x device x category x filter x sort, while preserving explicitly high-risk combinations.

## Minimum Coverage Expectations

For each requirement, identify:

- At least one happy-path scenario.
- At least one negative or validation scenario when user input or branching exists.
- Boundary cases for numeric/date/range fields.
- State transitions for multi-step workflows.
- Role/permission coverage when roles exist.
- Data setup and cleanup assumptions.
- Requirement-to-test traceability.

## Coverage Output Format

Before importing tests, prepare a short coverage note:

```text
Coverage Techniques:
- Use case testing: ...
- Equivalence partitions: ...
- Boundary values: ...
- Decision table/state transition: ...
- Error guessing risks: ...

Selected Test Cases:
- P0: ...
- P1: ...
- P2: ...

Deferred / Not Covered:
- ...
Reason:
- ...
```

## Case Granularity

- Keep each case **atomic in scope**: one validation condition / one acceptance-criteria line per case, so a failure pinpoints the exact rule and each requirement line maps 1:1 to a result.
- Atomic does not mean a single step. Every case is a **complete, runnable flow**: precondition/navigation -> enter surrounding valid data -> perform the action under test -> verify the result. Avoid lone-step cases like "count the columns"; include the steps to reach and exercise that state so the case executes on its own (including under Run with AI).
- Cover the happy-path flow **and** its edge cases for every feature: main success flow plus boundary and negative variants. Do not stop at the positive path.
- Quote expected error/UI strings verbatim from the requirement, including source typos; flag suspected typos separately rather than correcting them in the expected result.

## Practical Rules

- Do not create redundant tests that exercise the same partition and same expected behavior.
- Prefer fewer strong tests over many shallow tests.
- Mark P0 for revenue, checkout, account, data-loss, or broken-entry-point risks.
- Mark P1 for important catalog, filter, sort, and traceability behaviors.
- Mark P2 for cosmetic, footer, secondary navigation, or low-risk edge cases.
- If a test is primarily exploratory or visual, say so and include what evidence is needed.

### references/manual-test-case-format.md

# Manual Test Case Format

Use this format when generating cases for Katalon True Platform.

## Fields

- Name: short verb-led title.
- Description: one or two sentences explaining the behavior under test.
- Pre-condition: environment, account, seed data, cart state, login state, AUT URL, and any browser/device assumptions.
- Test Steps: manual style actions. Start with navigation when page context matters.
- Expected Results: observable outcome for each step.
- Test Data: concrete values used by the step, or `N/A`.
- Priority: P0 critical path, P1 important functional path, P2 secondary/edge path.
- Requirement IDs: internal requirement IDs or source keys when linking is requested.

## Step Quality Rules

- Write one user action per step.
- Use visible labels and URLs, not implementation selectors.
- Put validations in Expected Results, not the action.
- Avoid "verify everything looks correct"; specify what must be visible or changed.
- Split long end-to-end flows when setup makes individual failures hard to diagnose.

## Katalon Import Notes

- Before creating test cases, search existing coverage with `find_test_cases_by_requirement` when requirement IDs are known and `find_test_cases` by title, requirement key, feature area, and folder.
- Reuse or update matching existing cases instead of creating duplicates.
- Create manual test cases with `create_test_case`.
- Link requirements after creation with `link_requirements_to_test_case`.
- Verify important created cases with `read_test_case`.
- Revise existing cases with one `update_test_case` call containing all updates.

## Example Shape

```text
Name: Add selected product variant to cart
Description: Verify that a shopper can select a product variant and add the selected quantity to cart.
Pre-condition: Storefront is available. Cart is empty.

### references/requirement-analysis.md

# Requirement Analysis Checklist

Use this checklist before writing tests from requirements.

## Inputs To Gather

- Requirement source: Jira key, Azure item, Katalon requirement ID, pasted text, or URL.
- Target AUT/environment.
- Persona or role.
- Business objective.
- Acceptance criteria.
- Known constraints, data, permissions, and dependencies.
- Sprint/release scope if test assets should be organized by iteration.

## Analysis Output

Produce:

- Requirement summary: what must be true for the feature to be accepted.
- Main flow: happy path from user intent to expected outcome.
- Alternate flows: optional paths, branching choices, pagination, sorting, filtering, retries.
- Negative flows: invalid data, missing data, permissions, empty states, out-of-stock or unavailable state.
- Data matrix: values needed for manual tests.
- Risk matrix: high-risk areas that deserve P0/P1 tests.
- Coverage map: requirement or story -> proposed test cases.

## Katalon Requirement Handling

- Use `find_requirements` to search synced Jira/Azure requirements.
- Use `read_requirement` for a specific requirement by source key or internal ID.
- Use `find_test_cases_by_requirement` to inspect existing coverage.
- Use `link_requirements_to_test_case` after test cases exist.
- Do not claim that the MCP can create requirements; current available tools only find/read/link synced requirements.