Зачем это спрашивают
Эти четыре слова звучат на каждой планёрке: «прогоним смоук», «нужен регресс перед релизом», «перепроверь баг». Интервьюеру важно понять, что вы не перепутаете их в работе. Если тестировщик называет перепроверкой полный регресс или считает смоук «быстрым регрессом», команда неправильно оценит, сколько времени нужно на релиз и что на самом деле проверено.
Ещё одна цель вопроса — увидеть, понимаете ли вы, зачем каждая проверка нужна и в какой момент её делают. Список определений без поводов звучит как заученный текст.
Как построить сильный ответ
Разведите понятия по двум осям: ширина (сколько функциональности охватываем) и глубина (насколько подробно проверяем). И для каждого назовите повод — событие, после которого проверку запускают.
| Проверка | Цель | Ширина и глубина | Когда |
|---|---|---|---|
| Смоук | Убедиться, что сборка вообще пригодна к тестированию | Широко, поверхностно | Сразу после выкладки новой сборки на стенд |
| Перепроверка (retest) | Подтвердить, что конкретный баг исправлен | Один баг, его шаги | Баг перешёл в статус «исправлен» |
| Санити | Убедиться, что изменённая область работает разумно | Узко, но глубже смоука | После небольшого исправления или доработки |
| Регресс | Убедиться, что изменения не сломали то, что работало раньше | Широко и подробно | Перед релизом, после значимых изменений |
Смоук
Название пришло из проверки железа: включили — не задымилось. Это короткий набор ключевых сценариев: приложение открывается, можно войти, основной путь пользователя проходит. Если смоук упал, дальше тестировать бессмысленно — сборку возвращают.
Перепроверка
Повтор шагов из конкретного баг-репорта на сборке с исправлением. Результат один из двух: баг закрыт или переоткрыт. В терминах ISTQB это подтверждающее тестирование (confirmation testing). Об этом этапе подробнее — в статье про жизненный цикл бага.
Санити
Узкая проверка вокруг изменения: не только шаги бага, но и соседние сценарии той же функции. Например, исправили расчёт скидки — проверяем скидку на разных суммах и с разными товарами. Санити часто рассматривают как небольшую часть регресса, сфокусированную на одной области. Важно: в разных командах границу между санити и смоуком проводят по-разному, поэтому в ответе стоит говорить о сути, а не спорить о терминах.
Регресс
Проверка того, что новые изменения не сломали старую функциональность — в том числе в местах, которые никто не трогал, но которые связаны с изменённым кодом. Регресс большой и повторяется к каждому релизу, поэтому его в первую очередь автоматизируют; как распределять такие тесты по уровням — в статье про пирамиду тестирования.
Типичный порядок
Новая сборка на стенде → смоук → перепроверка исправленных багов → санити вокруг исправлений → регресс перед релизом.
Пример ответа
Это четыре разных проверки с разной целью. Смоук делают сразу после выкладки сборки: быстро и широко проходят главные сценарии, чтобы понять, можно ли вообще тестировать дальше. Перепроверка — это повтор шагов конкретного бага после исправления: баг либо закрываю, либо переоткрываю. Санити шире перепроверки, но уже смоука: смотрю исправленную функцию и соседние сценарии, например после правки скидки проверяю её на разных суммах. Регресс — широкая и подробная проверка того, что изменения не сломали старое, даже в местах, которые не трогали. Его проводят перед релизом, и это первый кандидат на автоматизацию. Обычно порядок такой: смоук, перепроверка, санити, регресс.
Частые ошибки
- Называть санити и перепроверку одним и тем же. Перепроверка — шаги одного бага, санити — область вокруг изменения.
- Говорить, что смоук — это «короткий регресс». Цель другая: смоук отвечает на вопрос «можно ли тестировать сборку», а не «не сломалось ли старое».
- Не называть поводов: когда и после чего запускается каждая проверка.
- Считать, что регресс нужен только при крупных изменениях. Небольшая правка тоже может задеть связанный код.
- Утверждать единственно верные определения санити: в разных командах термин используют немного по-разному.
Пример на MarketCove
Представим, что на стенд учебного магазина MarketCove выложили сборку, где исправлен гипотетический баг: покупатель в истории заказов не видел статус, который установил сотрудник, — назовём его ORD-12.
- Смоук: открывается каталог, открывается карточка товара, товар добавляется в корзину, можно войти по имени пользователя, гость может оформить заказ. Плюс быстрый запрос к API, что сервис отвечает:
curl -s -o /dev/null -w "%{http_code}\n" "https://shop.tomiddle.com/api/products"
Ожидаем код 200. Если каталог не открывается или вход сломан, дальше не идём.
- Перепроверка: точно по шагам и с теми же данными, что указаны в репорте ORD-12, на том же стенде. Результат — баг закрыт или переоткрыт с комментарием.
- Санити: несколько смен статуса подряд, заказ из одного и из нескольких товаров, выход и повторный вход, ответ
GET /api/orders/{id}для того же заказа, гостевой заказ — он не должен появиться ни в чьём профиле. - Регресс: корзина и её сохранение в localStorage, оформление заказа целиком, история заказов в профиле, статусы в админке заказов, ключевые запросы API.
Задание для практики
Возьмите MarketCove и придумайте гипотетическое изменение, например «в оформлении заказа добавили поле комментария». Для этого изменения составьте четыре коротких списка:
- Смоук на 5–7 пунктов для любой новой сборки магазина.
- Перепроверку — если бы с этим полем был связан баг, что именно вы бы повторили.
- Санити на 5–8 проверок вокруг поля комментария.
- Регресс: какие соседние области могли пострадать от изменения формы заказа.
Затем проверьте себя на скорость в блице и пройдите вопросы про виды и уровни тестирования.
