OpenText

OpenText AQM 26.1: Strengthen traceability, approvals, and release evidence

OpenText AQM 26.1 improves release governance through project reporting, requirement coverage, traceability, baselines, version comparison, and controlled electronic approvals. Teams can restrict new requirement-to-test coverage links, assign approval permissions by user group, and set re-authentication requirements for signature actions. These capabilities support auditable delivery decisions across regulated and enterprise software portfolios.

By Chris CarpenterOpenTextALMAQMEnterprise Testing
OpenText LogoOpenText AQM
OpenText AQM 26.1: Strengthen traceability, approvals, and release evidence cover graphic
Back to OpenText release updates
Release facts
VendorOpenText
ProductOpenText Application Quality Management
Version26.1
Published by MeritoAugust 26, 2026
Release historyOpenText Application Quality Management release history

OpenText AQM 26.1 gives release owners group-based approval permissions and configurable re-authentication for electronic-signature actions, making it easier to enforce accountable release decisions. The update also expands reporting, requirements evidence, version control, and reusable baseline capabilities in the Web Client.

Reporting that supports release decisions

Project teams can now generate, preview, and download project reports directly in the Web Client. Business View Excel reports can also be generated and modified in Microsoft Excel, providing a practical route for teams that need governed operational reports alongside executive-ready analysis.

For release management, the value is not simply more reports. It is a clearer and more repeatable path from quality data to decision evidence:

  • Produce project-level evidence without depending on desktop-only reporting workflows.
  • Export Business View data for controlled analysis and stakeholder distribution.
  • Reduce manual collection of status, coverage, and quality information before release reviews.

Report ownership still matters. Organizations should define approved report templates, data refresh expectations, and who may distribute release evidence externally.

Tighter control of coverage and traceability

The Web Client now lets teams add requirement coverage to tests and refine that coverage by test configuration. This makes coverage evidence more specific where a requirement must be validated across platforms, environments, or configurations.

A new site parameter, DISABLE_REQUIREMENT_TEST_COVERAGE, allows administrators to prevent users from adding new requirement-to-test links. This is important for programs where coverage relationships are controlled artifacts: an unauthorized link can make a coverage position appear stronger than the approved test strategy supports.

Requirement traceability is also now available in the Requirements module. Combined with configuration-aware coverage, it supports stronger answers to common release-review questions:

  • Which approved requirements are covered by tests?
  • Which configuration-specific obligations remain unverified?
  • What upstream or downstream requirement relationships affect release scope?
  • Who was permitted to alter the evidence model?

Better change evidence through versions, libraries, and baselines

Teams can compare two versions of a requirement or test from the entity history. This reduces the effort required to determine what changed between a prior approved state and the current release candidate.

Libraries and baselines add another governance layer. Teams can organize reusable project content, capture baselines, compare changes over time, and import libraries into other projects. For enterprise delivery organizations, this can support controlled reuse of test assets and clearer separation between a shared standard and a project-specific variation.

Baseline practices should be defined deliberately. Establish naming conventions, approval criteria, and retention expectations before treating a baseline as formal release evidence. Otherwise, multiple baselines can create ambiguity rather than control.

Electronic approvals gain practical administrative controls

Electronic-signature workflows now support bulk approval submission. Teams can submit multiple records within an entity for approval in one flow, which can reduce repetitive work when a release package contains many related items.

Administrators can also configure approval permissions by user group. For specific entities, groups can be authorized to submit, withdraw, or reassign approval requests, while access to approval audit trails can be granted separately. This lets organizations apply separation of duties without giving broad workflow privileges to every contributor.

The new approval settings also provide a re-authentication policy for signature actions:

  • No re-authentication
  • Re-authentication once per active session
  • Re-authentication for every action

The appropriate setting depends on risk, shared-device exposure, regulatory obligations, and the materiality of the approval. High-assurance workflows may require authentication on every action; lower-risk internal workflows may reasonably use a session-based policy. Security, quality, and compliance owners should agree the policy before rollout.

Workflow and dashboard updates

Workflow support now includes approval information and queries of linked entities across different modules. These additions can help teams build workflow rules that reflect approval state and cross-module relationships, rather than relying on isolated entity data.

A modern dashboard experience is available as a technology preview. It supports creating dashboard pages and graphs, composite graphs, and image exports. Because it is marked as a preview, teams should validate reporting accuracy, permissions behavior, operational support, and adoption needs before using it as a primary management reporting mechanism.

Implementation priorities for enterprise teams

A practical adoption sequence is to start with controls that affect evidence integrity, then improve reporting and user experience.

  • Review approval roles, audit-trail access, and re-authentication requirements.
  • Decide whether new requirement-to-test links require centralized change control.
  • Define baseline ownership and version-comparison use in release reviews.
  • Standardize project and Business View reports for release gates.
  • Pilot the dashboard preview with a limited stakeholder group.

This sequence keeps governance decisions ahead of broad configuration changes. It also gives teams a defensible operating model when auditors or release boards request evidence.

How Merito helps

Merito helps enterprises assess AQM configuration against delivery governance, audit, and DevSecOps operating requirements. We can define role models, approval policies, reporting standards, traceability practices, and rollout plans for the new capabilities, while helping teams avoid disruptive changes to established release workflows.

Merito is an authorized OpenText reseller and services partner. Our OpenText AQM team can scope licensing, sizing, and rollout for 26.1, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.

About OpenText Application Quality Management

OpenText Application Quality Management licenses, renewals, upgrades and implementation are available through Merito, an authorized OpenText reseller and services partner.

Frequently Asked Questions