qTest
Enterprise test management by Tricentis. Scales from agile teams to global QA organisations with ALM and automation integration.
Overview
qTest, created by QASymphony in 2011 and acquired by Tricentis in 2018, is an enterprise test management platform. It provides test case management, test execution, exploratory testing, and automation integration in a single platform. qTest is part of the Tricentis ecosystem, integrating with Tosca, Testim, and NeoLoad for end-to-end quality management.
qTest is designed for large organisations with complex testing requirements — multiple teams, global locations, regulatory compliance, and diverse technology stacks.
What it's used for
qTest is the right choice when:
- Enterprise scale: Hundreds of testers across multiple teams and locations.
- Tricentis ecosystem: Integration with Tosca, Testim, and NeoLoad.
- Exploratory testing: Built-in session-based exploratory testing with charter management.
- Regulatory compliance: Audit trails, electronic signatures, and compliance reporting.
Pros & Cons
Pros
- Scales to enterprise size with robust permissions and governance
- Strong integration with Tricentis automation tools
- Built-in exploratory testing management
- Advanced analytics and portfolio reporting
- Professional support and implementation services
Cons
- Expensive — enterprise pricing only
- Complex setup and configuration
- Can be overwhelming for small teams
- Smaller community than TestRail or Jira plugins
- Requires Tricentis partnership for full value
Platforms & Integrations
qTest is a cloud-based SaaS with optional on-premise deployment. It runs in any modern web browser.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Enterprise | Custom | All modules, professional services, dedicated support |
NZ Context
qTest is used by a small number of large NZ enterprises with Tricentis contracts. For most NZ teams, TestRail or Jira + Xray provide better value. qTest is most relevant for NZ professionals working in multinational companies with global QA standards.
Alternatives
- TestRail — More affordable and easier to set up for most teams.
- Xray (Jira) — Better agile integration if already using Jira.
- PractiTest — Modern SaaS alternative with strong automation integration.
When to choose qTest
A quick decision guide for NZ teams evaluating test management options.
| Choose qTest when… | Choose something else when… | Combine with… |
|---|---|---|
| You are already in the Tricentis ecosystem — Tosca or Testim is your automation platform and you need test management that speaks the same language. | Your team is under 30 testers. TestRail gives you 90% of the capability at a fraction of the cost and is live in a day, not a month. | Jira for defect tracking — qTest syncs bidirectionally so your test runs and bug tickets stay linked without manual copy-paste. |
| You need regulatory-grade audit trails — electronic signatures, immutable execution history, and compliance reports for ISO 13485, FDA, or financial-services audit. | You are already deep in Jira. Xray or Zephyr Scale keeps everything in one tool; switching to qTest adds a second system your developers will ignore. | NeoLoad or k6 for performance testing — qTest can aggregate results from load runs alongside functional test metrics in a single quality dashboard. |
| You run session-based exploratory testing at scale. qTest Explorer records sessions, captures evidence, and links charters to requirements — tools like TestRail have no equivalent. | Your budget is fixed and small. Enterprise-only pricing with no self-service tier means procurement cycles of weeks and negotiation before you can trial it properly. | Selenium Grid or Playwright with the qTest Automation Host — pipe your CI results directly into qTest so every pipeline run is automatically reflected in your test dashboard. |
| You manage QA across multiple business units or geographies and need portfolio-level reporting — release readiness across five squads in one view, not five separate spreadsheets. | You are a startup or scale-up moving fast. The implementation overhead and contract length work against you — PractiTest or Linear + a lightweight test plugin will serve you better until you hit genuine enterprise complexity. | Azure DevOps or GitHub Actions — qTest's REST API and native connectors let you pull test results from any CI platform into a centralised quality gate without changing developer workflows. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were the QA lead at TechServNZ — running a managed services organisation with hundreds of testers spread across NZ, Australia, and Asia-Pacific delivery centres, each client project with its own compliance requirements.
I would…
Evaluate qTest seriously — but insist on a 90-day pilot before signing an enterprise contract. I would run the pilot on one mid-size client engagement, measure onboarding time for new testers, integration effort with the client's Azure DevOps instance, and whether the portfolio dashboards actually reduce the reporting overhead my leads currently spend 3 hours a week on manually. If those three things improve, I would commit. If not, I would standardise on TestRail, which my teams already know and can spin up for a new client in an afternoon.
If…
I were a senior QA engineer at Harbour Bank — a heavily regulated bank with SOX and RBNZ obligations, multiple squads across retail, business banking, and the mobile app, and an existing Tricentis Tosca licence for UI automation.
I would…
Recommend qTest without much hesitation — but only because Tosca is already in the building. The Tosca-to-qTest integration is tight enough that automation results feed directly into test reports with no manual wiring, which is exactly what a compliance audit needs: a single unbroken chain from requirement to automated run to sign-off. I would also insist on turning on electronic signatures for UAT cycles on the day of go-live, not three months later when someone realises the audit trail is incomplete. That configuration step takes an afternoon; retrofitting it across 2,000 test cases does not.
If…
I were a test manager at HealthNZ — consolidating QA practices across multiple DHB-legacy systems, a mix of waterfall clinical applications and newer agile digital health products, with a mandate to standardise tooling across the organisation.
I would…
Push back on qTest unless the organisation is already committed to a Tricentis relationship. The honest assessment: HealthNZ's problem is not test management sophistication, it is consistency. Jira plus Xray would unify defect tracking and test cases in one system that developers, product owners, and testers all already use, and it would get adopted far faster than a new enterprise platform with a separate login. I would reserve qTest as the answer for the specific clinical-software programmes that genuinely need ISO 13485-aligned audit trails — and run everything else on the simpler stack.
The bottom line: qTest is a powerful answer to a specific question — how do you manage quality at enterprise scale when automation, exploration, and compliance all need to live in one auditable system? If that is not your question yet, the tool will cost you more in overhead than it saves. Buy complexity only when simplicity has already failed you.
Interview questions
Questions you are likely to get if you list qTest on your CV — with what interviewers are really testing for.
What is the difference between qTest Manager, qTest Explorer, and qTest Insights — and when would you use each?
What they’re really testing: Whether you actually used the platform or just put the name on your CV — genuine users know the module boundaries by feel.
Strong answer covers: Manager handles structured test case authoring, execution cycles, and requirements traceability; Explorer is session-based exploratory testing with charter management and evidence capture; Insights is the cross-project reporting and portfolio dashboard layer. Bonus: mention that many NZ teams licence only Manager and bolt on a BI tool rather than paying for Insights separately.
When would you choose qTest over Xray for Jira, and when would you go the other way?
What they’re really testing: Tool judgement — they want to hear you weigh trade-offs rather than reflexively favour the tool you know best.
Strong answer covers: qTest wins when you need a compliance-grade audit trail (electronic signatures, immutable history), are in the Tricentis ecosystem (Tosca integration is native), or manage QA across multiple teams with portfolio dashboards. Xray wins when the whole organisation already lives in Jira and you want defects and test cases in one system developers will actually open. Cost matters: Xray is often dramatically cheaper for teams under 50 testers.
You’re joining TeleNZ as a senior QA engineer. The team runs Selenium tests in GitHub Actions and tracks defects in Jira, but test cases live in a spreadsheet. How would you introduce qTest without disrupting the current CI pipeline?
What they’re really testing: Change management awareness and integration pragmatism — can you adopt enterprise tooling incrementally without blowing up what works?
Strong answer covers: Start by migrating test cases from the spreadsheet into qTest Manager first — no pipeline changes needed yet. Then wire qTest’s Automation Host to pull Selenium results from GitHub Actions via the REST API or the qTest-GitHub integration, so CI runs automatically update execution status. Only then consider retiring the spreadsheet. Frame it to the team as “your automation still runs the same way; qTest just shows you the results in a single dashboard instead of a Actions log.”
Your Playwright tests pass locally and in the staging pipeline, but qTest shows them as “Not Run” after each CI build. How do you diagnose this?
What they’re really testing: Systematic debugging discipline and familiarity with qTest’s automation result ingestion mechanics.
Strong answer covers: Check the qTest Automation Host logs first — it is a separate agent process and the most common failure point. Verify the test run payload format: qTest expects results mapped to specific test case IDs via the API or a JUnit/JSON report parser; if the Playwright reporter is not generating the right format, results silently go nowhere. Also confirm the API token used by the CI job has not expired and that the qTest project ID in the pipeline config matches the live project, not a stale clone from a template.
How would you structure a qTest project to support five squads releasing independently on different cadences, while still giving the QA manager a single release-readiness view?
What they’re really testing: Architecture thinking at scale — whether you understand qTest’s project and permission model well enough to design it, not just use it.
Strong answer covers: Use one qTest project per squad (or product domain) with module-level permissions so teams own their own test libraries. Connect all projects to a shared Insights dashboard using cross-project reports — that is where the QA manager gets the portfolio view. Use release cycles mapped to each squad’s sprint cadence rather than a single monolithic release; Insights can aggregate pass rates, defect density, and automation coverage across all of them into one release-readiness report. Name projects consistently (e.g. “SQ-Payments”, “SQ-Identity”) so filters in Insights are maintainable as headcount grows.