What Is qTest? A Guide to Tricentis qTest Test Management

What Is qTest?

qTest is an enterprise test management platform from Tricentis. It stores test cases, organizes them into releases and cycles, records manual and automated results, and links requirements to tests to defects so QA leads can report coverage and release readiness across many projects at once.

It is a system of record, not a test runner. qTest tracks what should be tested and what happened when it was, while the tests themselves execute in whatever framework or grid your team already uses.

Tricentis currently positions the product as agentic test management and analytics. In practice, teams adopt it for four jobs:

• A central test case repository - one library of cases with folders, versioning, and custom fields, replacing scattered spreadsheets.
• Release and cycle planning - deciding which subset of that library runs for a given release, sprint, or regression pass.
• Result capture - recording pass, fail, blocked, and skipped outcomes from both manual sessions and automated runs in one place.
• Traceability and reporting - proving which requirements are covered, which are not, and which defects came from which failed test.

That last job is the one enterprises actually buy. In JetBrains' State of Developer Ecosystem 2023, 80% of respondents said testing plays an integral role in their software development projects, while only 46% used test case design as part of their testing process. Tools in this category exist to close that gap between stated intent and daily practice.

If you are new to the category, our guide to what test management is covers the process qTest is built to support.

Who Owns qTest, and Why Does QASymphony Keep Appearing?

Tricentis owns qTest. The product came from QASymphony, which announced in June 2018 that the two companies would merge under the Tricentis name. qTest now sits in the Tricentis portfolio next to that company's other testing products.

The old name still surfaces in search results, and that trips people up. Overview videos and walkthroughs published under the QASymphony brand continue to rank for qTest queries, so their screenshots show an interface and a logo that no longer match what you see after signing in.

Two practical consequences when you research qTest:

• Check the publication date before trusting a qTest tutorial, because pre-acquisition material describes menus that have since moved.
• Search both names when hunting for a specific feature, since some documentation and community threads are still filed under QASymphony.

What Are the qTest Modules?

qTest is sold as a suite rather than a single application, and the module names matter because pricing, documentation, and support articles are organized around them. Tricentis lists the following components on its product pages:

One thing to watch if you are comparing documentation against sales material: Tricentis has begun describing the newest flagship experience by capability, using labels such as agentic test creation, rather than by these module names. The module list still exists on the product feature pages, but the naming is being de-emphasized, so a support article and a current landing page can describe the same function with different words.

How Does qTest Actually Work?

The mental model is a hierarchy. Understanding it is what makes the rest of the tool, and any future migration, make sense.

• Project - the top-level container, usually one per product or business line.
• Modules and folders - the tree that organizes test cases by feature area. qTest calls the top level of this tree a module, which is separate from the product modules above.
• Test cases - the reusable definitions, each with a title, preconditions, priority, type, and an ordered list of steps with expected results.
• Releases and test cycles - the planning layer that selects which cases run in a given sprint or regression pass.
• Test runs - the execution records, one per case per cycle, holding the actual outcome and any attachments.
• Defects - raised from a failed run and linked back to it, usually in Jira rather than in qTest itself.

Those components are the checklist any test management platform is measured against, and qTest covers most of them directly while leaving execution to tools outside the product.

The split between the design layer and the execution layer is the important part. Test cases are the reusable assets; runs, cycles, and defects are the history of what happened to them.

That distinction decides what you can carry with you if you ever change tools, and it is where most migration surprises come from.

How Does qTest Connect to Jira and CI?

Integration breadth is the main reason large organizations pick qTest, and it works along two axes.

Jira and the ALM side

qTest links test cases to Jira issues so a requirement or user story carries visible test coverage, and a failed run can raise a defect without leaving the test. For teams whose planning already lives in Jira, this connection is what makes the traceability reporting meaningful rather than decorative.

That emphasis tracks the market. The Stack Overflow Developer Survey 2025 found 52.1% of professional developers used Jira regularly over the previous year. When that much of the profession already works inside one tracker, the depth of a test management tool's Jira sync is a more useful question than the length of its integration list.

It is worth being clear about the boundary. qTest holds the test assets and Jira holds the work items, so the integration is a synchronization between two systems rather than one tool doing both. Teams that want the test cases to live inside Jira itself usually evaluate Jira test management tools that install as an app instead.

Automation and CI

Because qTest does not run tests itself, automated results have to be pushed in from wherever execution happens. The standard route is an agent that Tricentis calls the Automation Host, which watches for completed runs and submits the resulting report back into qTest Manager.

