Pushing CI Test Results to qTest Manager via REST API: A Practical Guide

Useful answer

If you want manual and automated test results to share a single execution history in qTest Manager, configure your CI pipeline to submit automation logs through qTest’s REST API. This keeps trend reporting unified and avoids maintaining parallel trackers.

Mechanism: submitting automation logs via qTest REST API

Each qTest user can generate an API token from their profile page. The token inherits the user’s permissions and is used in the Authorization header as a Bearer token. Requests are sent to the tenant-specific base URL (for example https://{tenant}.qtestnet.com/api/v3) and must include the numeric projectId that scopes the call to a particular qTest project. Test cases marked for automation accept a POST to the /automation/executions endpoint carrying a JSON payload with the test’s outcome, timestamps, duration, and optional attachments. The API then attaches the result to the test case’s execution history, where it appears alongside manual runs.

Worked example

In a CI pipeline, a post-build step can parse JUnit XML output, convert each test case into a log object carrying testCaseName, automationId, status, startedOn, endedOn, durationInMs, and comment, then POST the batch to the qTest automation executions endpoint. For example, a curl command may send a JSON payload such as an array of objects with test case details. The API records the result on the mapped test case’s run and shows it in execution history.

Stable test-case mapping strategy

Relying on the test case’s display name is fragile because renames break the link and cause silent failures. Instead: add a custom field (e.g., Automation ID) to the test case schema in qTest Administrator; populate that field with a value that never changes for the corresponding automated test (fully qualified class+method, or a UUID stored in your test metadata); in the CI script, look up the test case by that custom field before submitting. If you need to resolve the ID dynamically, you can first call GET /api/v3/projects/{projectId}/test-cases?filter=automationId eq "{value}" to obtain the numeric test case ID, then include it in the payload. This approach ensures that a test case rename or moving to a different folder does not break the automation link.

Limits and common mistakes

• Project scoping – results are confined to the projectId used in the request. Multi-project setups require a separate configuration (or a loop) per project.
• Rate limits – qTest enforces per-token request limits (exact numbers vary by license; consult your API docs). Exceeding them yields HTTP 429 responses.
• Attachment size – each file attached to a test-log payload is typically limited to ~10 MB; larger logs or screenshots must be stored elsewhere and referenced by URL.
• Pagination – listing existing automation executions uses paginated endpoints (pageSize and pageStart parameters). Your reporting jobs should handle continuation tokens.
• Timezone – the API stores timestamps in UTC. If your CI runner uses a local timezone, convert to UTC before sending to avoid sorting surprises in the execution history view.

Common mistakes and how to avoid them: creating a new test run on every build fragments trend reports; mapping by display name silently fails after renames; swallowing HTTP errors so CI stays green while results never land; assuming Jira defect links are included in every license tier (they depend on the qTest Launch module); using a personal API token that inherits full permissions and may expire when the user leaves – create a dedicated service-account token with least privilege and rotate it periodically.

Verification steps

1. Open your tenant’s API documentation from the qTest Manager help menu and locate the POST /api/v3/projects/{projectId}/automation/executions endpoint; note the required JSON fields.
2. Generate an API token for a service account with limited permissions. Submit a single test log for a scratch test case using curl (as shown above) and confirm the result appears in that test case’s execution history.
3. Check your subscription or admin console to verify which qTest modules (Manager, Explorer, Launch, etc.) are licensed for your organization.
4. Introduce a deliberate failure in your CI step (e.g., change the status to Failed) and ensure the qTest result, attachment, and any Jira updates (if configured) appear as intended.