Choosing Between Planned and Execution Test Cycles in qTest Manager

Decision: When to Use Planned vs Execution Test Cycles

\n

In qTest Manager the choice between a Planned Test Cycle and an Execution Test Cycle determines how test effort is measured and reported. Using the wrong type mixes baseline scope with live results, causing fragmented dashboards and inaccurate quality‑gate calculations.

\n

Takeaway: Define your test scope in a Planned Cycle, then track results against a separate Execution Cycle that is tied to a specific build or environment.

\n\n

Comparison Table

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Aspect	Planned Test Cycle	Execution Test Cycle
Primary purpose	Define what tests belong to a release or sprint; no execution status required	Capture Pass/Fail/Blocked results for a specific build
Typical association	Release or Sprint (general target)	Build version, environment, or test run identifier
Key metric	Test coverage / total test count	Pass/Fail/Blocked rate (numerator for progress)
Reporting role	Provides the denominator for progress calculations	Supplies the actual results that drive the progress bar

\n\n

Trade‑offs and Constraints

\n

Administrative Overhead vs. Data Granularity

\n

Planned cycles keep the test‑suite mapping stable during design. Creating a new Planned cycle for every minor build adds unnecessary overhead and makes it hard to see the overall scope. Execution cycles, on the other hand, must be granular enough to isolate results per build; reusing a single Execution cycle for multiple builds hides which version introduced a defect.

\n

Reporting Integrity

\n

qTest Insights aggregates data from cycles marked as Execution. If results are logged in a Planned cycle, they are excluded from progress reports, giving a false impression of zero advancement.

\n

Audit‑Trail Risks

\n

Changing a cycle’s type or moving test runs after execution has started can alter timestamps or user stamps in some qTest versions, complicating compliance audits.

\n\n

Implementation Workflow

\n

These steps assume you have Administrator or Test Lead permissions in the project.

\n

\n
1. Create the Planned Cycle\n
   \n
   1. Navigate to Test Execution → Test Cycles.
   \n
   2. Click Add Test Cycle.
   \n
   3. Select the target Release.
   \n
   4. Enter a name such as [Planned] Sprint 22 Baseline.
   \n
   5. Leave the Cycle Type as Planned (or explicitly set it if your version requires it).
   \n
   6. Associate the Test Suites that contain all test cases for the release.
   \n
   7. Save.
   \n
   \n
\n
2. Create the Execution Cycle for a Build\n
   \n
   1. Still in Test Execution → Test Cycles, click Add Test Cycle.
   \n
   2. Select the same Release.
   \n
   3. Enter a name like [Exec] Build 3.4.1‑QA.
   \n
   4. Set Cycle Type to Execution.
   \n
   5. Optionally add the Build number in the description field.
   \n
   6. Save.
   \n
   \n
\n
3. Copy Test Runs from Planned to Execution\n
   \n
   1. Open the Planned Cycle, select all test runs (checkbox at top).
   \n
   2. Choose Copy (or Move if you prefer not to keep the original).
   \n
   3. Destination: the newly created Execution Cycle.
   \n
   4. Confirm.
   \n
   \n
\n
4. Execute and Log Results\n
   \n
   1. Assign testers to the Execution Cycle.
   \n
   2. Update each test run status to Pass, Fail, or Blocked as testing proceeds.
   \n
   3. Optionally attach logs or defects.
   \n
   \n
\n

\n\n

Validation: Confirming Correct Separation

\n

After executing a few test runs, verify that reporting reflects only the Execution Cycle.

\n

\n
• Go to qTest Insights → Reports → Test Execution Progress.
\n
• Select the Release.
\n
• The report should show:
  \n
  \n
  • Total Tests equal to the number of test runs in the Planned Cycle.
  \n
  • Passed/Failed/Blocked counts derived solely from the Execution Cycle.
  \n
  \n
• If the progress bar does not move despite marked Passed results, open the Execution Cycle and confirm that those runs reside there, not in the Planned Cycle.
\n

\n\n

Rollback Procedure (if runs were mistakenly left in a Planned Cycle)

\n

Moving runs after execution has begun may reset the Execution Start Date to the time of the move. Export a CSV of the original results first if an immutable audit trail is required.

\n

\n
1. Create the correct Execution Cycle (if it does not already exist).
\n
2. Open the Planned Cycle, select the misplaced test runs.
\n
3. Choose Move to transfer them to the Execution Cycle.
\n
4. Verify that the runs now appear under the Execution Cycle with updated timestamps.
\n
5. Re‑run the validation step in qTest Insights to confirm reporting is restored.
\n