---
name: katalon-trueplatform-testing
description: End-to-end testing on Katalon True Platform — take ANY testing task and route it through the right lane. Use when the user asks to analyze requirements, design manual test cases, import them into True Platform/TestOps, link requirements, organize suites, run tests manually with AI, schedule automated/TestCloud runs, run Playwright specs and ship results into True Platform, monitor executions, file defects, or report test outcomes. Also use to decide what is and isn't possible through the Katalon MCP.
---

# Katalon True Platform Testing

> **Give me any testing task. I figure out the lane, design the coverage, run it, and report it back with evidence.**

This skill turns a vague request ("test the checkout flow", "we shipped a new filter", "here's a Jira story, cover it") into a complete, traceable run on Katalon True Platform — manual, automated, or Playwright — without you having to know which Katalon tool does what.

**Golden rule:** Prefer **Katalon MCP tools** for anything that lives on the platform (projects, requirements, cases, suites, runs, results, defects). Use **Browser/Playwright** for touching the live AUT — exploring it, or *being* the automation. Never scrape the platform with a browser when an MCP tool exists.

---

## 0. The 30-second intake

Before doing anything, answer four questions. Most can be inferred from context — only ask when genuinely ambiguous.

| # | Question | If unknown → |
|---|----------|--------------|
| 1 | **What's the AUT?** (URL / app) | Look in the requirement, the chat, or `read_auts`. |
| 2 | **What changed / what's the intent?** | Read the requirement or ask for one line of scope. |
| 3 | **Which lane?** (see §1) | Default to **Lane A (Manual + Run with AI)** for new/unknown behavior. |
| 4 | **Where do results go?** | A True Platform project + repository (resolve via §2). |

Then state the **automation boundary** in one line (see §5) so expectations are honest, and go.

---

## 1. Lane routing — the one decision that matters

There are **three execution lanes**. Pick by *what already exists* and *who's driving*, not by preference.

```
                    ┌─────────────────────────────────────────────┐
   New behavior,    │  LANE A — Manual + Run with AI              │
   no code yet,  ─► │  Design cases → manual run → AI executes →   │
   exploratory      │  poll → report.   (Katalon MCP)             │
                    └─────────────────────────────────────────────┘
   Katalon-authored ┌─────────────────────────────────────────────┐
   automation       │  LANE B — Automated / TestCloud             │
   already in    ─► │  Find suites → run config → schedule_test_   │
   the repo         │  run → read results.   (Katalon MCP)        │
                    └─────────────────────────────────────────────┘
   Team lives in    ┌─────────────────────────────────────────────┐
   code, wants      │  LANE C — Playwright (code-first)           │
   cross-browser ─► │  Author/run .spec.ts → @katalon/playwright- │
   + CI gating      │  reporter uploads to True Platform Test Runs │
                    └─────────────────────────────────────────────┘
```

**Decision cheatsheet:**

| Signal in the request | Lane |
|---|---|
| "Here's a story / new feature / no automation yet", "explore", "cover this manually", "run with AI" | **A** |
| "Run the regression suite", "schedule on TestCloud", "we already have Katalon tests", mobile native/web on TestCloud | **B** |
| "We use Playwright", "cross-browser", "wire it into CI", `.spec.ts` files exist, "ship Playwright results into the platform" | **C** |
| "Just look at the page / poke around the live site first" | Browser/Playwright **exploration** (not a result lane) → then usually **A** |

You can combine lanes: explore with a browser → design in **A** → once stable, port the happy paths into **C** for CI. Say so when you do.

Read `references/test-lane-routing.md` for the full routing logic and tie-breakers.

---

## 2. Resolve context first (always, before any write)

```
list_projects  →  list_repositories  →  resolve the one repository/Test Project
```

- **Repository == Test Project.** Same resolution target.
- One project/repo matches the wording or current context → use it. Don't scan everything to avoid choosing.
- "Katalon Cloud" / "cloud repo" → prefer a repository literally named `Katalon Cloud`.
- Once project + repo + requirement scope are resolved, do **non-destructive writes** (create cases, link, build suites) without re-asking.
- **Before destructive or bulk-out-of-scope changes** (deletes, mass moves, anything beyond the request) → summarize and get approval.

> **Auth note:** this skill assumes a connected Katalon True Platform MCP server. If tools aren't available, run the server's `authenticate` flow first and tell the user to complete OAuth in the browser. Tool names below are the canonical bare names (`create_test_case`, …); your install may prefix them.

---

## 3. Requirement analysis → coverage (the thinking, before the typing)

1. **Get the requirement.** `find_requirements` / `read_requirement` for synced Jira/Azure items; analyze inline if pasted. *You cannot create requirements in Katalon* — they sync from the ALM.
2. **Produce a requirement analysis:** intent · personas/roles · main flow · alternate flows · negative flows · data & environment assumptions · risk areas · coverage recommendations.
3. **Design with ISTQB techniques** — enough *risk-based* coverage, not maximum case count:
   - **Equivalence partitioning** — input classes, roles, statuses, product states.
   - **Boundary value analysis** — quantities, prices, dates, pagination, length limits.
   - **Decision tables** — combinatorial business rules.
   - **State transitions** — cart/checkout/lifecycle, execution `TODO → IN_TESTING → PASSED/FAILED`.
   - **Scenario/use-case** — end-to-end journeys.
   - **Error guessing** — domain-known failure modes.
   - **Pairwise** — when variants explode; preserve high-risk combinations explicitly.
