Test management · Native connection

Azure Test Plans and TestingOps: test cases, suites and test runs

TestingOps reads Test Case work items from an Azure DevOps project, creates AI-written cases in a test plan with suites that follow your folders, records TestingOps runs as Azure test runs and files defects as Bug work items.

Native connection
Available with limits

Request a demo Microsoft Learn: use personal access tokens

Azure Test Plans ContextResults TestingOpsAI test agents

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

In short

Azure Test Plans and TestingOps in short

The Azure Test Plans connection uses your organization URL and a personal access token. It reads the 200 most recently changed Test Case work items of a project, with their steps, for import or as knowledge that agents search.

It creates cases as Test Case work items with steps, adds them to static suites built from the folder path, updates linked cases, records a finished run as an Azure test run and creates Bug work items from TestingOps defects.

The push dialog has no plan picker: on the first push TestingOps creates a test plan for its cases in the project and reuses it afterwards.

What it does

What it does for your testing

1
Test Case work items come in
Input
Test Case work items of an Azure DevOps project
TestingOps
Reads the 200 most recently changed with title, state and steps
Output
Imported cases or knowledge entries, without suite folders
2
Cases land in a suite tree
Input
Selected TestingOps cases
TestingOps
Creates Test Case work items with steps and adds them to static suites built from the folder path
Output
Cases in suites under the test plan TestingOps uses, linked back to TestingOps
3
A run becomes a test run
Input
A finished TestingOps run
TestingOps
Creates a test run with a result per linked case: Passed, Failed or NotExecuted, duration and comment, then completes it
Output
A completed test run in the project
4
A defect becomes a Bug
Input
A TestingOps defect
TestingOps
Creates a Bug work item with the defect title and its steps, expected and actual result as repro steps
Output
The Bug's link stored on the defect

Step by step

How it works

ConnectUnder Integrations → Project tools → Test management, open Azure Test Plans and enter your organization URL and a personal access token.
Read casesImport cases with Import from tool on Test Cases, or link the project as a Test management source in Knowledge Base. Reads stop at the 200 most recently changed cases.
Push casesPush to TM writes cases into suites of the test plan TestingOps uses in the project you pick, and updates linked cases after keeping a copy.
Report runs and defectsSend to TM on a finished run records a test run; the TM button on a defect creates a Bug work item.

Duplicates the import preview finds can be deleted with Remove duplicates from Azure Test Plans; TestingOps keeps a copy of each case first.

Connect

Setup

In Azure DevOps, create a personal access token whose scopes cover work items and test management.
In TestingOps, open Integrations → Project tools and, under Test management, select Azure Test Plans; enter https://dev.azure.com/<organization> as Base URL and the token, then select Test connection and Connect.
Import cases with Import from tool on Test Cases, push cases with Push to TM and report runs with Send to TM, picking the Azure DevOps project as the target.
To file a defect, open it and select TM (Report to test management).

Documentation: Microsoft Learn: use personal access tokens · Microsoft Learn: what is Azure Test Plans?

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

Use cases

Run recent Azure test cases with AI

Trigger: A team imports the manual cases it changed recently
Uses: The 200 most recently changed Test Case work items and their steps
Agent activity: Imports them, marks duplicates and lists cases without steps
Result: Runnable cases in a TestingOps project
Condition: Older cases are not read; a CSV export can be pasted under Import existing test cases instead

Keep AI-written cases in Azure suites

Trigger: Agents write cases in the folder Checkout/Payment
Uses: The cases, their steps and their folder path
Agent activity: Push to TM creates the Checkout and Payment suites and the Test Case work items
Result: A suite tree in the test plan TestingOps uses
Condition: You cannot target one of your existing plans from the push dialog

Report a run and file the defect

Trigger: A regression run on RunningOps finishes with one confirmed defect
Uses: The run's results and the defect's fields
Agent activity: Send to TM records the test run; the TM button on the defect creates a Bug
Result: A completed test run and a Bug with repro steps
Condition: Only linked cases get results; with none linked, an empty run is created

Capabilities

Capabilities and limits

What is read

Test Case work items of a project: title, state, change date and steps
The 200 most recently changed per read; no suite or plan path

What is produced

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

Where it can write

Test Case work items with title and steps, added to static suites created from the folder path
Updates to linked cases (title and steps) and deletion of duplicates you confirm
Test runs with a result per linked case: outcome, duration and comment
Bug work items from TestingOps defects
Not written: preconditions, shared steps, parameters and configurations

How it connects

Organization URL (https://dev.azure.com/<organization>) and a personal access token

Account and permissions

TestingOps acts with the permissions of the token's owner
Creating test plans and suites needs an Azure DevOps access level that allows it, such as Basic + Test Plans

Limits

Reads stop at 200 cases, so a large project is only partly imported
Imported cases land without suite folders
Pushed cases go into the test plan TestingOps creates; there is no plan picker
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 keeps its manual cases in Azure Test Plans and its stories in Azure Boards. It pushes 18 AI-written cases from the folder Checkout/Payment; TestingOps creates the Checkout and Payment suites under the test plan it uses and adds the cases with their steps.

After the run on RunningOps, Send to TM records a completed test run with Passed or Failed per case and the failure message as the comment. The one confirmed defect is reported as a Bug with its repro steps.

Frequently asked questions

Which test plan do pushed cases go into?

Into a test plan that TestingOps creates in the target project on the first push and reuses later. The push dialog cannot target one of your existing plans, so copy or move cases into your own plans in Azure Test Plans if you need them there.

Why are only 200 cases read?

TestingOps asks Azure DevOps for the IDs in one query and reads the work items in one batch, which takes at most 200. It reads the 200 most recently changed Test Case work items; for the rest, paste a CSV export under Import existing test cases in Knowledge Base.

Do imported cases keep their suites?

No. The read carries no suite or plan path, so imported cases land without folders. Pushing in the other direction does build suites from the folder path.

Can it file bugs in Azure DevOps?

Yes. The TM button on a TestingOps defect creates a Bug work item with the defect title, and its steps, expected and actual result as repro steps.

Is there a two-way sync?

No. Imports run when you ask or on an hourly or daily schedule, and pushes, write-backs and run reports run when someone starts them. Before an Azure case is changed or deleted, TestingOps keeps a copy.

Next step

Bring an Azure DevOps project to a demo and see cases pushed into suites and a run recorded.

Request a demo More test management integrations