Qase TMS: Modern Test Management for Agile Teams

Test management tooling sits in an awkward spot for most engineering teams. It has to serve QA engineers who live in it all day, developers who open it only to triage a failing run, and product managers who want a dashboard that tells them whether the release is safe. Tools built in the 2000s — TestRail, TestLink, HP ALM — were designed for waterfall projects with long release cycles and dedicated QA departments. They assume you have weeks to write test plans and dedicated testers who do nothing else.

Agile teams don't work that way. Sprints are two weeks. Tests need to be written, updated, and executed in parallel with development. Defects need to flow straight into the same backlog everyone else is looking at. And engineers need an API so they can wire test results into CI without a manual upload step.

Qase was built with that model in mind. This post covers the architecture, key features, integrations, pricing, and where it beats — or loses to — Zephyr Scale and Xray for agile workflows.

What Qase Actually Is

Qase is a cloud-native test management platform launched in 2019. It's SaaS-first, with no on-premise option in the standard tier. The underlying model is straightforward: you organize tests into projects, tests within projects live in suites, and you execute them in test runs tied to a test plan. Defects found during runs link to external issue trackers.

That hierarchy — project → suite → test case → test run — is standard across all TMS products. What differentiates Qase is how it surfaces that hierarchy in the UI, how its API is structured, and how agile-friendly its workflow model is.

Core Data Model

Projects

Every object in Qase lives under a project. Projects have a unique code (e.g., MYAPP) used in all API endpoints and in generated test case IDs (MYAPP-42). Projects are isolated — there's no cross-project test case reuse in the base plan. Enterprise tier adds shared steps and cross-project reporting.

Test Suites

Suites are folders. They nest arbitrarily deep. A typical structure for a web app:

Auth
  ├── Login
  │     ├── Valid credentials
  │     ├── Invalid password
  │     └── Account lockout after 5 failures
  └── OAuth
        ├── Google sign-in
        └── GitHub sign-in
Checkout
  ├── Cart management
  └── Payment processing

Suites have no behavior of their own — they're purely organizational. You can bulk-move test cases between suites, clone suites, and filter runs by suite.

Test Cases

Test cases are where the work lives. Each case has:

• Title — plain text, searchable
• Description — Markdown, rendered in the UI
• Pre-conditions — what state must exist before the test runs
• Steps — numbered list of action/expected-result pairs
• Post-conditions — cleanup or assertions to make after the test
• Priority — Critical / High / Medium / Low / Not Set
• Type — Functional, Performance, Regression, Smoke, Security, Acceptance, Compatibility, Exploratory, Other
• Status — Actual / Draft / Deprecated
• Automation status — Not Automated / To Be Automated / Automated
• Tags — free-form
• Custom fields — configured at the project level

The step model deserves attention. Each step has an "Action" field and an "Expected result" field. This is the right model for manual testers writing in natural language. Steps can be imported from shared step libraries (paid feature) so common flows like login aren't duplicated across hundreds of tests.

Qase also supports parameterized test cases — you define a dataset and the case runs once per row. Useful for login tests across multiple account types, or form validation across a list of invalid inputs.

Test Plans

A test plan is a static snapshot: "here are the cases we intend to run for this milestone." Plans reference test cases by ID. You can filter by suite, tag, priority, or custom field values when building a plan.

Plans are optional — you can start a test run from an ad-hoc case selection without a plan. For sprint-based work, creating a plan per sprint or per release gives you a clean audit trail.

Test Runs

A test run is an execution instance of a plan (or ad-hoc case set). When you start a run:

1. Qase creates a run record with status In Progress
2. Each case in the run gets an individual result slot
3. Testers pick up cases, mark them Passed / Failed / Blocked / Skipped / Invalid
4. Failed cases automatically prompt for a defect link or new defect creation
5. The run closes when all cases have a result, or you close it manually

Runs have an environment field (staging, production, etc.) and a milestone link. Time tracking is per-result — Qase records how long each tester spent on each case.

The run dashboard shows a live donut chart of pass/fail/blocked/untested counts. This is the view PMs care about — it answers "are we done?" at a glance.

Defects

Defects in Qase are either internal (Qase-native) or external (pushed to Jira, GitHub Issues, YouTrack, etc.). When a tester marks a result as Failed, they can:

• Create a new defect (internal or external)
• Link an existing defect by ID

Internal defects have status, severity, and assignee fields. They're useful if you're not using an external tracker, but most teams immediately connect Jira or GitHub and push everything there.