TestMu AI supports exactly this flow. Tests run on the TestMu AI grid through HyperExecute, and the JUnit XML report is handed to that agent so the outcome lands against the right test cycle in qTest. The setup steps are documented in the HyperExecute qTest integration guide, which is the practical option if you want to keep qTest as the reporting system while moving execution somewhere faster.

Is qTest Free, Cloud Based, or Open Source?

These three questions come up constantly in search, and all three have short answers.

• Free - no. Tricentis does not publish qTest pricing anywhere on its product site, and there is no free tier. Access starts with a trial or a quote, so you cannot size the cost without talking to their sales team.
• Cloud based - yes, and also not only. qTest is offered as hosted SaaS, and Tricentis additionally ships a self-managed build documented under the qTest OnPremises name for teams that cannot place test data in multi-tenant infrastructure.
• Open source - no. qTest is commercial and closed source. The confusion is a naming collision with Qt's QTest, the open source C++ unit testing framework, which is a genuinely different product from a different company.

The absent price page is worth planning around rather than complaining about. Enterprise test management is generally sold per seat with tiering, which means the real evaluation question is how many people need write access versus how many only need to read reports.

If a public price is a hard requirement for your procurement process, comparing against tools that publish one is the faster path. Our roundup of free test management tools covers the options with published limits.

What Actually Moves If You Migrate Off qTest?

This is the question almost no qTest overview answers, and it is the one that decides how expensive a platform change becomes. The short version: your test design survives a migration, and your execution history usually does not.

TestMu AI Test Manager reads directly from qTest using your instance URL and an API token, so there is no manual export step. The table below is drawn from that documented migration path and is a fair guide to what any tool-to-tool move can realistically carry.

The right-hand column is the one to plan for. Execution history is scoped to the tool that produced it, so if your audit or compliance process depends on multi-year run history, you either keep a read-only qTest instance or export that history separately before switching.

Four documented behaviours are worth knowing before you start, because each one surprises people mid-migration:

• Duplicate names get suffixed - folders and projects sharing a name are renamed with a numeric suffix, because the destination requires unique names.
• Custom fields match by name - if a field with the same name already exists, it is reused as-is and its type is not changed, so audit your field list first.
• Shared test cases are flattened - a called or shared case is expanded inline into the calling case's steps rather than staying a reference.
• Freeze the source - editing the qTest project while a migration runs risks an inconsistent import.

The flow itself is short. You open Test Manager Projects, choose Import data, select qTest as the source, supply the instance URL and API token, pick the projects, and the migration continues in the background with an email when it finishes. Full prerequisites and troubleshooting are in the one-click qTest migration documentation.

If you would rather not connect the two systems directly, Test Manager also accepts a CSV import, which trades the API setup for a manual field-mapping pass. Either route lands the same test-design data on the other side.

The reason to consolidate is visible in that sequence. When the case repository and the execution grid sit in one workspace, run history accumulates where the cases already live, so the execution layer you could not carry across stops being a thing you have to migrate at all.

Who Should Use qTest?

qTest is built for scale and governance, and that focus makes it a strong fit for some teams and an expensive mismatch for others.

A good fit when

• You are running many parallel projects and need consistent reporting across all of them rather than per-team dashboards.
• Requirement-to-defect traceability is an audit obligation, not a nice-to-have.
• You already run other Tricentis products and want the test estate in the same portfolio.
• A self-managed deployment is mandatory for data residency reasons.

A poor fit when

• You are a single team who mostly needs test cases attached to Jira issues, where a lighter app does the job.
• You need published pricing to get budget approved before a sales conversation.
• You want management and execution in one platform, since qTest deliberately leaves execution to other tools.
• Your rollout window is weeks, not quarters, because the configuration depth that suits enterprises slows down small teams.

If you have reached the second list, the comparison worth reading next is our breakdown of qTest alternatives, which ranks the options on governance, consolidation, and migration effort.

Conclusion

Start by writing down which of the four jobs in the first section you actually need. Most teams evaluating qTest need the repository and the traceability, and discover late that they also needed execution, which qTest leaves to another tool.

If your shortlist includes consolidating management and execution, TestMu AI Test Manager covers case authoring with AI generation, plans and cycles, and traceability from requirements through to tests, runs, and defects, with results arriving from the same platform that ran them. Test analytics across those runs live in Test Insights.