From vamfi-software-consultancy
This skill should be used when the user asks to "create a regression plan", "plan regression testing", "identify regression risks", "plan test automation", "assess flaky tests", "determine regression scope for this release", or needs to protect against regressions during a release or refactoring exercise.
npx claudepluginhub vamfi/vamfi-plugins --plugin vamfi-software-consultancyThis skill uses the workspace's default tool permissions.
Define the scope, priority, and automation approach for regression testing. Identify flaky tests and calculate automation ROI to ensure regression testing is sustainable and effective.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Define the scope, priority, and automation approach for regression testing. Identify flaky tests and calculate automation ROI to ensure regression testing is sustainable and effective.
Regression testing answers: "Does the new change break anything that was working before?" A regression plan prevents over-testing (running everything every time) and under-testing (missing critical paths).
For each release or change, determine which test suites must run:
| Trigger | Regression Scope | Rationale |
|---|---|---|
| Any PR merge | Unit + lint | Fast feedback, catches most errors |
| Staging deploy | Unit + integration + E2E smoke | Validates environment |
| Production release | Full suite + performance baseline | Maximum safety |
| Database schema change | Data migration tests + full integration | Schema regressions are high risk |
| Authentication change | Security tests + full E2E | Auth breakage is critical |
| Third-party update | Integration tests for that provider | Contract validation |
Score each test suite by risk:
| Test Suite | Business Impact | Change Frequency | Automation | Priority |
|---|---|---|---|---|
| [Payment flow E2E] | Critical | Low | 100% | P0 — always run |
| [User registration] | High | Medium | 90% | P0 — always run |
| [Report generation] | Medium | Low | 70% | P1 — run on staging |
| [Admin settings] | Low | Low | 50% | P2 — run on release |
Identify flaky tests (tests that pass and fail without code changes):
| Test ID | Failure Rate | Root Cause Category | Recommendation |
|---|---|---|---|
| [TC-042] | 15% | Timing/async issue | Fix or quarantine |
| [TC-103] | 30% | Test data collision | Isolate test data |
| [TC-201] | 8% | External service dependency | Mock the service |
Root cause categories:
For each manual regression area, calculate automation ROI:
Manual effort per release: [time] hours × [£/hr] = [£cost]
Automation build cost: [time] hours × [£/hr] = [£build cost]
Maintenance per release: [time] hours × [£/hr] = [£maintenance]
Annual saving: (manual cost - maintenance) × releases/year
Payback period: build cost / annual saving
ROI: (annual saving - build cost) / build cost × 100%
Recommend automation where:
| Phase | Suite | Owner | Duration | Pass Criteria |
|---|---|---|---|---|
| PR gate | Unit + lint | CI/CD | < 5 min | 100% pass |
| Staging | Integration + smoke | CI/CD | < 15 min | 100% pass |
| Release | Full suite | QA Lead | < 45 min | 100% pass, no P0 open |
references/flaky-test-remediation.md — Patterns for fixing flaky tests by root cause