qTest Test Cycles: Planning and Managing Test Execution at Scale

Test cycles in qTest are the mechanism for organizing and tracking test execution against a specific release, sprint, or milestone. A cycle groups test cases into a planned execution effort, tracks who runs what, and rolls up status to give you a real-time picture of where you are in testing. This guide covers how cycles work, how to structure them for different workflows, and how to use them to manage testing at scale.

What a Test Cycle Is

A test cycle is a container for a set of test runs — executions of specific test cases in a specific context (environment, build version, sprint). A test case in your repository is static; a test run inside a cycle is an instance of that test case tied to a particular execution effort.

Think of it this way:

• Test Case: "Verify user can reset password" (the specification)
• Test Run: "Execution of 'Verify user can reset password' against build 2.3.1 on Chrome/Windows" (the event)

The same test case can have multiple test runs across different cycles. The cycle tracks the outcome of each run without modifying the test case itself.

Creating a Test Cycle

1. In qTest Manager, navigate to Test Execution in your project
2. Click Create Cycle
3. Set the cycle properties:
   • Name: Sprint 24, Regression v2.3, UAT Round 1
   • Description: optional context for the cycle's purpose
   • Start Date / End Date: planned testing window
   • Build: which application build this cycle tests (freeform or from a build list)
   • Environment: the target environment (Staging, QA, Production)

The start and end dates are informational for tracking purposes — qTest doesn't enforce them, but they appear in reports and help visualize test schedule against deadlines.

Adding Test Cases to a Cycle

Manual Selection

1. Open the cycle → Add Test Cases
2. Browse the test case tree or search by name, ID, or status
3. Select test cases → Add to Cycle

From a Test Suite

If you've organized test cases into test suites (named collections), you can add an entire suite to a cycle at once. This is the most common approach for regression cycles where the suite doesn't change much run-to-run.

From a Saved Filter

Create a saved search/filter (e.g., "all test cases tagged 'smoke' and status 'ready'") and add the results to a cycle. Useful for building cycles dynamically based on test case attributes.

Via Import

Import test runs from CSV with columns for test case ID and optional pre-set execution results. Used for migrating results from external sources or bulk-populating a cycle from another tool.

Sub-Cycles: Structuring Complex Test Efforts

A cycle can contain sub-cycles, allowing you to organize execution by:

• Feature area: Login, Checkout, Admin
• Tester: each sub-cycle assigned to a team member
• Environment: Chrome, Firefox, mobile
• Test type: Smoke, Regression, Edge Cases

Creating sub-cycles:

1. Right-click a cycle → Create Sub-cycle
2. Name the sub-cycle
3. Move test runs between parent cycle and sub-cycles by dragging or using the "Move" action

Execution status rolls up: if all test runs in a sub-cycle pass, the sub-cycle shows as Passed. The parent cycle aggregates all sub-cycle statuses.

Assigning Test Cases to Testers

Within a cycle, each test run can be assigned to a specific tester:

1. Select one or more test runs in the cycle
2. Right-click → Assign to
3. Choose a team member

Testers see their assigned runs in the My Assignments view. They can filter their queue by cycle, status, or priority.

Bulk assignment: select all test runs in a sub-cycle → assign to one tester. For a cycle with 200 test cases split across 4 testers, create 4 sub-cycles, bulk-assign each to one person, and done.

Execution Statuses

Each test run in a cycle has one of these statuses:

When a tester marks a test run as Failed, they can immediately create a defect from that run — defect details are pre-populated with the test case name, failed step, and execution context.

Running Tests

Open a test run to start execution:

1. Click the test run → Execute
2. Step through the test case steps one by one
3. For each step: mark Passed, Failed, or Blocked, add notes, attach screenshots
4. Submit the execution

Submitting marks the run status and adds the result to cycle reporting. Runs can be re-executed — each re-execution creates a new execution record, preserving history.

Test execution view options:

• Standard view: step-by-step form, one step visible at a time
• List view: all steps on one screen, useful for manual testers who are already familiar with the test
• Quick pass/fail: for simple tests where you don't need step-level granularity

Tracking Cycle Progress

The cycle dashboard shows real-time status:

• Total test runs: how many test runs are in the cycle
• Execution progress: percentage of runs with a final status (Passed, Failed, Blocked, Skipped)
• Pass rate: passed / (passed + failed)
• Status breakdown: donut chart of status distribution
• Defects linked: count of defects raised in this cycle

The Burn-down view shows execution progress over time: how many tests remain Not Run each day. This helps identify if you're on track to complete testing by the cycle end date.

Configuration-Specific Cycles

For testing across multiple environments or configurations, qTest supports Configurations:

1. Define configurations: {Chrome + Windows}, {Firefox + Mac}, {Safari + iOS}
2. Attach configurations to a cycle
3. qTest creates a test run per test case per configuration automatically

A cycle with 100 test cases and 3 configurations creates 300 test runs — one for each test/config combination. Results are tracked separately per configuration, and the coverage report shows which configurations have full test coverage.

Release Testing with Multiple Cycles

A common pattern: multiple cycles feed into a release.

Release 3.0
├── Cycle: Sprint 23 (feature testing)
├── Cycle: Sprint 24 (feature testing)
├── Cycle: Integration Testing
└── Cycle: Regression v3.0

The release view aggregates across all cycles, showing overall pass rates and requirement coverage. You can see at a glance whether every user story linked to the release has passed test coverage across all cycles.

Automated Test Integration

If you run automated tests (Selenium, Cypress, Playwright, etc.), you can push results directly into qTest cycles via the qTest API or qTest's native integrations.

qTest Launch (included in qTest Manager) handles automated result ingestion:

1. Configure a qTest Launch agent on your CI server
2. After your test framework runs, Launch picks up the test results (JUnit XML, TestNG XML, Cucumber JSON)
3. Launch creates or updates test runs in the specified cycle with the automation results

This means your cycle shows both manual and automated results in one view — you don't need to maintain separate tracking for automated vs. manual execution.

Cycle Templates

For repeating cycles (sprint testing, weekly regression), create a cycle template:

1. Set up a cycle with the test cases and structure you want to repeat
2. Clone Cycle → select the source cycle
3. Adjust the dates and build number for the new cycle

The clone inherits all test case assignments, sub-cycle structure, and configuration settings. Test run statuses reset to Not Run. This is faster than rebuilding the cycle from scratch each sprint.

Common Workflow: Sprint Testing

A typical sprint testing cycle with qTest:

1. Sprint start: import Jira stories as requirements → create a sprint cycle → add test cases linked to sprint requirements → assign to testers
2. During sprint: testers execute assigned runs → defects logged in Jira automatically → developers fix → re-execute failed runs
3. End of sprint: requirements coverage report shows which stories have full test coverage → export for sprint review

The cycle end state gives you an audit trail: which tests were run, when, by whom, with what result, and what defects were found — without maintaining that record manually.