Getting Automated Test Results into qTest: REST API, Automation Host, or Jira-Linked Workflows

The decision you're actually making

If your team runs automated tests in CI and manages test cases in Tricentis qTest Manager, the real question isn't whether to integrate them — it's who orchestrates execution and how results land in qTest. There are three supported patterns, and they differ mainly in where control lives, what infrastructure you maintain, and how much traceability you get for free.

The short version: most teams are best served by keeping CI as the execution engine and pushing results into qTest through the REST API. qTest Launch with Automation Host agents makes sense when you want qTest itself to schedule and trigger runs. Jira-linked workflows are about traceability, not execution, and usually complement one of the other two.

Comparing the three options

Trade-offs that matter in practice

REST API: maximum flexibility, you own the mapping

qTest Manager exposes a versioned REST API with per-user API tokens generated inside qTest. Any CI system can call it without installing agents, which keeps secrets, credentials, and pipeline logic where they already live. The catch: the API does not magically know which automated test corresponds to which qTest test case. You need a stable mapping — typically via the automation content field on test cases, or a disciplined naming convention — before result submission is trustworthy.

The usual flow is: create (or locate) test runs under a test suite and release, then POST test logs with a status per run. If your mapping is wrong, results land on the wrong runs and your coverage reports quietly become fiction. Treat the mapping as a first-class artifact, reviewed like code.

Automation Host: centralized control, real operational weight

qTest Launch plus Automation Host agents is the supported route when you want qTest to schedule and trigger automation itself. This centralizes execution control in the test management tool, which some QA-led organizations prefer. The trade-off is operational: you maintain always-on machines, keep agents registered and healthy, and confirm your license includes the Launch/Host modules — capabilities here have changed across releases, so verify before designing around it.

A common failure mode is duplicating pipeline logic: the team already has build, deploy, and environment setup in CI, then re-implements a weaker version inside qTest scheduling. If your CI already orchestrates environments well, agent-based execution rarely pays for itself.

Jira integration: traceability, not execution

qTest for Jira surfaces test coverage and defects in Jira when requirements live there. It solves the "can the product owner see coverage on this story?" problem. It does not submit automated results by itself — you still need the API or Automation Host underneath. Budget time for field mapping, defect-creation rules, and permission alignment between the two systems; behavior depends on both qTest and Jira versions and plugin configuration.

Recommended default architecture

For most engineering teams: CI orchestrates, qTest records, Jira (optionally) displays. That is, keep Jenkins/GitHub Actions/GitLab CI as the single place that builds, deploys, and runs tests, then push results to qTest via the REST API as a final pipeline stage. Add the Jira plugin if requirements traceability is a requirement.

Concrete validation you can run in an afternoon

Before committing, prove the round trip on your own instance. API endpoints, authentication details, and payload fields vary across qTest versions and SaaS vs on-premise deployments, so confirm against your instance's API documentation first. Then:

1. Generate an API token in your qTest instance (user profile settings) and confirm a simple authenticated call — listing projects — succeeds from a script on your CI runner.
2. Programmatically create a test run under a known release and test suite, and verify it appears in the qTest UI in the right location.
3. Submit two test logs against that run: one passing, one failing, the failing one with an attachment (e.g., a screenshot or log file).
4. In the qTest UI, confirm status, execution timestamp, and the attachment render correctly in the run's execution history.

If all four checks pass, the API path is viable for your instance. If you're evaluating Automation Host instead, install the agent on a spare machine and confirm it registers and heartbeats in qTest Launch before writing any scheduling configuration — an agent that won't stay connected invalidates the whole design.

Limitations to keep in mind

• Exact endpoint paths, token scopes, and supported payload fields differ by qTest version and deployment type. Do not code against examples from a different version without checking your instance's API docs.
• Launch and Automation Host capabilities have shifted across releases; confirm your licensed modules before committing to agent-based execution.
• Jira integration behavior depends on plugin configuration on both sides; test defect creation and field sync in a sandbox project first.

The decision is reversible at the edges — many teams start with API submission and add Jira traceability later — but switching orchestration ownership (CI vs qTest Launch) is a real migration. Validate the API round trip first; it is the lowest-commitment path and the one least likely to duplicate what your CI already does well.