Execution & Progress Tracking

Assign & Execute

A test plan brings together the test cases from its linked cycles. Because every case belongs to a cycle (the hierarchy is strictly Plan → Cycle → Case), assignment and execution always happen against the cycle — and the results roll straight back up into the plan's aggregated progress.

A plan has four tabs: Test Cycles, Execute, Details and History.

Assigning Testers

Assignment is done in the cycle, not on a per-row dropdown:

1. Open the cycle — from the plan's Test Cycles tab, or from the Test Cycles section of the project.
2. Go to the cycle's Test Cases tab and tick the test cases you want to assign.
3. Click Assignees and choose a team member.

There is one underlying assignment per case per cycle, so the assignment shows up everywhere that cycle appears, including every plan that links it. In the plan's views the assignee is shown as read-only text.

Executing Tests from the Plan

1. Open the plan and go to its Execute tab.
2. Pick a linked cycle from the cycle selector at the top. The plan opens the same execution interface as the cycle's own Execute page — test steps, the status control, the actual-result field and the read-only Defects ID list.
3. Work through the test steps, verify expected results, and set the execution status (Pass, Fail, Blocked, or Not Executed).
4. Record the actual result. Defects can be neither created nor linked from the execution interface — link them on the test case, as described in Linking a defect to a failed test. See the Test Cycles documentation for details on the execution interface.

Execution Status Reference

Execution Synchronization

Execution statuses are always synchronized between a plan and its linked cycles:

• Execute in the plan, see it in the cycle: If you mark a cycle-based case as Pass from the plan view, that status update is immediately reflected in the cycle itself.
• Execute in the cycle, see it in the plan: If a tester marks a case from within the cycle (not through the plan), the plan's aggregated progress updates in real time.
• No conflicts: Because there is only one underlying execution record per test case per cycle, updates from either view are always consistent.

Track Progress

One of the most powerful features of test plans is the aggregated progress dashboard. Instead of checking each cycle individually, the plan view consolidates all execution data into a single set of metrics.

Aggregated Progress Bar

At the top of the plan view, a color-coded progress bar shows the combined execution status across all linked cycles:

• Teal — Total passed test cases
• Red — Total failed test cases
• Blue — Total blocked test cases
• Gray — Total not-executed test cases

The bar provides an immediate visual indicator of testing health. A plan where the green segment dominates and the gray segment is negligible tells you that testing is nearly complete and mostly passing.

Per-Cycle Progress

Below the aggregated bar, each linked cycle shows its own individual progress bar and metrics. This lets you identify which cycles are on track and which are falling behind. For example:

• The Regression cycle might be at 92% completion with only a couple of failures.
• The UAT cycle might be at only 40% completion, indicating it needs attention.
• The Performance cycle might show 100% completion but with 2 failures that need investigation.

Completion Percentage Calculation

The plan's overall completion percentage is calculated as:

Completion = (Passed + Failed + Blocked) / Total Test Cases x 100%

In other words, completion measures how many test cases have been executed (regardless of outcome) versus how many remain at "Not Executed." A plan is 100% complete when every test case has been executed, even if some failed or were blocked.

A plan does not display a pass rate of its own — it shows status counts and the completion percentage. Pass percentages come from the Reports tab, where:

Pass % = Passed / Total Test Cases x 100

Blocked and not-executed cases are in the denominator, so a partly executed plan shows a low Pass % even when everything that ran passed. Read the two together: completion tells you how much testing is done, and Pass % is only meaningful once completion is high.

Using Progress for Release Decisions

When using a test plan to inform go/no-go release decisions, consider these guidelines:

• High completion, high Pass % — Testing is thorough and the software is performing well. Review any failures to confirm they are known or low-severity issues.
• High completion, low Pass % — Testing is thorough but many tests are failing. Investigate critical failures, prioritize fixes, and plan a re-test cycle.
• Low completion — Testing is incomplete, and Pass % is not yet meaningful because the not-executed cases are counted against it. Identify blockers, allocate more resources, or extend the timeline before making release decisions.
• Many blocked cases — Suggests environmental or dependency problems. Resolve blockers before concluding anything about software quality.