Using qTest's Filterable Test Run History to Answer 'What Actually Passed?'

Every sprint review eventually hits the same question: which test runs actually passed for this release, and who executed them? If your answer involves exporting everything to a spreadsheet and eyeballing rows, you're doing work qTest already does for you. Its test run execution history supports filtering by status, assignee, and custom fields — and the same filtered view drives bulk updates and exports. This post walks through how to use that combination deliberately, and where it can trip you up.

The problem: execution history is only useful if you can slice it

A mature qTest project accumulates thousands of test runs across cycles, builds, and environments. The raw list is a firehose. What teams actually need are narrow, defensible slices: all failed runs assigned to a specific tester this week, or all unexecuted regression runs tagged for a given platform. qTest's filtering on test runs — by status, assignee, and your own custom fields — is the mechanism for producing those slices without leaving the tool.

The thesis here is simple: treat a saved, well-defined filter as the unit of work. Review it, bulk-act on it, export it. One filter, three uses.

Filtering by what matters: status, assignee, and custom fields

In the qTest web interface, open your project's Test Execution area and apply filters to the test run grid. The practically useful combination for agile traceability is:

• Status — e.g., Failed or Unexecuted, to isolate what needs attention rather than what's done.
• Assignee — to see one tester's execution stream, useful for workload balancing and for clarifying ownership during triage.
• Custom fields — this is where the real leverage is. If your team tags runs with fields like Environment, Browser, or Release Candidate, you can answer questions like "all failed runs on the staging environment for RC3" in one view.

The catch: custom fields only help if they're populated consistently. Agree on a small set of required fields at the test cycle level and enforce them when runs are created, not after the fact.

Worked example: triaging a failed regression slice

Suppose your nightly regression run against the staging environment produced failures, and you need a clean list for the morning stand-up plus a retest pass once fixes land.

1. In Test Execution, filter test runs to Status = Failed, your Environment custom field = staging, and the current test cycle.
2. Verify the result set visually: spot-check a few rows to confirm the status and environment values match the filter. Don't assume the filter applied the way you intended — especially with custom fields, where similarly named fields can exist.
3. Apply a bulk action: add a comment like "Triaged in stand-up 2026-10-14 — linked to defect DEF-1234" to the whole filtered subset, or reassign the runs to the tester who'll handle retests. Bulk status updates and comments apply to exactly the filtered set, which is why step 2 matters.
4. Export the filtered view as CSV for the stand-up notes, or as JSON if a downstream reporting script consumes it.

Expected result: the exported file contains only rows matching your filter criteria, with columns reflecting the fields in your grid view. If the CSV contains runs outside your filter, re-check the filter state before exporting — exports reflect the active view.

Web UI and API parity — with caveats

A genuinely useful property of this feature is that filtering behaves consistently between the qTest web interface and the REST API. A filter you prototype interactively can be reproduced programmatically for scheduled reports, which keeps manual triage and automated dashboards telling the same story. When building API queries, mirror the exact field names and values from the UI rather than guessing — custom field identifiers in particular are easier to confirm in the interface first.

Trade-offs and limitations

Two things can quietly break this workflow:

• Custom workflows and integrations. If your qTest instance uses custom workflow states or a third-party integration overrides default permission schemas, filter results may not match what you expect — some statuses may be renamed, or some runs may be invisible to certain roles. Confirm with your qTest admin which statuses and fields are canonical before building reports on them.
• Permissions on bulk operations. Bulk status updates and comments require a role with the appropriate permissions. Unauthorized attempts fail with a permission error and modify nothing — which is safe, but confusing if you expected a partial update. Check your project role before relying on bulk actions in a time-pressured triage.

Also note that filtering is a view over current state, not an audit snapshot. If someone re-executes a run after you export, your CSV is stale. For release sign-off, export at a defined cutoff and record the timestamp.

Actionable closing

Pick one recurring question your team answers manually today — "what failed on staging," "what's unexecuted for this sprint" — and encode it as a named filter with agreed custom fields. Verify it once by hand against the grid, then reuse it for review, bulk updates, and export. That small discipline turns qTest's execution history from a log you scroll through into a traceability tool you can defend in a sprint review.