TCM Automation

Push results from your CI runner into a TCM test run using a Personal Access Token and one of the official SDKs.

What this is for

The TCM platform was built around manual testers — humans who log in, click through a test plan, and mark each case pass or fail. TCM Automation is the surface we expose for automated tests: a long-lived credential (a Personal Access Token), a typed SDK in your CI runner’s language, and a small REST API for everything in between.

Typical flow

1. A QA lead creates a Test Run in the TCM web UI from a test plan. The run gets a unique ID.
2. The lead shares the run ID with the automation team (e.g. as a CI variableTCM_RUN_ID).
3. A QA engineer mints a Personal Access Token under Account → API Tokens and stores it as TCM_TOKEN in CI secrets.
4. The CI job uses one of the SDKs to list the run’s executions, run each test, and recordResult() back into TCM. Optionally upload logs/screenshots via uploadAttachment().

Where to start

• Quick start — mint a token, install an SDK, push your first result.
• Authentication — how PATs work, how to revoke them.
• Runs & executions — the data model.
• REST API reference — the live OpenAPI spec.

External integrations (server-to-server)

If you’re building a system that needs to pull defect state on a schedule (a PMO dashboard, a Slack bot, an ETL into your data warehouse), you want the integration API instead — a separate auth flow and a stable read-only contract designed to outlive UI changes.

• Integrations — concepts — how identity mapping works, scopes, lifecycle.
• Integrations — REST reference — endpoint contracts + curl examples.