Модуль 2 · Урок 7
Confirmation і regression testing
Confirmation відповідає, чи усунено конкретний defect. Regression шукає небажаний вплив зміни на інші частини. Один зелений retest не замінює risk-based regression.
Fix verificationChange impactRegression selectionResidual risk
Два різні контракти
| Confirmation | Regression | |
|---|---|---|
| Primary question | Чи виправлено original defect? | Чи не створила зміна нові failures? |
| Basis | Defect report, reproducer, expected result | Code/config/data diff, dependencies, risk model |
| Scope | Original condition + доречні boundaries | Affected features, interfaces, quality characteristics |
| Result | Fixed / not fixed / cannot verify | Regression evidence + remaining risk |
Impact analysis перед regression
Freeze change scope. Code, configuration, schema, infrastructure, feature flags та dependencies.
Map blast radius. Callers, consumers, shared state, cached data, permissions та observability.
Select tests. Critical journeys, changed branches, interfaces, historical defects і non-functional risks.
Define exit. Required pass set, accepted failures, owner та residual-risk statement.
Автоматизація без ілюзії повноти
Stable repeatable regression — хороший automation candidate, але suite старіє. Новий change може вимагати нових tests, а flaky check — окремого triage. «Усе зелене» означає лише, що виконані записані assertions у конкретному environment.
Не ретестіть лише happy path
Fix boundary defect потребує original reproducer, сусідніх partitions і downstream impact. Якщо defect стосувався race condition, один послідовний run майже нічого не доводить.
Практика
- Візьміть synthetic DEF-118 про exact-end booking overlap.
- Запишіть confirmation test з original evidence.
- Побудуйте dependency/impact map і regression selection basis.
- Визначте automation candidate, owner, result та residual risk.
Офіційне джерело
Практична перевірка · урок 7 з 16
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.