Plan Management
Clone plans for reuse, review the audit trail, and understand when to use plans versus cycles.
Clone a Plan
Cloning a test plan creates a new plan with the same structure — the same linked cycles and standalone test cases — without duplicating the underlying data. This is the fastest way to set up a new plan for a recurring testing effort.
How to Clone
- Open the plan you want to clone, or find it in the plan list.
- Click Clone from the plan actions menu (three-dot icon).
- A new plan is created immediately with "(Clone)" appended to the name. The new plan links the same cycles and standalone test cases as the original.
- Rename the cloned plan and update its description to reflect the new context (e.g., change "v3.0 Release Plan (Clone)" to "v3.1 Release Plan").
What Gets Cloned
| Attribute | Cloned? | Details |
|---|---|---|
| Plan name | Yes | Copied with "(Clone)" appended. Rename it to reflect the new scope. |
| Description | Yes | Copied as-is. Update it for the new plan's goals and criteria. |
| Linked cycles | Yes | The same cycles are linked to the new plan. The cycles are not duplicated. |
| Standalone test cases | Yes | The same test cases are linked to the new plan. |
| Execution statuses | No | Execution data belongs to the cycles and cases, not the plan. The cloned plan reflects current live data from linked items. |
| Plan history | No | The new plan starts with a fresh history. The original plan's history is unaffected. |
Common Cloning Use Cases
- New release: Clone the previous release's plan, then add or remove cycles to reflect the new release's scope. For example, clone "v3.0 Release Plan" and update it to "v3.1 Release Plan," swapping out the old feature cycle for a new one.
- New sprint: Clone the last sprint's plan to preserve the regression cycle link. Add the new sprint's feature cycle and remove any one-off cycles from the previous sprint.
- Template plans: Create a "template" plan with your standard cycle structure (regression, smoke, UAT) and clone it at the start of each release. This ensures consistency across releases.
- Parallel environments: Clone a plan for a different deployment environment (e.g., clone the Staging plan as a starting point for the Production plan), then adjust the linked cycles to point to environment-specific cycles.
Remember that cloning a plan links the same existing cycles to the new plan. It does not create copies of the cycles. If you need fresh cycles with reset execution statuses, clone the cycles first (from the Test Cycles tab), then link the new cycles to the cloned plan.
Plan History
Every test plan maintains a comprehensive audit trail of all changes. The history tab records every action with a timestamp and the user who performed it, providing full traceability for compliance and review purposes.
Tracked Changes
The following events are recorded in the plan history:
- Plan created — When the plan was created and by whom.
- Plan metadata updated — Changes to the plan name or description, showing the old and new values.
- Cycle linked — When a test cycle was linked to the plan, including the cycle's name and ID.
- Cycle unlinked — When a test cycle was removed from the plan.
- Test case linked — When a standalone test case was linked directly to the plan.
- Test case unlinked — When a standalone test case was removed from the plan.
- Execution status changes — Status updates for standalone test cases executed within the plan context.
- Plan cloned — When the plan was used as the source for a clone operation, with a reference to the new plan.
Compliance tip: In regulated environments (healthcare, finance, defense), the plan history serves as auditable evidence that testing was planned, executed, and tracked according to process. Export or reference the plan history in your compliance documentation.
Execution history for cycle-based test cases is tracked in the cycle's own history, not the plan's history. To see the full execution audit trail for a cycle-based case, navigate to the cycle and check its history tab.
Plan vs. Cycle
Understanding when to use a test plan versus a test cycle is key to effective test management. They serve different purposes and work best at different levels of your testing strategy.
Detailed Comparison
| Aspect | Test Plan | Test Cycle |
|---|---|---|
| Purpose | Strategic container for organizing a testing initiative (release, sprint, milestone) | Operational unit for executing a specific set of test cases |
| Contains | Multiple test cycles + standalone test cases | Individual test cases with execution statuses |
| Hierarchy level | Top level — sits above cycles | Middle level — sits below plans, above cases |
| Execution | Can execute standalone cases directly; cycle cases are executed through their cycle | Primary execution interface — all cases are executed here |
| Progress tracking | Aggregated across all linked cycles and standalone cases | Individual — tracks its own set of test cases only |
| Tester assignment | Assigns testers to standalone cases; cycle assignments are managed in the cycle | Assigns testers to individual test cases within the cycle |
| Cloning | Clones the plan structure (linked cycles and cases); does not clone cycles | Clones the cycle with all test cases; resets execution statuses |
| Multi-membership | A cycle can belong to multiple plans | A test case can belong to multiple cycles |
| Typical scope | Release-wide, sprint-wide, or initiative-wide | Single test run (regression pass, smoke test, feature validation) |
| Best for | Release readiness decisions, cross-team coordination, compliance reporting | Day-to-day test execution, tester workload management, CI/CD automation |
When to Use Each
Use a test cycle when you have a defined set of test cases to execute as a single unit of work. Cycles are your day-to-day execution tool. Examples: "Sprint 14 Regression," "Payment Feature Smoke Test," "Staging Environment Sanity Check."
Use a test plan when you need to coordinate multiple cycles and see a consolidated view of testing progress. Plans are your strategic coordination tool. Examples: "v3.0 Release Verification Plan," "Q1 2026 Quality Dashboard," "Security Audit Plan."
Use both together for the most effective workflow: create cycles for each testing activity, then link them into a plan for aggregated visibility. This gives testers a focused execution interface (the cycle) while giving managers and stakeholders a strategic overview (the plan).
A good rule of thumb: if you are tracking one round of test execution, use a cycle. If you are tracking an entire testing effort that spans multiple rounds, use a plan.