Execution & Progress Tracking

Assign & Execute

Test plans provide a unified interface for assigning testers and executing test cases. Depending on whether a case belongs to a linked cycle or is a standalone case, the assignment and execution workflow differs slightly.

Assigning Testers Within a Plan

For standalone test cases (linked directly to the plan):

1. In the plan view, find the standalone test case in the table.
2. Click the Assignee dropdown on that row.
3. Select a team member from the list of project members.
4. The assignment is saved immediately.

For cycle-based test cases:

Test cases that belong to linked cycles retain their assignments from the cycle. You can view these assignments in the plan, but to change them, navigate to the cycle itself. This ensures that cycle assignments remain the source of truth and are not inadvertently overridden from the plan level.

Executing Tests from the Plan View

From the plan view, you can execute any test case — both standalone cases and cases from linked cycles:

1. Find the test case in the plan's test case table. Cases are grouped by their source (the cycle they belong to, or "Standalone" for directly linked cases).
2. Click the Execute button (play icon) on the test case row. This opens the standard execution interface with test steps, status controls, comments, and defect linking.
3. Work through the test steps, verify expected results, and set the overall execution status (Pass, Fail, Blocked, or Not Executed).
4. Add execution comments or link defects as needed. 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 and standalone test cases:

• Green — Total passed test cases
• Red — Total failed test cases
• Yellow — 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 with a high pass rate.

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 a 95% pass rate.
• 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.

The pass rate is a separate metric:

Pass Rate = Passed / (Passed + Failed + Blocked) x 100%

Together, these two metrics tell the full story: completion tells you how much testing is done, and pass rate tells you how well the software is performing.

Using Progress for Release Decisions

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

• High completion, high pass rate — 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 rate — Testing is thorough but many tests are failing. Investigate critical failures, prioritize fixes, and plan a re-test cycle.
• Low completion — Testing is incomplete regardless of pass rate. 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.