Change-based regression test scope workbook

Regression scope starts with changed requirements and their effects, not the number of modified files. Record the change identifier and reason, the requirement versions before and after it, and the target build and test versions. Establish whether the change only alters visible wording or changes permissions or the interpretation of data. If several changes ship together, connect their identifiers and the boundaries they affect in common. Record deadlines and environment constraints without treating them as evidence of low risk.

The workbook produces a selected test list and reasons for exclusions. Completing it does not mean tests ran or a release was approved. The regression scope insight explains selection by change risk. This material applies that reasoning through a change brief, impact candidates, scope decisions, execution and exclusion records, and a handover sheet.

When multiple screens and APIs share a permission policy, or several systems consume one file, a change can fail outside the modified location. Follow the changed requirement through implementation and tests, then work back from the implementation to callers and user actions. Permission policy, persistence rules, search and export, shared configuration and external integrations are boundaries worth examining separately. The impact worksheet records the link evidence, failure boundary to check, review outcome and owner.

A link between a test and a requirement does not establish that impact review is current. Check whether the expected result was updated after the requirement changed. A missing link calls for an unresolved item, an owner and a review date, not an assumption of no impact. Requirements changes and test traceability addresses maintaining the links that help discover candidates. Finding candidates and deciding which of them to execute remain separate tasks.

The decision worksheet records impact reach, change uncertainty, consequences of failure, and detection and rollback conditions. Focused covers an established independent boundary and adjacent flows. Expanded considers connections across roles, integrations and data consumers. Broad or Release-level considers important shared failure boundaries across the release. These labels do not automatically prescribe a test count or acceptance threshold.

If a shared permission change justifies wider scope, do not dilute it by averaging several low-scoring factors. Conversely, a large code change need not select unrelated tests when evidence shows that its impact stays within an independent module. Broad does not mean running every test without exception: unrelated items may be excluded with recorded reasons. When an important scenario cannot run because time or accounts are unavailable, record the unverified condition rather than relabeling the scope as lower risk.

The following changes are fictional worksheet exercises, not customer changes or executed test results. In A, a common document permission policy changes across viewing, search and downloads. Assuming that the policy affects multiple roles and organization boundaries, select Broad scope and include cross-organization document access, exposure in search results and download permissions. Exclude wording in an independent statistics screen only after establishing that it shares neither the policy nor the affected data.

In B, an export file consumed by two systems gains a field. Consider Expanded scope covering both consumers' interpretation and compatibility with the earlier format, rather than checking only file creation. If the consumer inventory is stale, leave an unresolved item and do not mark impact review complete. C changes independent display text without altering identifiers, stored values or shared logic. Assuming those conditions are verified, choose Focused scope for the display and adjacent interactions.

If the text in the real version of C also serves as a business code or search key, the assumption fails. Revisit impact candidates instead of copying the scope label. The useful part of an example is the condition that justified its selection, not just the chosen level. Leave result fields empty until the selected tests actually run.

After choosing a scope level, record each test identifier, whether it is selected, excluded or unresolved, the supporting reason and execution preparation. Selecting cross-organization document access in A requires accounts and documents for those organizations. An unavailable account is not evidence that the scenario is irrelevant. Record what must be prepared, its owner and execution date, and report the unverified risk to the release owner. For an excluded statistics label, reference the evidence establishing that it is disconnected from the permission policy and affected data.

Tests that previously found defects and real usage patterns can also support selection. An absence of defect history does not establish low risk. Some checks make sense only when integrations and data state are observed together. A shared rule may be checked at a faster, more reproducible layer, but moving that check does not remove risks that can only be observed through the user interface. Check whether another reviewer can understand the same boundary from the exclusion record.

The handover sheet connects selected tests and execution rounds to the build, environment, run identifier, results, defects, unverified conditions and next owner. Use PASS, FAIL, BLOCKED and NOT RUN for execution records; do not mark planned work as passed. Revisit the change brief when the build, requirement or configuration changes, and revisit impact candidates and selection evidence when a dependency or defect is discovered. Check whether an earlier passing record still explains the new change.

READY, READY WITH CONDITIONS and HOLD are separate release decisions based on agreed criteria, actual results, unverified scope and residual risk. Connect results to the release decision memo and scenario result sheet. The downloadable PDF and editable Excel workbook are in English. A change list, current test catalog, unresolved impact and release constraints support a concrete discussion of scope and ownership with IXC QA process consulting or QA outsourcing.