Build a Regression Plan
A project or increment can have multiple regression plans to organize testing activities. You can create different plans for core functionality testing, new features, and performance testing. Understanding how plans, suites, and test sets work together helps you structure effective regression testing.
Permission requirement: Building regression plans requires modify permissions on the project. Assigning owners requires ability to assign work to team members. Generating test sets from suites requires modify permissions and team assignment rights.
Who Builds Regression Plans
Plan construction supports comprehensive testing strategies:
- QA Managers structure regression plans with suites organized by functional area, testing type, or release cycle to support comprehensive coverage.
- Test Leads generate test sets from suites for specific environments and sprints, scheduling execution during sprint planning.
- Product Owners assign plan and suite owners to clarify testing responsibility and coordinate overall testing strategy.
- Scrum Masters organize multiple plans by functionality, testing type, or team to enable parallel testing and clear accountability.
Regression Plan Structure
A regression plan organizes testing into a three-level hierarchy:
Regression Plan: Top-level container that groups related testing activities
- Can have multiple suites
- Can be assigned an owner responsible for coordinating testing
- Example: "Q1 2024 Release Testing Plan"
Regression Suite: Template for a set of related tests within a plan
- Acts as a template for generating test sets
- Typically executed under multiple environments (e.g., Dev, QA, Production)
- Can be assigned an owner
- Example: "Login and Authentication Suite"
Regression Test: Individual test case assigned to a suite
- Defines what functionality to verify
- Gets converted to acceptance tests when test sets are generated
- Example: "Verify password reset flow"
Test Sets and Acceptance Tests
When you generate a test set from a regression suite, the system creates executable tests:
Test Set: Combination of a suite and a specific environment
- Represents actual testing activities performed during a sprint or iteration
- Can be scheduled and assigned to teams
- Example: "Login Suite - QA Environment - Sprint 12"
Acceptance Test: Executable form of a regression test
- Created automatically when you generate a test set
- Can be tracked and executed like other acceptance tests
- Links back to the original regression test
Build Your Plan
Follow this workflow to build an effective regression plan:
- Create the plan: Define the overall testing scope and assign an owner
- Add suites: Group related tests by functional area or testing strategy
- Assign tests: Add regression tests to each suite using tags and filters
- Generate test sets: Create executable test sets for specific environments and sprints
- Schedule execution: Assign test sets to teams during sprint planning
Assign Owners
You can assign owners at both the plan and suite levels to clarify responsibility:
- Plan owner: Coordinates overall testing strategy and progress
- Suite owner: Manages specific functional area testing and test case maintenance
Owners receive notifications about testing progress and can track completion in reports.
Organize Multiple Plans
Use multiple regression plans to organize testing by:
- Functionality: Core features, new features, edge cases
- Testing type: Functional testing, performance testing, security testing
- Release cycle: Monthly release plan, quarterly validation plan
- Team: Team A regression tests, Team B regression tests
Troubleshooting
Why can't I see the regression tests I assigned when I generate a test set?
Test sets only include regression tests that were assigned to the suite before generation. If you assigned tests after generating a test set, you must generate a new test set to include those tests. Existing test sets represent a snapshot of the suite at the time of generation and do not automatically update.
How do I avoid creating duplicate test sets for the same environment?
When generating test sets from a suite, use clear naming conventions that include environment and sprint (e.g., "Login Suite - QA - Sprint 12"). Before generating, check the Test Sets backlog to see if a test set already exists for that suite and environment combination. Duplicate test sets can create confusion during execution.
Why don't my regression tests appear in sprint burndown or velocity reports?
Regression tests themselves don't appear in reports—only the generated test sets do. After generating test sets from your regression suites, schedule those test sets into sprints. The test set estimates and To Do values then roll up into burndown and velocity calculations just like other backlog items.
Should I create separate regression plans for each increment or reuse one plan?
Both approaches work depending on your needs. Reuse one regression plan across increments if your test suites are stable and represent ongoing product functionality (e.g., "Core Features Suite"). Create increment-specific plans if testing scope changes significantly per increment or if you want to archive completed plans. Many teams use hybrid: stable core suites in one plan, increment-specific new feature suites in separate plans.