Category ยท 8 integrations
Issue trackers, wikis and code integrations
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.
A test case is only as good as the requirement behind it. Trackers hold the user stories, acceptance criteria and defects; wikis hold the analysis and decisions; code hosts hold the changes that decide what needs retesting.
TestingOps reads what you authorise into the project's knowledge base, uses it when agents write and review test cases, and writes back only where a tool and your settings allow it, for example a defect or a comment.
Compare
How these tools differ
| Tool | What TestingOps does with it | Connection |
|---|---|---|
| Jira | Requirements source and workflow trigger: knowledge sync, Tester Agent rules on board columns, impact-based runs, result comments and defects filed on request. | Native connection Available |
| GitHub | Repository issues and pull requests as requirements, labels as Tester Agent columns, defects as issues labelled bug, and deployment statuses that start a test plan run. | Native connection Available |
| GitLab | gitlab.com or self-managed by base URL; issue board lists as Tester Agent columns, notes as replies, defects as issues, and deployment events that start a plan run. | Native connection Available |
| Azure DevOps | Work items of every type in a team project, the Acceptance Criteria field, state-based Tester Agent rules through service hooks and Bug work items; Azure Repos commits are not searched. | Native connection Available with limits |
| Confluence | A read source: the pages of one space per link become know-how documents, refreshed by page version, and agents can search the space live. | Native connection Available |
| Bitbucket | A read-only code source: pull requests, the README and files, plus Jira-key commits for the Jira Tester Agent; no issue filing, comments or agent rules. | Native connection Available with limits |
| Linear | One team per link over Linear's API, defects as Linear issues and agent tools for comments and workflow states; no Tester Agent rules. | Native connection Available |
| YouTrack | Cloud or self-hosted by base URL and permanent token; State, tag and assignee changes through YouTrack commands; no Tester Agent rules. | Native connection Available |
Integrations in this category
Jira
Stories and acceptance criteria become test context; agents act on the workflow steps you choose and report back on the issue.
Native connectionAvailableGitHub
Issues, pull requests and the README become test context; agents work on issues through label-based board rules and file defects as issues.
Native connectionAvailableGitLab
Issues, merge requests and the README become test context; agents follow issue board lists and reply in notes.
Native connectionAvailableAzure DevOps
Work items and their Acceptance Criteria field become test context; agents act on state changes through service hooks.
Native connectionAvailable with limitsConfluence
The pages of a Confluence space become know-how that agents read when they write and review test cases.
Native connectionAvailableBitbucket
Pull requests, the README and repository files become test context; commits with Jira keys feed Jira impact analysis. Read-only.
Native connectionAvailable with limitsLinear
A team's issues become test context; agents read and update issues, and defects become Linear issues.
Native connectionAvailableYouTrack
Project issues become test context; agents comment, change State and tag issues; defects become YouTrack issues.
Native connectionAvailable
Other categories
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.
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.