Integrations and automation in Zeta Test Management 5.2

Zeta Test Management can hand defects and other work items to external bug trackers and provides a small, separately secured MCP automation interface. Actual availability depends on the connector, target-system version, authentication, project permissions, product configuration and the operation you need.

Validate every integration with a representative non-production project before rollout. The presence of implementation code is not a support promise for every target-system release, field or operation.

Bug tracker connectors and rollout boundaries

The verified Zeta Test Management 5.2 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 5.2 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

The MCP interface introduced in Zeta Test Management 5.2.2 is intentionally small, globally disabled by default and not a general write or full-access API. It uses JSON-RPC 2.0 at POST /mcp.

MCP must be enabled globally and, for project tools, for the concrete project. Project API keys belong to active project users and inherit their roles and visibility. A global key receives project access only after separate authorisation. Prefer short-lived, purpose-specific keys, store them outside documentation and client logs, and revoke them when no longer needed.

The currently documented tools are:

  • ztm_usage_guide for the built-in usage guide;
  • ztm_tools_list for tools visible in the current authentication context;
  • ztm_mcp_search for searching the tool catalogue, not project test data;
  • ztm_admin_license_get for global administrative licence metadata;
  • ztm_project_test_library_export for a read-only JSON export of visible test-library nodes.

Before rollout, confirm TLS and proxy behaviour, key ownership and expiry, project-path restrictions, user visibility, export size limits, logging and the revocation procedure. Use the web application guide for the browser workflow and the Windows-client guide for comprehensive administration.