Integrations

Jira

The Jira integration is bidirectional. Setup requires installing the Qase app from the Atlassian Marketplace and authorizing it against your Jira instance (cloud or server). Once connected:

• Defect push: Failing test results create Jira issues automatically. The Jira issue ID is stored on the Qase defect record.
• Requirement linking: Qase test cases can link to Jira issues (stories, epics). This lets you answer "which test cases cover story PROJ-123?"
• Status sync: When a Jira issue moves to Done/Resolved, Qase can optionally mark the linked defect as resolved.

The requirement coverage view is genuinely useful for sprint reviews. You can pull up a Jira epic and see which Qase cases reference it, plus their last pass/fail status.

GitHub

Two integration modes:

1. Defect push: Failed results create GitHub Issues. Labels, assignee, and milestone are configurable.
2. CI reporter: The Qase GitHub Action (qase-io/gh-action) submits test run results from CI pipelines without manual uploads.

Slack

Slack notifications fire on run start, run completion, and (optionally) individual failures. The payload includes run name, project, pass rate, and a direct link to the run. Useful for async teams where QA isn't watching the dashboard all day.

REST API

Qase's API is where it earns serious points for engineering teams. The v2 API is documented at https://developers.qase.io/reference and covers every object in the system.

Key endpoints:

GET  /v1/case/{code}                     # List test cases
POST /v1/case/{code}                     # Create test case
GET  /v1/run/{code}                      # List test runs
POST /v1/run/{code}                      # Create test run
POST /v1/result/{code}/{id}              # Submit result for a case in a run
GET  /v1/defect/{code}                   # List defects

Authentication is an API token passed as the Token header. Tokens are per-user, generated in account settings.

The typical CI integration pattern:

# Start a run at the beginning of the test suite
RUN_ID=$(curl -s -X POST "https://api.qase.io/v1/run/MYAPP" \
  -H "Token: $QASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"CI Run #'"$BUILD_NUMBER"'","cases":[1,2,3,4,5]}' \
  | jq '.result.id')

# Submit results per case
curl -s -X POST "https://api.qase.io/v1/result/MYAPP/$RUN_ID" \
  -H "Token: $QASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"case_id":1,"status":"passed","time_ms":1240}'

# Close the run
curl -s -X POST "https://api.qase.io/v1/run/MYAPP/$RUN_ID/complete" \
  -H "Token: $QASE_API_KEY"

Qase also publishes reporter libraries for Jest, Pytest, Playwright, Cypress, JUnit, TestNG, and others. The reporters hook into test framework lifecycles and submit results automatically — no manual curl calls in your pipeline.

Webhooks

Qase can fire outbound webhooks on run creation, run completion, result submission, and defect creation. Payloads are JSON. Useful for custom dashboards or triggering downstream workflows without polling the API.

Reporting

Qase's reporting is basic compared to enterprise tools, but covers the main use cases:

• Run reports: Pass/fail/blocked by case, tester, suite, and environment. Exportable to CSV or PDF.
• Trend charts: Pass rates over time across runs. Useful for spotting regression trends.
• Defect analytics: Open defect count by priority and severity.
• Coverage heatmap: Which suites have the most failures, surfaced as a visual grid.

The analytics tier (paid add-on on lower plans) unlocks deeper trend data and cross-project aggregation.

Real Workflow Walkthrough: Two-Week Sprint

Here's what a sprint cycle looks like with Qase in practice.

Sprint planning (Day 1)

A QA engineer creates a test plan called "Sprint 42." They pull in all cases tagged sprint-42 plus any regression cases for touched modules. Plan sits at 63 cases total.

Development phase (Days 1–8)

As developers build features, the QA engineer writes new test cases directly in Qase against the relevant Jira stories. Qase's Jira link means the engineer can open any Jira story and see linked test cases from the sidebar (requires the Jira app). New cases are marked Draft until reviewed.

Exploratory testing (Days 7–9)

Qase has a built-in exploratory testing session timer. The tester sets a mission ("explore checkout flow on mobile"), sets a time box (45 minutes), and records notes and bugs inline. Session results attach to the run as a separate result type. This is a clean way to capture unstructured testing without losing it in Slack messages.

Regression run (Day 9–10)

The QA engineer starts the test run against the staging environment. The Slack integration posts a message to #qa-releases: "Sprint 42 regression started — 63 cases." Team members assigned to cases get email notifications.