4. **Write a one-screen coverage note** (techniques used · selected P0/P1/P2 cases · deferred + risk rationale) *before* importing anything.

Read `references/manual-test-design.md` for the case format, step-quality rules, and the coverage-note template.

---

## 4. The three lanes, in detail

### Lane A — Manual + Run with AI  *(default for new behavior)*

```
draft cases → create_test_case → link_requirements_to_test_case → (group into suite)
   → read_auts → create_manual_test_run → create_manual_ai_session
   → read_manual_ai_session (poll) → report
```

Rules that bite if ignored:
- **Always `read_auts` immediately before `create_manual_test_run`.** Never reuse an AUT choice from an earlier turn.
- No AUT exists but a URL is known → pass it as `default_aut_environment_url`.
- After any manual run is created, **start Run with AI automatically** — don't ask again — unless the user explicitly said "manual only, no AI".
- Before `create_manual_ai_session`, call `read_test_suite` for each suite and pass **non-empty** case lists.
- **Poll** `read_manual_ai_session` until every item leaves `TODO`/`IN_TESTING`. If it stays queued a long time, keep polling at sane intervals; only report "in progress" if asked or the platform errors/times out.

### Lane B — Automated / TestCloud  *(existing Katalon automation)*

```
find_test_suites (automated) → find_execution_profiles → list_test_cloud_environments
   → build_run_configuration → (build_schedule) → schedule_test_run → read_execution*
```

- Use `schedule_test_run` **only** for automated suites. Never push a single manual case through it.
- Mobile: confirm **mobile browser vs native app**; native needs app details.

### Lane C — Playwright (code-first → into True Platform)

The integration is the npm package **`@katalon/playwright-reporter`**: your real Playwright specs run anywhere (local / CI), and results — status, duration, screenshots, videos, traces, browser metadata, errors — upload into True Platform **Test Runs**, filterable by Testing Framework.

Minimum path:
```bash
npm install --save-dev @katalon/playwright-reporter
# playwright.config.ts: add getGlobalSetupPath() + the reporter with platform creds
KATALON_API_KEY=… KATALON_PROJECT_ID=… npx playwright test     # auto-upload during run
# OR decouple run from upload:
playwright-reporter upload --output ./reports --api-key … --project-id …
```

Use Lane C when the team owns code, wants Chromium/Firefox/WebKit coverage, and needs CI to gate merges. Read `references/playwright-integration.md` for full config, env vars, CI snippets, and the "design in A, harden in C" promotion pattern.

---

## 5. Capability boundaries — say this out loud, up front

**Available via Katalon MCP:** discover projects/repos · find/read requirements · create/read/update/move/duplicate/delete cases · link requirements · manage folders & suites · manual runs + Run with AI · automated/TestCloud scheduling · executions & results · quality metrics · ALM-linked defects.

**Not directly available — and the workaround:**

| Want | Reality | Do instead |
|---|---|---|
| Create a requirement | Synced from Jira/Azure only | Create in ALM → sync → find/link |
| Create a formal Test Plan entity | No direct tool | Named suite/folder + sprint/release association |
| Guarantee Run-with-AI finishes | Can block on AUT/account/env | Report the **blocked** state + the exact fixture/account/env fix needed |
| Inspect the live AUT UI | Not via Katalon MCP | Browser/Playwright |
| Create a defect with no failed result | Needs a failed test-result ID + ALM project | `find_alm_integration_projects` first; only file on real failures |

Read `references/katalon-mcp-tools.md` for the complete tool map and boundaries.

---

## 6. Results, defects, reporting

After execution, **read before you report:**
- Lane A: `read_manual_ai_session` (+ execution/result tools if IDs returned).
- Lane B: `read_execution` → `read_execution_test_results` → `read_test_result`.
- Lane C: results land in **Test Runs**; surface the run link + framework filter.
- Quality rollups: `fetch_requirement_data` · `fetch_test_case_data` · `fetch_defect_data` · `fetch_test_stability_data` · `fetch_test_configuration_data`.

**Report format** (every run):
```
Run:  name · link · status
Summary:  passed / failed / blocked-incomplete / not-run
Findings:  failed case → concise reason (with screenshot/trace/error as evidence)
Defects:  created or recommended
Next:  gaps, skipped items, what needs manual follow-up
```

**Evidence discipline:** a failure claim carries its proof — the verbatim error line, a screenshot, or a trace. No "looks broken" without the artifact. If you can't produce the evidence, downgrade the claim.

**Defects:** `create_defect` only on a known failed test-result ID. Run `find_alm_integration_projects` first if integration IDs are unknown. Ask before filing unless the user asked for auto-filing on failure.

Read `references/execution-and-reporting.md` for the per-lane execution rules and the reporting template.

---

## 7. Autonomy policy

For an end-to-end request, run the whole available flow without pausing on *optional* decisions:

```
Analyze → Create/link cases → Build suite → Create run → Execute (A/B/C) → Report
```

**Ask only when:** a required value can't be resolved safely · multiple equally-valid choices remain · credentials/accounts are missing · the next action is destructive · or the user explicitly wants approval gates.

Otherwise: pick the best match, **say what you assumed**, and keep moving.