TestingOps.ai

Test management · Native connection

Qase and TestingOps: suites, cases, runs and defects

TestingOps reads the cases of a Qase project with their suites, preconditions and steps, sends AI-written and edited cases back into suites, records TestingOps runs as completed Qase runs and files defects.

  • Native connection
  • Available with limits
Request a demo Qase docs: Qase API and API tokens
Connection
Native connection
Writes back
Within what you allow
Last checked
7 Nov 2026

In short

Qase and TestingOps in short

The Qase connection uses a Qase API token and the code of a Qase project. TestingOps reads cases with title, preconditions, steps and suite path, for import or as knowledge that agents search.

It creates cases in suites built from your folder path, updates linked cases, records a finished run as a Qase run with a result per case and completes it, and creates Qase defects from TestingOps defects.

It works with Qase's cloud API; there is no field for a self-hosted Qase address.

What it does

What it does for your testing

  1. 1

    Cases keep their suites

    Input
    The cases of a Qase project
    TestingOps
    Reads up to 5,000 cases with preconditions and steps and turns each case's suite path into its folder
    Output
    Imported cases in folders that match the suites
  2. 2

    Cases go out into suites

    Input
    Selected TestingOps cases
    TestingOps
    Creates missing suites from the folder path and the cases with preconditions and steps; updates linked cases after keeping a copy
    Output
    Qase cases linked back to TestingOps
  3. 3

    A run becomes a completed Qase run

    Input
    A finished TestingOps run
    TestingOps
    Opens a run for the linked cases, adds a passed, failed or skipped result with comment and time per case and completes the run
    Output
    A completed run in the Qase project
  4. 4

    Defects go to Qase

    Input
    A TestingOps defect
    TestingOps
    Creates a Qase defect with the title and the defect's steps and results as the actual result
    Output
    The Qase defect reference on the TestingOps defect

Step by step

How it works

  1. ConnectUnder Integrations → Project tools → Test management, open Qase and paste a Qase API token.
  2. Read casesImport cases with Import from tool on Test Cases, or link the project, by its code, as a Test management source in Knowledge Base.
  3. Write casesPush to TM writes cases into suites; the import dialog can update Qase with the cases you edited, keeping a copy of each first.
  4. Report runs and defectsSend to TM on a finished run records the run; the TM button on a defect creates a Qase defect.

Connect

Setup

  1. In Qase, create an API token.
  2. In TestingOps, open Integrations → Project tools and, under Test management, select Qase; paste the token as API token, then select Test connection and Connect.
  3. Import cases with Import from tool on Test Cases, push cases with Push to TM and report runs with Send to TM, picking the Qase project code as the target.
  4. To file a defect, open it and select TM (Report to test management).

Documentation: Qase docs: Qase API and API tokens

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

Use cases

Use cases

Bring a Qase repository into AI-executed runs

Trigger
A team imports its Qase project into TestingOps
Uses
Cases with preconditions, steps and suite paths
Agent activity
Imports them into matching folders and marks duplicates
Result
Runnable cases organised like the Qase suites
Condition
Folder paths come from the first 100 suites of the project

Remove duplicates in Qase

Trigger
The import preview groups duplicate cases
Uses
The same title with the same or nearly the same steps
Agent activity
Remove duplicates from Qase deletes them after a second confirmation, keeping a copy of each
Result
A cleaner Qase project; deleted cases can be restored from Backups
Condition
For customer users, limited to the organization's administrators

Record a run with timings

Trigger
A run on RunningOps finishes
Uses
Results and durations of the linked cases
Agent activity
Send to TM opens, fills and completes a Qase run
Result
A completed Qase run with a result and time per case
Condition
Only cases linked to the connection are reported

File a defect where the team triages

Trigger
A tester confirms a defect found by a run
Uses
The defect's title, steps, expected and actual result
Agent activity
The TM button on the defect creates a Qase defect
Result
A Qase defect linked from TestingOps
Condition
Every defect is created with the same severity; set the real one in Qase

Capabilities

Capabilities and limits

What is read

  • Cases of a project, by project code: title, preconditions, steps (action and expected result), last update and suite
  • The suite tree, used for folder paths (the first 100 suites)
  • Up to 5,000 cases per read

What is produced

  • Imported TestingOps cases in suite folders, or knowledge-base entries
  • Copies of Qase cases kept before they change or are deleted

Where it can write

  • Cases with preconditions and steps in suites created from the folder path, and updates to linked cases
  • Deletion of duplicates you confirm
  • Runs with passed, failed or skipped results, comment and time; the run is completed afterwards
  • Defects with a title and the defect details as the actual result, at one fixed severity

How it connects

A Qase API token, used against Qase's cloud API

Account and permissions

TestingOps acts with the permissions of the token's user

Limits

  • Cloud API only: no self-hosted Qase address
  • Suite trees are read up to 100 suites; cases in further suites lose their folder path, and a push may create a second suite with the same name
  • Defects get a fixed severity
  • No live two-way sync; runs are reported when someone sends them

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team testing a mobile wallet keeps about 600 cases in a Qase project with the code WAL, organised in suites such as Onboarding and Transfers. It imports WAL into TestingOps, and each case lands in the folder of its suite.

The Transfers cases run on RunningOps, and Send to TM records the run in Qase, which shows it completed with a result and time for each case. A confirmed failure is filed as a Qase defect with the TM button.

Frequently asked questions

Does it work with a self-hosted Qase?

No. The connection uses Qase's cloud API address and the form has no base URL field.

Do Qase suites carry over to TestingOps?

Yes, for the first 100 suites of the project: a case's suite path becomes its folder on import, and on push the folder path becomes suites. In projects with more suites, some cases come without their folder path.

What does a reported run look like in Qase?

TestingOps opens a run for the linked cases, adds one result per case with status, comment and time, and then completes the run.

Which severity do Qase defects get?

Every defect is created with the same fixed severity, with the defect's steps and results as the actual result. Set the severity you need in Qase.

Can duplicates be deleted in Qase?

Yes, after a second confirmation. TestingOps keeps a copy of each deleted case, which you can restore from Backups in the import dialog.

Next step

Bring a Qase project to a demo and see its cases run and reported back.

Request a demoMore test management integrations