Qase Test Management: Modern Test Case Management for Agile Teams

TestRail has been the default test case management tool for over a decade. It works, it's mature, and nearly every QA engineer has used it. But it also shows its age: the interface is dense, the setup is complex, and the pricing model (per user, seat-based) is painful for small teams that need occasional access for developers and product managers.

Qase is what TestRail would look like if it were designed in 2020 rather than 2010. It's cleaner, faster, and built with modern agile workflows in mind. The free tier covers small teams completely, and the paid tiers are priced for startups, not enterprises. This guide covers Qase's core features and helps you decide whether it's the right fit for your team.

Projects and Test Suites

Qase organizes work around Projects (equivalent to TestRail's projects) and Suites (equivalent to sections). The main difference from TestRail: Qase doesn't have a separate "suite" layer on top of sections. Your project contains a suite tree directly.

Creating a project is a 30-second operation. Choose a project code (like APP or WEB) — this prefix appears in all issue references (e.g., APP-123).

The suite tree uses folders and can be nested as deeply as you need:

Authentication
  ├── Login Flow
  ├── Registration
  └── Password Reset
Dashboard
  ├── Overview
  └── Widgets
API
  ├── Authentication Endpoints
  └── Resource Endpoints
Mobile
  ├── iOS
  └── Android

Drag-and-drop reordering works reliably (this sounds basic, but TestRail's version requires edit mode and is clunky). Cases can be moved between suites without losing their history.

Test Case Versioning

This is Qase's standout feature that TestRail doesn't have. Every test case maintains a version history. When you edit a test case — changing steps, expected results, or preconditions — Qase saves the previous version. You can see what the test looked like at any point in time and restore previous versions.

Why this matters: you run a test case in sprint 40, it passes. In sprint 41, someone "improves" the test case by adding a step. In sprint 42, the step fails. Was it a regression in the product or a change in the test? With versioning, you can look at the exact test case that passed in sprint 40 and compare it to what ran in sprint 42.

Test execution reports in Qase link to the specific version of the test case that was executed. This creates a complete audit trail: who tested what, when, with what exact test steps.

Defect Tracking Integration

Qase integrates with Jira, GitHub Issues, Linear, GitLab, YouTrack, and others. The integration does more than just linking — it bidirectional syncs defect status.

Setting up Jira integration:

1. Go to Project Settings > Integrations > Jira
2. Enter your Jira URL and API credentials
3. Map Qase result statuses to Jira issue statuses

When you mark a test case as Failed in Qase, you can create a Jira issue directly from the result screen. The issue pre-populates with:

• Test case title
• Steps that failed
• Actual vs. expected results
• Screenshots (if attached)
• Link back to the Qase test run

When the Jira issue is resolved, Qase can automatically flag the linked test case for re-execution.

For GitHub Issues users, the integration is even lighter-weight. Link a repository, and failed tests create GitHub issues with Qase results embedded as comments.

Qase API for CI Integration

Qase's REST API covers the full test management lifecycle. The base URL is https://api.qase.io/v1/.

Authentication:

# All requests use the token header
curl -H "Token: YOUR_API_TOKEN" \
  "https://api.qase.io/v1/project"

Creating a test run:

curl -X POST \
  -H "Token: $QASE_TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.qase.io/v1/run/APP" \
  -d '{
    "title": "Automated: Sprint 42 - 2026-06-01",
    "description": "CI run from GitHub Actions #${{ github.run_number }}",
    "plan_id": 3,
    "milestone_id": 5,
    "cases": [1, 2, 3, 4, 5]
  }'

Response includes the id of the created run.

Posting results:

curl -X POST \
  -H "Token: $QASE_TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.qase.io/v1/result/APP/42" \
  -d '{
    "results": [
      {
        "case_id": 1,
        "status": "passed",
        "time_ms": 340,
        "comment": "Passed in 0.34s"
      },
      {
        "case_id": 2,
        "status": "failed",
        "time_ms": 1200,
        "comment": "Expected redirect to dashboard, got 403 error",
        "defect": true
      }
    ]
  }'

Status values in Qase: passed, failed, blocked, skipped, invalid.

Completing a run:

curl -X POST \
  -H "Token: $QASE_TOKEN" \
  "https://api.qase.io/v1/run/APP/42/complete"

Using the Qase Reporter Libraries

Qase maintains official reporters for popular test frameworks:

pytest:

pip install qase-pytest

# pytest.ini
[pytest]
qase_mode = testops
qase_testops_token = YOUR_API_TOKEN
qase_testops_project = APP
qase_testops_run_title = "Automated: %(date)s"

Mark test cases with the Qase ID:

import pytest

@pytest.mark.qase(1)
def test_login_valid():
    pass

@pytest.mark.qase(2)
def test_login_invalid():
    pass

Run tests and results automatically appear in Qase:

pytest tests/ --qase-mode=testops

Jest:

npm install --save-dev qase-jest

// jest.config.js
module.exports = {
  reporters: [
    "default",
    ["qase-jest", {
      token: process.env.QASE_TOKEN,
      projectCode: "APP",
      runTitle: "Automated Jest Run",
    }]
  ]
};

Playwright:

npm install --save-dev playwright-qase-reporter

The official reporters handle authentication, run creation, result posting, and run completion automatically. You only need to add case ID annotations.

Test Plans and Milestones

Qase's test plan model is simpler than TestRail's:

Test Plan — a saved configuration of test cases. Think of it as a named subset of your test suite: "Smoke Tests", "Payment Flow Tests", "Full Regression". Plans persist and can be reused across runs.

Milestone — a time-bounded release or sprint. Attach runs to milestones to track release readiness.

For agile teams, the typical setup:

1. Create a milestone per sprint: "Sprint 42 (May 26 — June 9)"
2. Create test plans for different run types: "Smoke", "New Feature Tests", "Regression"
3. When a sprint ends, create test runs from the relevant plans, attach them to the milestone
4. Execute and track in the milestone dashboard

The milestone dashboard shows total cases, pass rate, blocking issues, and time remaining. It's the single view you need for sprint retrospectives and release go/no-go decisions.

Reporting and Analytics

Qase's reporting is more visual than TestRail's by default:

Defect Report — total defects created from test failures, by severity, by sprint. Connects QA activity directly to defect velocity.

Test Run Report — detailed pass/fail breakdown with time-to-execute data. Shows which test cases take the most time — useful for identifying candidates for automation.

Custom Report — build reports by filtering on status, assignee, milestone, date range. Export to CSV or schedule email delivery.

Analytics Dashboard — team-level metrics: runs per week, pass rate trend, test case creation rate. Useful for QA managers tracking team productivity over time.

The analytics are more immediately useful out of the box than TestRail's, which requires more manual report configuration.

Qase vs. TestRail for Small and Mid-Sized Teams

The honest comparison for teams of 2-20 people:

Pricing: Qase's free tier supports unlimited test cases and 3 users. Paid plans start at $20/month for 3 users. TestRail starts at $38/month for 3 users and scales steeply with seat count. For a startup with occasional PM or developer access, Qase is significantly cheaper.

Onboarding: Qase takes 30 minutes to be productive with. TestRail takes a day. The simpler interface means new QA engineers don't need to learn the tool — they just use it.

Reporting: TestRail has more powerful and customizable reports for enterprise use cases. Qase's built-in analytics are better for day-to-day sprint tracking.

Test case versioning: Qase has it, TestRail doesn't. This is a genuine advantage for teams that iterate test cases frequently.

API: Both have comprehensive APIs. Qase's official framework reporters (pytest, Jest, Playwright) make CI integration faster than TestRail's, which typically requires custom scripting or third-party packages.

Jira integration: Both have it. Xray is still the better choice if you need deep bidirectional Jira integration. For simple defect linking, both Qase and TestRail are equivalent.

Scale: TestRail handles enterprise-scale test libraries (10,000+ cases) better than Qase. If you're a large organization with complex multi-product testing infrastructure, TestRail is the more battle-tested choice.

For teams from 1 to about 20 people working on a single product in an agile environment, Qase is the better starting point. You can always migrate if you outgrow it — test cases export cleanly to CSV. The time saved on setup and the cleaner interface compounds across every sprint.

Getting Started in 15 Minutes

1. Create account at qase.io (free tier, no credit card)
2. Create a project with your product code
3. Build your suite tree (top 3-5 feature areas)
4. Write 5-10 test cases for your most critical flows
5. Create a test run, execute the cases manually once
6. Connect your CI using the official reporter for your framework

The first manual run gives you the baseline. The CI integration makes every subsequent run automatic. After a sprint, you'll have meaningful data on pass rates and coverage without ever leaving your existing workflow.