Product scope and interface coverage
This page compares the verified Zeta Test Management 5.2 scope across the Windows client, web application and MCP interface. The interfaces share project and permission boundaries but are not feature-equivalent.
Use the linked summaries as planning entry points. Detailed prerequisites are maintained in System requirements; current connector, Jira REST and MCP setup boundaries are maintained in Integrations and automation.
Product scope and interface matrix
Zeta Test Management supports the structured preparation, execution and evaluation of software tests. The Windows client remains the primary application for project setup, administration and the broadest functional scope. The web application adds browser-based core and preview areas. MCP provides a small, separately secured automation interface rather than general write or full access.
| Area | Windows client | Web application | MCP |
|---|---|---|---|
| Structure projects and the test library | Broad primary scope | Test library and requirements as configurable preview areas | Read-only JSON export of visible test-library nodes |
| Execute test runs | Yes | Core area | – |
| Search and evaluate results | Yes | Result search as a core area | – |
| Planning, performed tests, reviews and reports | Yes | Performed tests, reviews and reports as preview areas | – |
| Backup and test variants | Yes | Preview areas | – |
| Administration and integrations | Primary interface | Depends on release, configuration and permissions | No general administration or write interface |
A dash means that no dedicated current MCP tool is documented for that area. Edition, licence, roles, project features and deployment model can further limit the visible scope.
Web preview areas
Preview areas are disabled globally by default. Enable them with AppSettings.ExperimentalWebAreas.Enabled and restrict individual areas through DisabledAreas. The current keys are requirements, test-library, performed-tests, reviews, reports, backup and test-variants. Roles and project features provide additional visibility checks.
MCP interface in version 5.2
The MCP interface introduced in version 5.2.2 is disabled globally and per project by default. It uses POST /mcp. Prefer short-lived, purpose-specific API keys with least privilege; a global key receives project access only after separate authorisation.
The current tools are ztm_usage_guide, ztm_tools_list, ztm_mcp_search, ztm_admin_license_get and ztm_project_test_library_export. ztm_mcp_search searches the tool catalogue, not test data. The test-library export is read-only and returns only nodes visible to the authenticated user as JSON. MCP is therefore not a general write or full-access API.
Validate the intended workflows with a representative project and confirm release-specific limitations with Zeta Software before a broad rollout.
System requirements
The detailed current requirements are maintained on System requirements for Zeta Test Management 5.2. The dedicated page distinguishes the Windows client, local web executable, central IIS deployment, browser, database and workload sizing.
The current technical baseline is Windows x64 and .NET 10. Exact operating-system, Windows Server, IIS, browser and SQL Server versions remain release-specific support decisions and should be confirmed before production rollout.
Bug tracker integrations
The verified Zeta Test Management 5.2 factory registration includes connectors for:
- Atlassian Jira through the REST API
- Mantis
- Redmine
- FogBugz
- Request Tracker
- Pivotal Tracker
The presence of a connector does not guarantee every target-system release or operation. Before rollout, verify authentication, project selection, required and custom fields, status values, comments and attachments against a representative test instance. Confirm the supported combination with Zeta Software.
Jira authentication
- Jira Cloud: select
Basic, use the Atlassian account email address as the user name and an Atlassian API token as the password, and setJira-IsCloudJiratotrue. - Jira Data Center: select
Bearerand enter a personal access token in the security-token field, subject to the target version and security policy. - Custom gateway: select
CustomHeaderand configure the secret plusJira-AuthHeaderNameand, if required,Jira-AuthHeaderPrefix.
Use HTTPS and a dedicated technical account with least privilege. Never place real secrets in documentation or screenshots. Older documentation may name Microsoft TFS or Azure DevOps, Trac, Bugzilla or OnTime; their absence from the currently verified factory registration is not a statement about a legacy or custom integration, but they must not be planned without explicit support confirmation.