Test management · Native connection

qTest and TestingOps: cases into modules, runs into test cycles

TestingOps sends AI-written and edited cases with their steps into qTest modules that follow your folders, and records TestingOps runs as qTest test cycles with a test run and a test log per case.

Native connection
Available with limits

Request a demo Tricentis: Download qTest Resources (API token)

qTest ContextResults TestingOpsAI test agents

Connection: Native connection
Writes back: Within what you allow
Last checked: 7 Nov 2026

In short

qTest and TestingOps in short

The qTest connection uses your qTest address and a bearer token. TestingOps creates test cases with precondition and steps in modules built from the folder path, updates linked cases and deletes duplicates you confirm, keeping a copy first.

A finished run becomes a test cycle with one test run and one test log per linked case; the passed and failed status IDs are looked up by name in your project.

Reading is weaker: the bulk case list does not ask for steps or module paths, so imported cases may arrive without them. There is no defect filing to qTest.

What it does

What it does for your testing

1
Cases land in modules
Input
Selected TestingOps cases
TestingOps
Creates missing modules from the folder path, then the test cases with precondition and steps; linked cases are updated after a copy is kept
Output
qTest test cases linked to TestingOps
2
A run becomes a test cycle
Input
A finished TestingOps run
TestingOps
Creates a test cycle, a test run per linked case and a test log with passed or failed status and the failure note
Output
A test cycle your team reviews in qTest
3
Existing cases as a starting point
Input
Test cases of a qTest project
TestingOps
Reads names and whatever steps the bulk list returns
Output
Imported cases, marked when steps are missing

Step by step

How it works

ConnectUnder Integrations → Project tools → Test management, open qTest and enter your qTest address and a bearer token.
Push casesSelect cases in Test Cases and use Push to TM, picking the qTest project.
Report runsSend to TM on a finished run creates the test cycle with its test runs and logs.
Bring existing cases inUse Import from tool on Test Cases, or paste a CSV export under Import existing test cases in Knowledge Base when you need the steps.

Anything that did not pass, skipped results included, is logged as failed in qTest.

Connect

Setup

In qTest, copy your bearer token from Download qTest Resources (API & SDK).
In TestingOps, open Integrations → Project tools and, under Test management, select qTest; enter your qTest address as Base URL and the token as Bearer token, then select Test connection and Connect.
Push cases with Push to TM and report runs with Send to TM, picking the qTest project as the target.

Documentation: Tricentis: Download qTest Resources (API token)

Where you connect it in TestingOps: Integrations → Project tools → Test management → qTest

Use cases

Keep qTest as the record of AI-written cases

Trigger: Agents write cases for a feature folder such as Loyalty/Rewards
Uses: The cases with precondition, steps and folder path
Agent activity: Push to TM creates the Loyalty and Rewards modules and the test cases
Result: New qTest test cases linked back to TestingOps
Condition: A later push updates the linked cases instead of creating new ones

Record a regression run in qTest

Trigger: A regression run on RunningOps finishes
Uses: Results and failure messages of the linked cases
Agent activity: Send to TM creates a test cycle, test runs and test logs
Result: A test cycle with passed and failed logs
Condition: Skipped results are logged as failed

Bring qTest cases in with their steps

Trigger: A team wants its existing qTest cases in TestingOps
Uses: A CSV export of the cases
Agent activity: Import existing test cases maps title, steps, expected result and priority columns and checks every row against the inventory
Result: Cases created, duplicates skipped, rows needing review listed
Condition: Import from tool may bring cases without steps

Capabilities

Capabilities and limits

What is read

Test cases of a project, by project ID: name and the steps the bulk list returns; no module path
Single cases with their steps, read before TestingOps updates or deletes them, for the kept copy
Up to 5,000 cases per read

What is produced

Imported TestingOps cases or knowledge-base entries
Copies of qTest cases kept before they change or are deleted

Where it can write

Test cases with precondition and steps under modules created from the folder path, and updates to linked cases
Deletion of duplicates you confirm
Test cycles with a test run and test log per linked case
Not written: defects

How it connects

Your qTest address (for example https://<company>.qtestnet.com) and a bearer token

Account and permissions

TestingOps acts with the permissions of the token's user

Limits

The bulk read does not request steps or module paths, so imports may lack both
Skipped results are logged as failed
No defect filing
Run statuses need a passed (or pass) and a failed (or fail) status in the project's test run settings

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team keeps its regression cases in qTest and runs them by hand every release. Agents write 25 cases for a new loyalty feature in the folder Loyalty/Rewards; Push to TM creates the Loyalty and Rewards modules and the cases with their steps.

After the run on RunningOps, Send to TM creates a test cycle with 25 test runs and logs: 23 passed and 2 failed with their failure notes.

Frequently asked questions

Why do imported qTest cases have no steps?

The bulk list TestingOps reads does not ask qTest to include steps, so cases may arrive with their names only; the preview marks them. To bring the steps in, export the cases to CSV and paste them under Import existing test cases in Knowledge Base.

How are skipped results recorded?

As failed. qTest receives the passed status for passed cases and the failed status for everything else, using the status names configured in the project.

Can TestingOps file defects in qTest?

No. File defects through an issue tracker connection such as Jira, with Report to… on the defect.

Where do pushed cases go?

Into modules that follow the case's folder path; missing modules are created. Cases that were pushed before are updated in place, after TestingOps keeps a copy of the qTest version.

Can duplicates be deleted in qTest?

Yes, after a second confirmation. A copy of each case is kept first and can be restored from Backups.

Next step

Bring a qTest project to a demo and see a TestingOps run recorded as a test cycle.

Request a demo More test management integrations