# Plan regression checks around a changed behavior

Illustrative planning brief; no automatic product import.

Illustrative change: a date filter alters exported records. The team needs boundary checks and an unaffected export check.

## Decision

Choose tests that distinguish the intended record boundary from a regression in the existing path.

## Owned work

- Map the changed behavior
  - Owner role: QA lead
  - Acceptance evidence: The brief identifies the date-boundary outcome and affected data path.
- Choose meaningful checks
  - Owner role: Reviewer
  - Acceptance evidence: Tests cover boundary inclusion and the unaffected export behavior.
- Record the result decision
  - Owner role: Acceptance owner
  - Acceptance evidence: Failure evidence changes the release or repair decision.

## Workflow

1. Start from the user-visible change and its affected seams.
2. Choose checks that would catch a credible wrong result.
3. Review failures before acceptance and avoid an implementation-mirroring test inventory.

## Judgment

This is a planning guide, not a certification that a release is safe or a replacement for your required checks.


## Illustrative delivery brief

Changed outcome: export honors the selected date boundary.
Regression risk: unaffected exports accidentally exclude records.
Checks: bounded synthetic cases for both paths.
Acceptance: reviewer uses actual results, not the number of tests.


## Workflow questions

### Should every code line get a test?

Choose tests by behavior and consequence, not by mirroring implementation text.

### How do we report a failed check?

Record the actual input, expected/observed behavior and the decision it blocks.

## Product connection

Use the affected behavior and acceptance evidence to define a TeamBoostAI regression task without prescribing every implementation step.

Confirm account availability before adopting this manual outline.