Jenkins to qTest result mapping precedence for parallel build executions

Answer

qTest does not consolidate parallel Jenkins reports for the same test case identifier into a single run by default. The Jenkins to qTest integration plugin maps JUnit XML to a test case by identifier, e.g., test case ID or name, and pushes each completed execution as a separate Test Run entry within the target Test Cycle.

With that mapping, a PASS from one parallel agent and a FAIL from another concurrent agent for the same identifier will create two distinct run records. The record level is not overwritten with a last-build-wins mechanism. The cycle-level summary you see for the test case is derived from those runs, typically showing the most recent run by timestamp, or an aggregation rule configured in the qTest version you are using.

Confirmed facts

• Mapping is identifier based. qTest matches JUnit results to test cases using the configured identifier.
• Parallel executions reporting the same identifier within one Test Cycle generally result in multiple Test Run entries, not a single consolidated status.
• qTest maintains a history of runs per test case per cycle. It does not inherently overwrite a PASS with a FAIL at the record level.
• Parallel Jenkins agents act as independent reporters. The plugin pushes results as they complete, creating distinct execution entries in qTest.

Likely explanation and uncertainty

The overall status shown for a test case in a cycle is often presented as the most recent run, or via a configured aggregation logic. Exact behavior varies significantly between qTest Manager on-premise and qTest Pulse/Cloud, and across plugin versions.

A last-write-wins race can occur only if the integration is configured to update an existing run rather than create a new one. In that update mode, the final status depends on which agent writes last, which is nondeterministic under parallel execution.

Overlapping identifiers across agents can also lead to data duplication if a unique build/run identifier is not used to differentiate executions.

Steps to verify for this case

1. Open the target Test Cycle in qTest and open the specific test case.
2. Inspect the Test Runs tab and count entries for the same identifier from the same build window.
3. Compare timestamps of the reported results against the status shown on the Test Cycle dashboard.
4. Check the Jenkins to qTest plugin configuration for the job: whether it is set to create a new run per build or update an existing run, and which identifier is used for mapping.

One diagnostic detail that changes the recommendation: which qTest edition and integration plugin mode you are using — create new run per Jenkins build vs update existing run — and whether the same Test Cycle ID is shared across parallel stages.