Ваша команда три дня гоняет полный регресс ради правки текста на кнопке.
А на прошлой неделе выкатила миграцию базы вообще без проверки — «мы же только бэкенд трогали». Если узнали себя — поздравляю: вы путаете смоук, санити и регресс. И это не терминологический спор для собеседований. Это причина, по которой ваши релизы одновременно медленные И дырявые. Уникальное достижение, между прочим: обычно выбирают что-то одно.
Смоук-тестирование — быстрая проверка, что сборка вообще живая: приложение открывается, ключевые функции работают. Запускается на каждую сборку, занимает минуты. Санити-тестирование — узкая проверка конкретного изменения: починили баг — проверяем починенное и то, что рядом. Регрессионное тестирование — широкая проверка, что новые изменения не сломали старую функциональность. Запускается перед релизом. Смоук отвечает «оно живое?», санити — «фикс сработал?», регресс — «мы ничего не задели?».
Что такое смоук-тестирование простыми словами
Термин пришёл от железячников: включаешь плату в розетку — если дым не пошёл, можно тестировать дальше. Ваш «дым» — это: приложение открывается, логин пускает, главный сценарий (корзина, оплата, создание заказа — то, что кормит бизнес) проходит до конца. Всё. Пять-десять проверок, десять минут.
Смоук не ищет баги. Смоук отвечает на один вопрос: имеет ли смысл тестировать эту сборку дальше — или она мертворождённая. Команды без смоука узнают о мёртвой сборке от клиентов. В пятницу вечером. По телефону.
Что такое санити-тестирование простыми словами
Санити — это проверка на здравый смысл после точечного изменения. Починили расчёт скидки — проверяем расчёт скидки и соседние цены, а не гоняем всю корзину, доставку и личный кабинет. Узко, глубоко, быстро.
Санити — это то, что вы делаете вместо полного регресса, когда изменение маленькое и вы понимаете его радиус поражения. Ключевое слово — «понимаете». Если разработчик на вопрос «что могло задеть?» отвечает «да ничего» и отводит глаза — это не санити, это лотерея.
Что такое регрессионное тестирование простыми словами
Регресс — проверка того, что старое не сломалось от нового. Не нового функционала — его вы и так проверите, он на виду. Старого. Того, что работало годами, никем не трогалось и отвалилось от миграции, обновления библиотеки или чужого рефакторинга.
Регресс — самая дорогая из трёх проверок: десятки и сотни сценариев. Вручную — дни. Поэтому команды начинают его «оптимизировать»: сокращать, пропускать, гонять раз в квартал. Баги при этом не в курсе, что у вас оптимизация.
Таблица отличий: смоук vs санити vs регресс
| Смоук | Санити | Регресс | |
|---|---|---|---|
| Вопрос | Сборка живая? | Фикс сработал? | Старое не сломалось? |
| Когда | Каждая сборка / деплой | После точечного фикса | Перед релизом |
| Широта | Узко, только критичное | Узко, вокруг изменения | Широко, всё старое |
| Время | Минуты | Минуты–час | Часы–дни |
| Кто запускает | Автоматика (в идеале) | QA | Автоматика + QA |
Почему вы гоняете не то
Теперь к неудобному. Типовая команда делает ровно наоборот.
Полный регресс — на каждый чих. Правка текста, замена иконки — «ну надо же всё проверить». Три дня QA-времени на изменение с радиусом поражения в одну кнопку. Спринт сгорел, команда ненавидит релизы, релизы становятся реже — и следующий тащит в себе уже двадцать изменений. Которые, конечно, «надо все проверить». Поздравляю, вы построили вечный двигатель боли.
Смоука нет вообще. Сборка уходит на стейдж, QA садится за трёхдневный регресс — и на второй день выясняет, что логин не работал с самого начала. Два дня тестировали труп.
Санити подменяет регресс. «Мы проверили фикс, остальное не трогали» — и через неделю выясняется, что «не трогали» задело выгрузку отчётов, о которой все забыли. Санити без периодического полного регресса — это езда без зеркал: пока едешь прямо, всё отлично.
Корень у всех трёх один: когда проверка стоит дорого, её начинают экономить. А экономят всегда на невидимом — на старой функциональности, которая «и так работает».
Как должна выглядеть пирамида прогонов
Заметьте: пункты 1 и 3 — автоматика. Смоук и регресс — это одни и те же проверки, повторяемые сотни раз без изменений. Именно такую работу и надо забирать у людей: в TestManager сценарий записывается через Recorder один раз — и дальше живёт в обоих контурах. Короткий набор гоняется как смоук на каждый деплой, полный — как регресс перед релизом, с отчётами, которые читаются за минуту. Санити и исследовательские проходы остаются людям — там, где нужна голова, а не выносливость.
Когда ручной прогон всё-таки нужен
Честно: автоматика не заменяет всё. Новый функционал, сложные пользовательские пути, «посмотреть глазами, не разъехалось ли» — это руки и голова живого QA. Но если ваши люди в сотый раз проходят один и тот же чек-лист логина — вы платите зарплату за работу робота. Робот, к слову, стоит дешевле и не увольняется от скуки.
FAQ
Чем смоук отличается от санити?
Смоук — широкий и мелкий: вся система на уровне «живое/мёртвое». Санити — узкий и глубокий: одно изменение и его окрестности. Смоук гоняют на каждую сборку, санити — после конкретного фикса.
Сколько проверок должно быть в смоуке?
5–15. Если смоук идёт больше 15 минут — это уже не смоук, а маленький регресс. Режьте до сценариев, без которых бизнес останавливается.
Как часто гонять полный регресс?
Перед каждым релизом. Если регресс автоматизирован — хоть каждую ночь. Если вручную и «раз в квартал, потому что дорого» — у вас не расписание, а признание.
Можно ли автоматизировать смоук и регресс без программиста?
Да. В TestManager сценарии записываются через Recorder по реальным действиям пользователя, собираются на Page Objects и запускаются по расписанию или из CI/CD. Ручной QA справляется с первого дня.
Смоук упал — что делать?
Ничего не тестировать дальше. Сборка не едет, разработчик чинит сразу. Смоук, падение которого «ну посмотрим потом», не существует — вы просто зря жжёте электричество.