TestKase Docs
Core TestingTest Plans

Test Plans

Learn how to create test plans, organize multi-cycle testing efforts, and track release-level quality.

Overview

A test plan is the highest-level organizational container in TestKase. While a test case defines what to test and a test cycle defines when and who tests it, a test plan defines why and how an entire body of testing fits together. Plans let you group multiple test cycles and standalone test cases under a single umbrella, giving stakeholders a consolidated view of testing scope, ownership, and progress for a release, sprint, milestone, or any cross-cutting initiative.

In professional test management, test plans serve as the strategic layer above individual execution runs. They answer questions like "Are we ready to ship v3.0?" by aggregating pass rates across the regression cycle, the smoke-test cycle, the UAT cycle, and any ad-hoc cases that do not belong to a specific cycle. Without a plan, teams must manually compile data from separate cycles to form a release-readiness picture. With a plan, that picture is always one click away.

When to Use a Test Plan

  • Release verification — Group all cycles and cases that must pass before a release ships (e.g., "v3.0 Release Plan" containing a Regression cycle, a Performance cycle, and a UAT cycle).
  • Sprint-level planning — Wrap the sprint's regression cycle plus any exploratory or ad-hoc test cases into a single plan for sprint-review reporting.
  • Cross-team initiatives — When multiple teams each own separate cycles (e.g., Backend API, Frontend UI, Mobile), a plan consolidates their results into one dashboard.
  • Compliance and audit — Regulated industries often require a documented test plan that references all executed tests. A TestKase plan provides that traceability.

Unified planning

Group multiple cycles and standalone cases under a single strategic container

Flexible linking

Link and unlink cycles and test cases at any time without affecting their data

Aggregated progress

See combined execution metrics across every linked cycle and case in real time

Clone for reuse

Duplicate a plan for new releases or sprints, preserving its structure instantly

Cross-team visibility

Share one plan across teams so everyone sees the same progress dashboard

Hierarchical organization

Plans sit above cycles, giving you a three-tier hierarchy: Plan > Cycle > Case

Audit trail

Every plan change is recorded — linking, unlinking, edits, and execution updates

Release readiness

Use aggregated pass rates to make data-driven go/no-go release decisions

Test plans are optional. If your testing workflow involves only a single cycle at a time, you can work with test cycles directly. Plans become valuable when you need to coordinate multiple cycles or track cross-cutting test coverage.

Create a Test Plan

Creating a test plan is the first step toward organizing a coordinated testing effort. A plan captures high-level metadata about the testing scope and serves as the container you will populate with cycles and cases.

Step-by-Step

  1. Navigate to the Test Plans tab in your project. You can find this in the project sidebar alongside Test Cases and Test Cycles.
  2. Click the Create Plan button in the toolbar. The plan creation dialog opens.
  3. Enter a plan name. Choose a descriptive name that communicates scope and context at a glance (see naming tips below).
  4. Optionally add a description. Use the description to document the plan's purpose, scope boundaries, entry/exit criteria, or links to related requirements and design documents.
  5. Click Create to save the plan. The plan is created in an empty state, ready for you to link cycles and test cases.

Plan Fields

FieldRequiredDescriptionTips
NameYesA descriptive name for the planInclude the release/sprint identifier and scope. Example: "v3.0 Release — Full Regression Plan"
DescriptionNoFree-text description of the plan scope, goals, and contextDocument entry/exit criteria, list the teams involved, and reference requirement IDs or Jira epics

Naming convention: Use a consistent format across plans so they sort naturally in the list. A good pattern is [Version/Sprint] — [Scope] Plan. Examples: v2.5 — Release Verification Plan, Sprint 14 — Regression Plan, Q1 2026 — Security Audit Plan.

You can edit the plan name and description at any time after creation. Changes are recorded in the plan history so there is always a record of what was modified and by whom.

Plan Structure

A test plan organizes testing activities in a clear hierarchy. Understanding this structure helps you design plans that are easy to navigate and produce meaningful aggregated metrics.

Three-Tier Hierarchy

TestKase uses a three-tier hierarchy for test management:

Test Plan (Strategic container — groups cycles and standalone cases)
├── Linked Test Cycles
│   └── Test cases within each cycle (managed in the cycle, reflected in the plan)
└── Standalone Test Cases (individual cases linked directly to the plan, outside any cycle)

Example Plan Structure

Consider a release plan for version 3.0 of a web application. The plan might be structured as follows:

ItemTypeContentsOwner
v3.0 Core RegressionLinked Cycle85 test cases covering login, dashboard, settings, API endpointsQA Team Lead
v3.0 New Feature — PaymentsLinked Cycle32 test cases for the new payment flowFeature QA
v3.0 Performance SuiteLinked Cycle12 load and stress test casesPerformance Engineer
v3.0 UATLinked Cycle20 user-acceptance test casesProduct Owner
Accessibility spot-check — checkoutStandalone CaseManual accessibility check of checkout flowQA Engineer
Database migration verificationStandalone CaseVerify data integrity after schema migrationBackend Lead
Third-party integration smoke testStandalone CaseConfirm Stripe and SendGrid still workQA Engineer

This structure gives the release manager a single view of all 152 test cases (149 from cycles + 3 standalone) with aggregated progress tracking across every team and testing category.

Keep plans focused on a clear scope. A release plan should contain all cycles and cases relevant to that release. Avoid creating plans that mix unrelated testing efforts, as the aggregated metrics would be misleading.

Next Steps