Category ยท 4 integrations
Design tools integrations
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.
Design files show what the user should see and do; whiteboards and diagrams record flows and decisions. Reading them early lets test preparation start during design instead of after release.
These connections provide context for test design. They do not generate visual comparison tests from designs.
Compare
How these tools differ
| Tool | What TestingOps does with it | Connection |
|---|---|---|
| Figma | Reads frames screen by screen with controls and prototype links; also analyses public prototype links without a token. | Native connection Available |
| Miro | Reads whiteboard frames with stickies, cards and connector captions; one document per frame. | Native connection Available |
| Zeplin | Reads handoff screens with annotations, designer notes and flow boards; only changed screens are re-read. | Native connection Available |
| draw.io | Reads a diagram file from a link (Git or diagrams.net), not an account: shapes under lanes and labelled arrows, one document per page. | Exported file link Available |
Integrations in this category
Figma
Turns each Figma screen into a knowledge-base document with its texts, controls and prototype links.
Native connectionAvailableMiro
Reads Miro board frames, sticky notes, cards and connectors as context for scenarios.
Native connectionAvailableZeplin
Reads handoff screens with annotations, designer notes and flow boards as context for test cases.
Native connectionAvailabledraw.io
Reads draw.io files from a link: shapes under their swimlanes and labelled arrows, page by page.
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.
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.
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.