Skip to content

Integrations and automation in Zeta Test Management

Zeta Test Management integrates with external bug trackers, exposes a governed MCP automation endpoint, and can connect supported web workflows to approved local Windows actions through Zeta Test Local Bridge. Availability depends on connector and target-system versions, authentication, product configuration, project permission, API-key scope, and the specific operation.

MCP is not limited to the original read-only introduction in 5.2.2. The current capability platform supports approved reads and protected writes through the same domain services as web chat. Every write remains gated by preview, explicit commit, and audit.

Bug tracker connectors and rollout boundaries

The verified Zeta Test Management 6.0 product path contains factory-registered connectors for:

  • Atlassian Jira through the REST API;
  • Mantis;
  • Redmine;
  • FogBugz;
  • Request Tracker;
  • Pivotal Tracker.

Before introducing a connector, verify authentication, project selection, required and custom fields, status values, comments and attachments against a representative target instance. Confirm the supported combination with Zeta Software.

Older documentation may mention Microsoft TFS or Azure DevOps, Trac, Bugzilla or OnTime. These names are not registered in the currently documented 6.0 factory path. This does not assess a legacy or customer-specific implementation, but the systems must not be planned without explicit support confirmation.

For the broader interface comparison, see Product scope, integrations and requirements.

Configure Jira REST securely

The current Jira connector uses the Jira REST API. Prepare an HTTPS base address, a Jira project key or project ID, and a dedicated account or revocable token with only the required permissions. Do not place real credentials in documentation, screenshots or support packages.

  1. Open the bug-tracker configuration in the Zeta Test Management project settings and select Jira.
  2. Enable the integration and enter the Jira HTTPS base address, for example https://jira.example.org. Do not append a REST path; the connector adds /rest/api/2/.
  3. Enter the Jira project key or required project ID.
  4. Select the authentication mode, enter the corresponding account or token values, and test the connection.

Jira Cloud: Basic with API token

Select Basic, use the Atlassian account email address as the user name and an Atlassian API token as the password, and set Jira-IsCloudJira to true. Do not use the normal Atlassian account password.

Jira Data Center: Bearer token

Select Bearer and enter a personal access token in the security-token field. Verify that personal access tokens are enabled for the target Data Center version and security policy.

Custom security gateway

Select CustomHeader when the approved target configuration requires a dedicated HTTP header. Configure the secret together with Jira-AuthHeaderName and, if required, Jira-AuthHeaderPrefix.

Validate fields and troubleshoot

Create a test issue and verify summary, description, issue type, priority and every required custom field directly in Jira. Validate comments and attachments separately when they are part of the intended workflow. If the connection fails, check the base address, Jira-AuthMode, token state, account permissions, project key, required fields, proxy, firewall, DNS and TLS trust in that order. Record the HTTP status and relevant logs without secrets.

MCP automation and rollout validation

MCP uses JSON-RPC 2.0 at POST /mcp. It is disabled until explicitly configured. Personal project API keys inherit the active user's roles and permissions; global administrative keys remain separate, and project access for a global key requires an additional approval.

The tool catalogue covers approved project and administration domains rather than one fixed list of introductory tools. Read the visible catalogue in the current authentication context and use the capability explorer before automating an operation. Protected writes use a fail-closed prepare → preview → commit → audit lifecycle with permission, version, and idempotency checks.

Before rollout, verify TLS and proxy behaviour, key ownership and expiry, project selection, least-privilege scopes, user visibility, logging, revocation, and the preview/commit behaviour in a representative non-production project. Detailed guidance is available under Safe actions, MCP and Local Bridge.

Import existing JUnit results

The web client supports importing automated test results into an explicitly selected test run. Preview and map results before committing; the import does not execute programs or contact CI servers.