Эти четыре термина часто смешивают, из-за чего команды по-разному понимают объём проверки и спорят уже на уровне слов. На практике важно договориться не о “правильном учебниковом определении”, а о едином смысле внутри команды.
Smoke testing
Smoke — это быстрая проверка того, что система в целом жива и пригодна к дальнейшему тестированию или использованию. Обычно сюда входят самые критичные happy-path сценарии: запуск, логин, базовая навигация, создание ключевой сущности, доступность основного API.
Sanity testing
Sanity — это узкая и целевая проверка конкретного изменения или проблемной зоны. Например, после небольшой правки в расчёте скидки команда проверяет именно связанные сценарии и соседние области, а не весь продукт.
Regression testing
Regression — это повторная проверка уже существующей функциональности, чтобы убедиться, что новые изменения не сломали старое поведение. Регрессия обычно шире smoke и sanity и строится вокруг известных продуктовых рисков.
Retest
Retest — это проверка конкретного исправленного дефекта. Вопрос здесь узкий: действительно ли баг исправлен в том сценарии, где он был найден. Retest не заменяет regression, потому что он не отвечает на вопрос, что ещё могло пострадать рядом.
Как различать на практике
- →Smoke: стоит ли вообще продолжать тестирование этой сборки.
- →Sanity: не сломано ли ожидаемое поведение в конкретной области после локального изменения.
- →Retest: исправлен ли конкретный дефект.
- →Regression: не пострадала ли остальная функциональность из-за изменений.
Best practice
- →Зафиксируйте словарь терминов внутри команды, чтобы одинаково понимать объём проверки.
- →Не подменяйте regression случайным набором старых тест-кейсов — он должен быть риск-ориентированным.
- →Не считайте retest достаточным основанием для релиза, если изменение затрагивало зависимые области.
Выбираем проверки по цели: релиз исправления скидки
Вымышленное требование DISC-1: скидка 10% действует при сумме товаров не меньше 10000 центов. В дефекте использовали > вместо >=, поэтому корзина на 10000 центов оставалась без скидки. Все суммы ниже дают целые центы; для остальных нужно отдельное правило округления. Релиз меняет сравнение в общей функции расчёта.
Проверка Цель Триггер Объём Пример
Smoke Сборка пригодна для дальнейших тестов? Новый деплой Небольшой набор по критичным функциям Приложение открывается, вход работает, каталог загружается, checkout доступен
Sanity (соглашение этой команды) Изменённая область ведёт себя ожидаемо? Небольшое исправление Ближайшие сценарии 9900 / 10000 / 10100 дают 9900 / 9000 / 9090
Retest / confirmation Исправлен конкретный дефект? Исправление известной проблемы Исходное воспроизведение и ожидание Та же корзина на 10000 теперь даёт 9000
Regression Не сломано ранее работавшее? Изменение с возможным влиянием Связанные и зависимые функции по рискам Сохранённые заказы, счета и расчёты возврата соответствуют согласованным ожиданиямОдин релиз и четыре разных вопроса
Сначала выполните smoke среды. Если checkout не открывается, зафиксируйте блокер: проблема деплоя не доказывает ошибку исправленного сравнения. Затем повторите исходные условия дефекта, аккаунт, валюту и вход на новой сборке: 10000 должно дать 9000. Это confirmation. После этого проверьте соседние 9900 и 10100; команда может называть такой узкий набор sanity.
Для регресса сначала изучите потребителей общей функции. Включите итог сохранённого заказа, счёт и тот путь возврата, который действительно использует расчёт. Для каждого возьмите согласованное ожидание по его правилам: нельзя автоматически считать возврат как 90% или переносить DISC-1 на каждого потребителя. Добавьте контрольную корзину, которая раньше корректно считалась без скидки. Ширина набора определяется связями и бизнес-риском, а не обязательным числом тестов.
Небольшой запускаемый пример
Сохраните как release_check_selection.py и запустите python3 release_check_selection.py. Вывод: Known defect reproduced; confirmation and three focused checks passed. Скрипт проверяет только арифметику и логику выбора; smoke приложения и регресс зависимых функций он не выполняет.
def old_total(cents):
return cents * 9 // 10 if cents > 10000 else cents
def fixed_total(cents):
return cents * 9 // 10 if cents >= 10000 else cents
# Values below produce whole-cent results; no rounding rule is inferred.
assert old_total(10000) == 10000
assert fixed_total(10000) == 9000
for cents, expected in [(9900, 9900), (10000, 9000), (10100, 9090)]:
assert fixed_total(cents) == expected
print("Known defect reproduced; confirmation and three focused checks passed")Фиксируем границы доказательств
Один кейс может входить в несколько наборов: проверка 10000 подтверждает исправление и пригодится для будущего регресса. Не считайте повтор выполнения дополнительным поведенческим покрытием. Записывайте сборку, цель, фактический результат и оставшийся риск, чтобы смысл «пройдено» был понятен.
Значение sanity различается между командами; иногда его используют как синоним smoke. Договоритесь о границах локально, а не превращайте эту таблицу в обязательную классификацию. Confirmation и regression отвечают на разные вопросы: устранение исходного воспроизведения не доказывает неизменность соседних функций.
Упражнение: retest суммы 10000 пройден, но счёт показывает 10000 после сохранения заказа на 9000. Можно ли считать релиз корректным? Нет. Исходный дефект может быть исправлен одновременно с провалом регресса зависимой функции. Зафиксируйте оба результата и исследуйте расхождение вместо превращения успешного retest в решение о релизе.
Продолжить изучение
Регрессионная стратегия по рискам
Короткие операционные чек-листы
ISTQB CTFL 4.0.1: section 2.2.3, confirmation and regression