As results come in, failed cases auto-prompt for defect creation. The tester clicks "Create Jira issue" — Qase pre-fills the issue with the test case title, steps, expected result, and actual result. The Jira issue appears in the sprint board.

Release sign-off (Day 10)

Run completes: 58 passed, 3 failed, 2 blocked. The PM opens the run dashboard link from Slack, sees the donut chart, and reads the three failures. Two are minor — the third is critical. Release decision is made in 5 minutes.

Qase vs Zephyr Scale vs Xray

Zephyr Scale (formerly SmartBear)

Zephyr Scale is a Jira Cloud app. It lives entirely inside Jira — no separate URL, no separate login. Test cases are Jira issue types. This is its biggest strength for teams already inside Jira: zero context switching, test cases appear in search, dashboards, and Jira's standard reporting.

The weakness: it inherits Jira's sluggishness. Creating 50 test cases in Zephyr Scale is noticeably slower than in Qase. The UI is heavily Jira-styled — functional but not optimized for bulk test authoring. API is solid (Jira REST + Zephyr's own endpoints).

For agile teams deeply embedded in Jira who don't want another SaaS tool to manage, Zephyr Scale is the natural choice. For teams who want a faster, purpose-built test authoring experience, it feels constrained.

Best for: Jira-native teams, large enterprises with Jira Server/Data Center already standardized.

Xray

Xray is also a Jira app (cloud and server). Its differentiator is Gherkin/BDD support — test cases can be written as Cucumber .feature files and synced between Jira and the filesystem. If your team writes BDD specs and uses Cucumber, Xray's native .feature file handling is unmatched.

Xray's test plan and coverage models are more complex than Qase's. It introduces "test sets," "test environments," and "test executions" as separate Jira issue types, which gives more granularity but adds cognitive overhead. Onboarding a new team member takes longer.

Best for: BDD/Cucumber shops, teams needing tight Jira issue-type integration for compliance.

Qase

Qase's strengths: purpose-built UI (fast to author tests), clean REST API, good reporter ecosystem, and straightforward pricing. Its weaknesses: weaker native Jira embedding (you're always switching between tools), fewer advanced reporting options on lower tiers, and no on-prem option.

Best for: Agile teams that aren't Jira-native, startups, teams prioritizing API-first workflow, QA teams who want a dedicated tool rather than a Jira plugin.

Decision matrix

Pricing

Qase pricing (as of 2025):

• Free: Up to 3 users, unlimited projects, basic features
• Startup: $20/user/month — full feature set, up to 100 users
• Business: $35/user/month — advanced analytics, shared steps, SSO
• Enterprise: Custom — on-demand support, custom data retention, audit logs

The free tier is genuinely usable for small teams. Three users covers a common split of one QA lead and two developers who need read/write access to the test suite.

Compare to Zephyr Scale: starts at $10/user/month with a Jira Cloud license, so the raw number looks lower — but Jira itself costs $8.15+/user/month, making total cost comparable.

Xray Cloud: from $10/user/month, with Jira license cost on top.

Limitations to Know Before Committing

No on-premise. If you're in a regulated industry with data residency requirements, Qase is not an option. Zephyr Data Center or Xray Server cover this.

Cross-project limitations on lower tiers. Shared step libraries and cross-project reporting are Business/Enterprise features. If you have multiple teams working across many projects and need consolidated reporting, budget accordingly.

Test case review workflow is basic. There's no formal review/approval workflow with comments and sign-offs. If your QA process requires sign-off before a test case is "approved," you'll work around this with status fields and naming conventions.

Import tooling. Qase's CSV importer works but requires manual field mapping. Migrating from TestRail or TestLink is straightforward if your data is clean; messy hierarchies require manual cleanup.

Summary

Qase hits the right balance for most agile teams: fast UI for test authoring, a clean REST API for CI integration, solid Jira connectivity without requiring you to live in Jira, and transparent pricing. It's not the right tool if you need on-prem hosting, deep BDD integration, or are already standardized on Jira Data Center.

The free tier is worth spinning up for evaluation — three users and unlimited projects is enough to run a real sprint cycle and see whether the workflow fits.

For teams already using a TMS like Qase to track what to test and which runs passed, HelpMeTest fills the execution gap: AI-powered test runs written in plain English, no code required, at usage-based pricing of $0.003 per test run — a straightforward complement for anything Qase tracks but doesn't run automatically.