Category ยท 9 integrations
Process models (BPMN) integrations
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.
Process models arrive in two ways: a direct connection to the modelling tool, or a link to an exported BPMN 2.0 file, for example in a Git repository. Each page says which applies.
Paths from start to end become scenario candidates, with the gateway decisions and events along the way. They are bounded: at most 30 paths per process and 60 steps per path, loops followed once and parallel branches listed separately. Treat them as a starting point for review, not as complete coverage.
Compare
How these tools differ
| Tool | What TestingOps does with it | Connection |
|---|---|---|
| Camunda | Direct API connection to Camunda 8 Web Modeler or the Camunda 7 engine, or a .bpmn file link; also lists inline form fields as test data hints. | Native connection, Exported file link Available |
| Bizagi | Exported .bpmn file from Bizagi Modeler, read from a link; changes arrive when the file at the link changes. | Exported file link Available |
| SAP Signavio | Direct API connection to Process Manager: walks the folder tree and exports BPMN 2.0 XML only when a model's revision changed. | Native connection Available |
| BPMN 2.0 file | Any BPMN 2.0 export read from a link (Git or any https address); the route for tools without their own connection. | Exported file link Available |
| IBM Blueworks Live | Direct API connection with a Service ID: exports the latest revision of a blueprint as BPMN 2.0, only when the revision changed. | Native connection Available |
| Celonis Process Management | Direct API connection to one Process Management storage with its REST token; BPMN export only when the element version changed. | Native connection Available |
| ADONIS | Direct API connection with a standard ADONIS user over Basic authentication; the model is downloaded each sync and rewritten only when it changed. | Native connection Available |
| Flowable | Direct connection to the Flowable REST API (open source, Work or Engage) or a .bpmn / .bpmn20.xml file link; CMMN and DMN are not read. | Native connection, Exported file link Available |
| ARIS | Exported .bpmn files from ARIS read from links; bulk export with an ARIS report script, each file linked. | Exported file link Available |
Integrations in this category
Camunda
Reads Camunda 8 Web Modeler files or deployed Camunda 7 processes and lists their paths as bounded test scenario candidates.
Native connectionExported file linkAvailableBizagi
Link a BPMN file exported from Bizagi Modeler; its lanes, gateways and events become bounded test scenario candidates.
Exported file linkAvailableSAP Signavio
Reads Process Manager BPMN models through an API user and turns their paths into bounded test scenario candidates.
Native connectionAvailableBPMN 2.0 file
Link a .bpmn file exported from any modeling tool; its paths, gateways and events become bounded scenario candidates.
Exported file linkAvailableIBM Blueworks Live
Exports Blueworks Live process blueprints as BPMN 2.0 through a Service ID and lists their paths as scenario candidates.
Native connectionAvailableCelonis Process Management
Reads processes of a Process Management storage (formerly Symbio) through its BPMN export; process mining data is not read.
Native connectionAvailableADONIS
Finds BPMN 2.0 business process diagrams in ADONIS repositories and turns their paths into bounded scenario candidates.
Native connectionAvailableFlowable
Reads the latest deployed process definitions through the Flowable REST API, or a .bpmn file link, and lists their paths as candidates.
Native connectionExported file linkAvailableARIS
Link BPMN files exported from ARIS, one by one or in bulk with a report script; their paths become scenario candidates.
Exported file linkAvailable
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.
Test execution
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.
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.
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.