Category ยท 2 integrations
Test execution integrations
TestingOps runs test cases on an execution provider and brings back results, steps and evidence. Which providers a workspace can use is decided by its execution policy.
Running a case is separate from writing it. An execution provider supplies the browser, device or runner; TestingOps sends the case, follows the run and records the outcome.
Which runners a server may use is set by a server-wide execution policy. On testingops.ai that policy allows RunningOps; other runners that appear in the product are switched off there. Each page below states whether a provider runs tests, is limited by the policy, or is only reachable by agents as an MCP tool.
Compare
How these tools differ
| Tool | What TestingOps does with it | Connection |
|---|---|---|
| RunningOps.ai | The execution provider testingops.ai allows: runs cases with its own engine and returns verdicts with screenshots, video, logs and a script. | Execution provider Available |
| BrowserStack | Two roles: an agent tool over MCP that the policy does not block, and a direct Automate runner that the policy switches off. | Execution provider, MCP tool for agents Available with limits |
Integrations in this category
RunningOps.ai
Runs test cases with RunningOps' own engine and brings back verdicts, screenshots, video, logs and scripts.
Execution providerAvailableBrowserStack
Agents can call BrowserStack's hosted MCP tools; the direct Automate runner is switched off on testingops.ai.
Execution providerMCP tool for agentsAvailable with limits
Other categories
Issue trackers, wikis and code
Requirements, work items, documentation and code changes are where test design starts. These connections give TestingOps agents that context and, where supported, a place to report back.
Test management
Keep your test management tool as the system of record. TestingOps can send cases with their steps, bring existing cases into its knowledge base and report run results where the tool supports it.
Design tools
Screens, flows and workshop boards describe the intended behaviour before any code exists. These connections bring that material into the knowledge base that agents write test cases from.
Low-code platforms
Low-code platforms keep the application as a model: data, screens and logic in a structured form. Reading that model lets agents design tests around what the application actually contains.
Process models (BPMN)
A business process model already describes the paths a case can take. TestingOps turns BPMN 2.0 elements into bounded test scenario candidates for review.
App markets
Store reviews show where real users struggle. TestingOps turns them into insights for the knowledge base: themes, version-level signals and test ideas.
AI model providers
Choose the model provider your agents run on and use your own account and API key.
MCP tools for agents
These connections run in one direction: your TestingOps agents call an external tool through the Model Context Protocol (MCP) when a task needs it.
Connection guides
Use TestingOps from the apps you already work in. These are setup guides: you connect the app to TestingOps, and the app calls TestingOps.
Private networks
Many test environments are only reachable inside a company network. These options let test runs reach them without opening the environment to the internet.