The refreshed qTest Manager user experience goes live for all users in September 2026, giving release owners a single visual standard to govern across test planning, execution, and reporting workflows.
The immediate feature is a refreshed color scheme intended to provide visual consistency throughout qTest Manager. Users can opt out for now, but that decision has a clear operating consequence: they will not receive future improvements built in the new interface.
What changes in September
September moves the refreshed user experience from an opt-in availability model to broad availability for all users. The update is a user-interface change, not a stated migration of test assets, integrations, or execution history.
For enterprise teams, this distinction matters. The principal delivery work is not data conversion; it is managing user adoption without introducing avoidable friction into active release cycles.
Key points:
- The refreshed color scheme becomes available across qTest Manager.
- Users may opt out of the new experience.
- Opted-out users will not receive future new-interface improvements.
- Availability can appear gradually, so environments may not update at the same moment.
Why release owners should treat this as a governed change
A visual update can still affect controlled work. Test leads and release managers rely on fast recognition of status, navigation patterns, action controls, and evidence views during high-pressure delivery windows. Even where records and process rules remain unchanged, a modified interface can affect execution speed and the consistency of user actions.
The risk is usually operational rather than technical: inconsistent training, local workarounds, support demand, or late discovery that a documented procedure no longer matches the screen users see.
Release owners should avoid an untracked mix of old and new interfaces across teams for longer than necessary. That makes support, procedural evidence, and root-cause analysis harder when a workflow issue is reported.
A practical adoption plan
Start with the teams that perform the highest-volume or highest-control qTest workflows. This commonly includes test execution leads, test managers, release coordinators, quality governance staff, and administrators.
Use a short, focused validation checklist:
- Navigate requirements, test cycles, suites, and test runs.
- Execute and update representative manual test runs.
- Review linked defects and Jira-connected requirement workflows.
- Confirm reporting and release-health review activities.
- Check screenshots, work instructions, and training references used as audit evidence.
Then establish a named owner for opt-out decisions. Opt-out should have a business reason, an expiry date, and a plan to move the affected users forward. Otherwise, a temporary compatibility choice becomes unmanaged delivery debt.
Governance and audit considerations
For regulated teams, assess the update under the organization’s existing change-control process. The release notes describe an interface refresh, but validation depth should reflect the criticality of the workflows supported by qTest in your environment.
Document:
- The scope of affected roles and projects.
- The workflows reviewed and the results of that review.
- Any changes needed to standard operating procedures or training.
- Approved exceptions for users who opt out.
- The target date for ending exceptions.
This gives quality leaders evidence that interface adoption was considered deliberately rather than left to individual preference. It also helps distinguish a product-interface issue from a process or training issue if execution quality changes after rollout.
Workflow impact for QA and DevOps teams
The update is most relevant where qTest acts as the decision record for release readiness. QA teams need consistent visual cues when reviewing execution status and defects. DevOps and release teams need a predictable path to the evidence that supports a deployment decision.
Teams already using qTest with Jira or Tosca Cloud should include those connected workflows in their spot checks. The September notes do not announce integration changes, but interface adoption is a good point to confirm that users can still complete their normal planning, automation-result review, and traceability tasks as expected.
A small pilot is often enough. The goal is not to repeat full regression testing of qTest; it is to prove that the work people perform to make and evidence release decisions remains clear, repeatable, and documented.
Recommended executive actions
- Sponsor one organization-wide adoption position for the new UI.
- Ask QA leadership to validate critical workflows by role.
- Require time-bound approval for UI opt-outs.
- Update training assets that contain qTest screenshots or navigation instructions.
- Review adoption and support signals after the rollout reaches your environment.
This approach preserves delivery momentum while preventing an unnecessary split in operating practices across the testing organization.
How Merito helps
Merito helps enterprises assess qTest changes against their delivery model, regulated-process obligations, and integration landscape. We can define an adoption plan, run role-based workflow validation, update governance artifacts, and create a measurable path to retire opt-outs. The result is a controlled user-interface transition that supports release teams rather than adding uncertainty during delivery.
Merito is an authorized Tricentis reseller and services partner, listed as a Certified Solution Partner in the Tricentis partner directory. Our Tricentis qTest team can scope licensing, sizing, and rollout for September 2026, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.