Category ยท 9 integrations
Private networks integrations
Many test environments are only reachable inside a company network. These options let test runs reach them without opening the environment to the internet.
A private network connection is about reachability, not about the tests themselves: the same test cases run, but the browser or device can now open addresses inside your network.
Compare
How these tools differ
| Tool | What TestingOps does with it | Connection |
|---|---|---|
| RunningOps host in the network | The only option where tests start inside your network: no VPN client or sign-in, and runs never fall back to the cloud pool. | Private network Available |
| GlobalProtect | SAML SSO in a sign-in window on the TestingOps card, a HIP report and a Windows or macOS client identity for portals with posture rules. | Private network Available |
| Check Point Remote Access | Keeps the VPN's encryption-domain routes, relays SMS or OTP codes and reconnects with a saved session; no SSO. | Private network Available |
| Cisco Secure Client (AnyConnect) | Password, certificate or both in a connection profile, with codes typed in TestingOps; the form lists SSO, but the gateway refuses it. | Private network Available with limits |
| FortiClient (SSL VPN) | FortiGate SSL VPN on your port and realm; password or certificate plus password, with no SSO and no IPsec mode. | Private network Available with limits |
| Ivanti Connect Secure (Pulse) | Password or certificate through your realm or sign-in URL path; SSO is listed in the form but not supported yet. | Private network Available with limits |
| OpenVPN | Uploaded .ovpn profile with IP ranges only; pushed routes and DNS are ignored and one-time codes are not supported. | Private network Available with limits |
| WireGuard | Uploaded peer configuration with keys only; AllowedIPs come from your IP ranges and the profile's DNS is dropped. | Private network Available with limits |
| IPsec (site-to-site) | Gateway-to-gateway tunnel with a pre-shared key or certificate and no user sign-in; on request, not self-service. | Private network On request |
Integrations in this category
RunningOps host in the network
Runs start on your own RunningOps host inside the network, so no VPN account, gateway or sign-in is needed.
Private networkAvailableGlobalProtect
A gateway machine signs in to your GlobalProtect portal with SSO, a password or a certificate and carries test traffic to internal addresses.
Private networkAvailableCheck Point Remote Access
A gateway machine signs in to your Check Point Remote Access VPN, asks for SMS or OTP codes in TestingOps and reconnects with a saved session.
Private networkAvailableCisco Secure Client (AnyConnect)
A gateway machine signs in to your ASA or FTD headend with a password, a client certificate or both; SSO is not supported yet.
Private networkAvailable with limitsFortiClient (SSL VPN)
A gateway machine signs in to your FortiGate SSL VPN with a password, or a certificate plus password, on the port and realm you set.
Private networkAvailable with limitsIvanti Connect Secure (Pulse)
A gateway machine signs in to your Ivanti Connect Secure appliance with a password or a client certificate, using your realm or sign-in URL path.
Private networkAvailable with limitsOpenVPN
Upload an .ovpn profile, optionally with a username and password; the gateway machine routes only the IP ranges you list.
Private networkAvailable with limitsWireGuard
Upload a WireGuard peer configuration; the gateway machine brings up the tunnel with wg-quick and routes the IP ranges you list.
Private networkAvailable with limitsIPsec (site-to-site)
IPsec site-to-site tunnels are available on request; the self-service form does not bring a tunnel up yet.
Private networkOn request
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.
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.