# Regression Identification

> Skill for the tester agent. Identify which existing tests are relevant to code changes and what new tests are needed to cover gaps. Load WHENEVER code changes are made — during PR review, before committing, or when planning test coverage.

- Skill: `las-pinter/regression-identification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add las-pinter/regression-identification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/las-pinter/regression-identification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: las-pinter (https://skillmd.com/u/las-pinter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/las-pinter/regression-identification

---


# Regression Identification

## Core Methodology (5 Steps)

### Step 1: Identify Changed Units

Map exactly what changed using `git diff`. Categorize each change:
- `[ADD]` — New code added
- `[MOD]` — Existing code modified
- `[DEL]` — Code removed
- `[REF]` — Code restructured (behavior unchanged)
- `[CFG]` — Configuration/environment changes

Track: which functions/methods were touched, which files, whether interfaces/contracts changed, whether data schemas changed.

### Step 2: Trace Dependents

For every changed file, trace at minimum:
1. Direct callers/importers
2. Test files for the changed module
3. Test files for callers of the changed module

**Dependency mapping techniques:**

| Technique | How | Best For |
|-----------|-----|---------|
| Static grep/search | Search for imports/references | Quick, small-medium projects |
| Build graph traversal | Use build system deps | Large projects |
| Dynamic call tracing | Run coverage tools on existing tests | Precise method-level mapping |

Flag changes with radius > 3 modules as high-risk. Stop tracing at 5+ modules deep (diminishing returns).

### Step 3: Check Existing Coverage

For each changed unit:

| Scenario | Check |
|----------|-------|
| Changed function | Does a test call this with relevant inputs? |
| New function | Is there a new test? |
| Changed behavior | Do tests assert the OLD behavior that changed? |
| Removed code | Were there tests for the removed functionality? |
| Error paths | Are error handling changes tested? |

Run the relevant existing tests and confirm: all previously passing tests still pass, and any test updated for new behavior is correct.

### Step 4: Identify Gaps

| Pattern | What's Missing | Risk |
|---------|---------------|------|
| New code, no tests | Untested new functionality | 🔴 High |
| Behavior changed, tests unchanged | Tests pass for wrong reasons | 🔴 High |
| Bug fixed, no regression test | Same bug can reappear | 🟠 Medium |
| Refactored code, coverage dropped | Previously tested paths untested | 🟠 Medium |
| Integration point changed, no integration test | Interface mismatch | 🔴 High |
| Dependency upgraded, no integration test | Breaking change undetected | 🟠 Medium |

**Prioritize gaps by:** business criticality → change complexity → defect probability → test proximity.

### Step 5: Write New Tests

| Gap Type | Best Level | Why |
|----------|-----------|-----|
| New logic path | Unit | Fast, precise, isolated |
| Changed behavior | Unit + Integration | Verifies behavior AND integration |
| Bug fix | Unit (reproduces the bug) | Prevents regression |
| API change | Contract | Catches consumer/provider mismatch |

Write the test that would have caught the bug before it was introduced.

---

## Change Impact Heuristics

| Change Type | Regression Risk | What to Test |
|-------------|----------------|-------------|
| Bug fix | 🟠 Medium | Fix + adjacent behavior + regression test |
| Refactor (no behavior change) | 🟢 Low | Run existing; add characterization tests if missing |
| New feature | 🟢 Low for existing | New paths; verify integration points unchanged |
| Interface/API change | 🔴 High | All callers; contract tests; backward compat |
| Dependency upgrade | 🔴 High | Full suite; check changelog for breaking changes |
| Data schema migration | 🔴 Very High | Migration forward + rollback; data integrity |

---

## Tiered Regression Strategy

| Tier | Trigger | Scope | Budget |
|------|---------|-------|--------|
| **Tier 1: Smoke** | Every commit | 20-30 critical tests | < 2 min |
| **Tier 2: Selective** | Every PR/merge | Impact-analyzed tests from Steps 1-3 | < 15 min |
| **Tier 3: Complete** | Merge to main | Full test suite | Nightly |
| **Tier 4: Full E2E** | Pre-release | E2E + manual exploration | Before release |

For individual changes, apply **Tier 2** — selective, impact-analyzed regression.

---

## Core Rules

1. Never mark a change done without running the relevant existing tests
2. Turn every production bug into a regression test — the fix isn't complete without it
3. Refactors: test coverage must increase or stay the same, never decrease
4. Dependency changes: always run the full integration test suite
5. Trace transitive dependencies, not just direct ones