TestingOps.ai

Test management · Native connection

TestRail and TestingOps: your TestRail inventory, AI test agents and run results

Keep TestRail as your system of record. TestingOps imports suites and sections with their steps, sends AI-written and edited cases back into sections and records TestingOps runs as TestRail runs.

  • Native connection
  • Available
Request a demo
Connection
Native connection
Writes back
Within what you allow
Last checked
7 Nov 2026

In short

TestRail and TestingOps in short

The TestRail connection uses your TestRail address, account email and API key. TestingOps reads projects, suites, sections and cases with their steps, and can import them as runnable TestingOps cases or keep them as knowledge that agents search.

In the other direction it pushes selected cases into sections that follow your folder tree, updates linked cases after keeping a copy of the TestRail version, and reports a finished run as a TestRail run with one result per linked case.

Each direction is an action you start or a schedule you choose. There is no live two-way sync and no field-level conflict resolution.

What it does

What it does for your testing

  1. 1

    A suite becomes runnable cases

    Input
    A TestRail project, a suite and, if you want, some of its sections
    TestingOps
    Previews up to 5,000 cases with steps, preconditions, priority and case type, can reformat them by your instruction and marks duplicates
    Output
    TestingOps cases in a folder tree that follows the sections, ready to run
  2. 2

    AI-written cases land in sections

    Input
    Cases selected in TestingOps
    TestingOps
    Creates the missing sections from each case's folder path and adds the case with preconditions and separated steps; linked cases are updated in place
    Output
    TestRail cases linked to their TestingOps counterparts
  3. 3

    A run becomes a TestRail run

    Input
    A finished TestingOps run
    TestingOps
    Creates a TestRail run for the linked cases and adds a result per case with status, failure message and elapsed time
    Output
    A TestRail run your team reviews as usual
  4. 4

    Duplicates leave the suite

    Input
    Cases the preview groups as duplicates: same title and the same or nearly the same steps
    TestingOps
    Deletes them in TestRail after a second confirmation, keeping a copy of each
    Output
    A smaller suite, with copies you can restore to TestRail

Step by step

How it works

  1. Connect TestRailUnder Integrations → Project tools → Test management, open TestRail and enter your TestRail address, account email and API key.
  2. Import or linkBring a suite into a project with Import from tool on Test Cases, or add the TestRail project or one of its suites as a Test management source in Knowledge Base, where up to 5,000 cases become knowledge agents search.
  3. Keep the import currentAn import can repeat every hour or every day. By default it adds new cases and leaves cases you already imported alone; Overwrite from the tool replaces them and keeps the earlier version in the case history.
  4. Send cases backSelect cases and use Push to TM, or let the import dialog update TestRail with the cases you edited. A copy of each TestRail case is kept before it changes.
  5. Report runsOn a finished run, Send to TM records it as a TestRail run for the cases linked to that connection.

Status mapping: passed becomes Passed, skipped becomes Blocked, failed and error become Failed. Results of cases that were never imported from or pushed to the same connection are left out.

Connect

Setup

  1. In TestingOps, open Integrations → Project tools and, under Test management, select TestRail.
  2. Enter your TestRail address as Base URL, your Email and an API key from TestRail, then select Test connection and Connect.
  3. To import, open Test Cases, select Import from tool, pick the connection, the Project in the tool, the Suite and, if you want, Sections (sub-suites), review the Preview and import the cases.
  4. To repeat the import, choose Every hour or Every day under Keep in sync and select Save schedule.
  5. To send cases, select them in Test Cases and use Push to TM; to report a run, open it and use Send to TM.
Where you connect it in TestingOps: Integrations → Project tools → Test management → TestRail

Use cases

Use cases

Start from years of TestRail cases

Trigger
A team links its regression suite to a new TestingOps project
Uses
Suites, sections, steps from the Steps or Text template, preconditions, priority and case type
Agent activity
Previews the cases, reformats them by the team's instruction without adding steps or dropping coverage, and marks duplicates
Result
Runnable cases in a folder tree that matches the sections
Condition
One preview reads up to 5,000 cases; for customer users, import is limited to their organization's administrators

Keep TestRail as the record of AI-written cases

Trigger
Agents write new cases for a feature folder
Uses
The selected cases with their folder path and steps
Agent activity
Push to TM creates the sections and adds the cases with separated steps
Result
New TestRail cases linked back to TestingOps, so a second push updates instead of duplicating
Condition
A case outside any folder is skipped, because TestRail needs a section

Report a regression run

Trigger
A run of the regression plan on RunningOps finishes
Uses
The results of the cases linked to the TestRail connection
Agent activity
Send to TM creates a TestRail run and adds one result per case
Result
A TestRail run with statuses, failure comments and elapsed times
Condition
A person starts the report; it is not sent when the run ends

Clean up a duplicated suite

Trigger
The import preview finds duplicates
Uses
Duplicate groups: the same title with the same or nearly the same steps
Agent activity
Remove duplicates from TestRail deletes them after a second confirmation and keeps a copy of each
Result
A cleaner suite; any deleted case can be restored from Backups
Condition
Deleting a case in TestRail is permanent there; the copy is kept in TestingOps

Capabilities

Capabilities and limits

What is read

  • Projects, suites and the section tree (shown as sub-suites)
  • Cases with steps from the Steps (separated) or Text template, preconditions, priority and case type
  • Up to 5,000 cases per import preview (500 unless you raise Read at most) and per knowledge source

What is produced

  • Imported TestingOps cases in a folder tree that follows the sections
  • Knowledge-base entries for agents to search while they write and review cases
  • Duplicate groups, and copies of TestRail cases kept before each change

Where it can write

  • New cases with preconditions and separated steps, in sections created from the folder path
  • Updates to linked cases: title, preconditions and steps
  • Deletion of duplicates you confirm, and restore of a kept copy
  • One TestRail run per report, with a result per linked case
  • Not written: defects, attachments and custom fields

How it connects

Your TestRail address (TestRail Cloud or your own server), account email and API key

Account and permissions

  • TestingOps acts with the permissions of the TestRail user whose API key you enter
  • For customer users, pushing cases and reporting runs need the integrations permission; import, write-back and duplicate removal are limited to the organization's administrators

Limits

  • No live two-way sync and no field-level conflict resolution
  • Run reports cover only cases linked to the same connection, and only when someone sends them
  • TestingOps skipped results appear as Blocked
  • A pushed case needs a folder; one push sends up to 500 cases

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team's booking-site regression suite in TestRail holds about 3,800 cases, many written with the Text template as a numbered list. The team imports the suite into a TestingOps project with the instruction to make every step atomic; the numbered text is split into steps, and the preview marks eleven duplicates, which the team removes from TestRail after confirming.

After the next regression run on RunningOps, a tester selects Send to TM. TestRail gets a run with one result per linked case, the failure message as the comment and the elapsed time.

Frequently asked questions

Is this a two-way sync with TestRail?

No. Each direction is a separate action: imports run when you ask or every hour or day, while pushes, write-backs and run reports run when someone starts them. There is no live sync and no field-level conflict resolution, and before TestingOps changes or deletes a TestRail case it keeps a copy you can restore.

Which TestRail step formats are supported?

Both templates. Steps (separated) are read as they are; in the Text template, numbered lines are split into steps and the expected result is matched to them, or placed on the last step when it is not numbered.

Can I import only part of a suite?

Yes. In a project with several suites you pick the suite, and you can tick sections; each ticked section brings its sub-sections. Leaving every section empty imports the whole suite.

What happens to cases I edited in TestingOps when the import runs again?

By default they are left alone and only new cases are added. With Overwrite from the tool they are replaced by the TestRail version, and the earlier TestingOps version stays in the case history.

How do run results appear in TestRail?

As a new TestRail run that includes only the linked cases. Passed results become Passed, skipped become Blocked, and failed or errored become Failed with the failure message as comment and the elapsed time.

Do cases have to be imported before results can be reported?

They have to be linked to the connection, which happens when a case is imported from it or pushed to it. Results of other cases are skipped and counted in the report.

Next step

Bring a TestRail suite to a demo and see it imported, run on RunningOps and reported back.

Request a demoMore test management integrations