Виды тестирования: functional, regression, smoke и sanity

Когда разработчик спрашивает QA «ты уже smoke-тест прогнал?», а тестировщик понимает это как «проверь быстренько всё», — жди проблем. Путаница между smoke, sanity, functional и regression — не просто терминологическая, она приводит к реальным провалам: битая сборка уходит на регрессию, точечный хотфикс получает полный трёхчасовой прогон, или, наоборот, серьёзное изменение проходит только дымовую проверку.

Эти четыре вида тестирования решают принципиально разные задачи и занимают разные места в процессе поставки. Functional тест отвечает на вопрос «работает ли то, что мы написали?». Regression — «не сломали ли мы то, что работало?». Smoke — «вообще жива ли эта сборка?». Sanity — «это конкретное исправление точно работает?». Смешивать их — значит либо тратить лишнее время, либо пропускать дефекты.

На собеседованиях QA-инженеров эта тема всплывает регулярно, причём именно в формате «объясни разницу» или «как бы ты выстроил тестирование после деплоя хотфикса». Поверхностных определений здесь не хватает — интервьюер ждёт понимания механики и контекста применения. Разберём каждый вид детально, а потом сложим в единую картину.

1. Functional testing: проверяем, что система делает то, что должна

Функциональное тестирование — это проверка того, что система выполняет заявленные требования. Мы смотрим на поведение: пользователь нажал «Войти» — система его авторизовала. Пользователь добавил товар в корзину — товар там оказался. Сумма заказа посчитана правильно. Нас интересует что делает система, а не как она это делает внутри.

Ключевое слово здесь — требования. Функциональное тестирование работает от спецификации: есть user story, acceptance criteria, технические требования — тесты покрывают именно их. Это black-box подход: тестировщик видит только входные данные и выходной результат, не заглядывая в код.

Что именно проверяем

Функциональное тестирование охватывает две группы сценариев.

Позитивные сценарии — система ведёт себя ожидаемо при корректных данных: форма логина принимает верный email и пароль, создаёт сессию, редиректит на dashboard. CRUD-операции работают: создание записи сохраняет её в базу, обновление меняет нужные поля, удаление убирает запись и не ломает связанные данные.

Негативные сценарии — система корректно обрабатывает некорректные данные: форма логина отклоняет неверный пароль с понятным сообщением об ошибке, API возвращает 422 при невалидном теле запроса, загрузка файла не принимает исполняемые файлы вместо изображений. Граничные значения: поле принимает максимум 255 символов — что происходит при 255 и при 256?

Связь с требованиями

Функциональный тест без привязки к требованию — это просто клик. Хороший тест-кейс всегда ссылается на конкретный пункт: «согласно US-42, пользователь должен получить email-подтверждение в течение 5 минут после регистрации». Если требование размытое или его нет — это сигнал идти к аналитику или разработчику за уточнением, а не додумывать самостоятельно.

Пример

Берём систему онлайн-платежей. Функциональные тесты для сценария «оплата картой» будут охватывать: успешную оплату валидной картой, отклонение карты с истёкшим сроком, ошибку при неверном CVV, обработку таймаута платёжного шлюза, корректное отображение суммы в рублях с копейками. Каждый сценарий — отдельный тест-кейс с конкретными шагами, ожидаемым результатом и привязкой к требованию.

2. Regression testing: убеждаемся, что новое ничего не сломало

Регрессионное тестирование — это прогон существующих тест-кейсов после изменений в системе. Цель одна: убедиться, что работавший функционал продолжает работать. Разработчик починил баг с пагинацией — нужно проверить не только пагинацию, но и поиск, фильтры и сортировку, которые с ней связаны. Изменили библиотеку авторизации — регрессия проходит по всем сценариям, где авторизация задействована.

Мотивация

Код — взаимосвязанная система. Изменение в одном месте часто имеет неожиданные последствия в другом. Классический пример: разработчик оптимизировал SQL-запрос в модуле отчётов, не зная, что этот же запрос используется в экспорте данных — экспорт начал отдавать пустые файлы. Без регрессионного тестирования такое уходит в прод.

Полная vs частичная регрессия

Полная регрессия — прогон всего тест-сьюта. Запускается перед крупными релизами или когда изменения затронули архитектурно значимые части системы: core-авторизацию, платёжный модуль, API-gateway. Занимает много времени, зато даёт максимальную уверенность.

Частичная регрессия — выборочный прогон на основе анализа рисков. Смотрим, какие части системы потенциально затронуты изменением, и тестируем только их. Применяется в agile-командах, где нет времени на полный прогон каждого спринта. Требует хорошего понимания архитектуры и зависимостей — и документированных трейсов между фичами и тест-кейсами.

Автоматизация как необходимость

При ручном регрессионном тестировании команда неминуемо попадает в ловушку: с каждым спринтом тест-сьют растёт, а времени больше не становится. Через полгода полная регрессия занимает две недели — и либо её перестают делать полностью, либо она превращается в формальность, где тестировщики «пробегают» по кейсам за час.

Выход — автоматизация. Регрессионные тесты в CI/CD запускаются на каждом пул-реквесте автоматически: разработчик создал PR, пайплайн прогнал регрессию, результат виден до мержа. Это называют shift-left: дефекты находятся как можно раньше, когда их исправить дешево, а не после деплоя на прод.

Место в CI/CD

Типичная конфигурация: unit-тесты + линтер на каждом коммите (секунды), smoke + функциональные тесты по PR (минуты), полная регрессия на ночном прогоне или перед release-ветвью (часы). Это позволяет получать быструю обратную связь разработчику и не задерживать итерации.

3. Smoke testing: быстрая проверка жизнеспособности сборки

Smoke-тестирование — это минимальный набор тестов, который проверяет, что сборка вообще пригодна для дальнейшего тестирования. Название пришло из электроники: если подключить новое устройство к питанию и оно не задымится — можно двигаться дальше. В тестировании ПО логика та же: если базовые функции работают — можно тратить время на детальную проверку. Если нет — возвращаем сборку разработчику.

Цель: не тратить время на битую сборку

Представьте: тестировщик два часа проверял сложный E2E-сценарий покупки, обнаружил дефект в шаге 15 из 20. Открывает баг-репорт, а разработчик смотрит и говорит: «Да, это у нас сломана миграция базы, я уже знаю, пересоберите». Два часа работы — в корзину.

Smoke-тест занимает 10–15 минут и отвечает на один вопрос: «Стоит ли вообще тестировать эту сборку?». Это первый барьер. Прошли smoke — идём дальше. Не прошли — билд отклонён, команда уведомлена, тестировщик не теряет время.

Что входит в smoke-набор

Smoke — это не случайные тесты. Это 5–15 критических сценариев, которые охватывают самые важные пути в системе:

Авторизация и базовая навигация — пользователь может войти, перейти по ключевым разделам, выйти. Если это не работает, ничего дальше тестировать не имеет смысла.

Главные бизнес-функции — одно-два действия, которые представляют ядро продукта. Для интернет-магазина это: добавить товар в корзину и оформить заказ. Для SaaS-платформы: создать проект, добавить участника.

Базовое API-поведение — ключевые эндпоинты отвечают с ожидаемыми кодами. GET /health возвращает 200, GET /api/users не возвращает 500.

Критическая инфраструктура — база данных доступна, внешние интеграции подключены, очередь сообщений принимает задачи.

Характеристики smoke-набора

Smoke-тесты должны быть стабильными: они прогоняются при каждом деплое, любая флакучесть создаёт ложные тревоги. Они должны быть быстрыми: 10–15 минут максимум. И они должны быть узнаваемо минимальными — не пытаться проверить всё, а прикрыть именно те точки, падение которых означает «эта сборка не готова».

4. Sanity testing: быстрая проверка конкретного исправления

Sanity-тестирование — это точечная проверка конкретной фичи или конкретного исправления. Там, где smoke — про сборку в целом, sanity — про одно изменение. Разработчик зафиксировал баг с расчётом скидки — sanity-тест проверяет именно расчёт скидки, плюс несколько соседних сценариев, которые могли быть затронуты.

Узкий фокус как принцип

Sanity-тест не претендует на полноту. Его задача — дать быстрый ответ на конкретный вопрос: «это исправление работает?». Если баг заключался в том, что при применении промокода цена уходила в минус — sanity проверяет именно это: промокод применяется, цена корректна, не уходит в минус, заказ оформляется. 15–20 минут, чёткий результат.

Когда применять

Sanity идеален в нескольких ситуациях. Первая — хотфикс в прод: критический баг нашли в производстве, разработчик быстро исправил, нужно убедиться, что исправление работает, не устраивая полный регрессионный прогон в 3 часа ночи. Вторая — переделка конкретного компонента: дизайнер переверстал форму оформления заказа, разработчик адаптировал логику — sanity проверяет форму и смежные сценарии. Третья — быстрая итерация в sprint: разработчик пересмотрел логику валидации, нужно быстро убедиться, что новая логика работает до того, как идти в полный регрессионный цикл.

Нерегрессионная природа sanity

Sanity — это не регрессия. Sanity не ставит задачу проверить, что всё остальное продолжает работать. Это задача регрессии. Sanity говорит: «эта конкретная вещь, которую мы изменили — она работает». Если после sanity возникают сомнения в смежных функциях — это сигнал запустить целевую регрессию по рискованным зонам.

5. Smoke vs sanity: в чём реальная разница

Это самая частая точка путаницы, и не случайно: оба вида быстрые, оба проверяют не всё подряд, оба часто выполняются вне стандартного pipeline. Но их цели противоположны.

Параметр	Smoke	Sanity
Цель	Убедиться, что сборка жизнеспособна	Убедиться, что конкретное изменение работает
Объём	Широкий, но поверхностный	Узкий, но детальный
Когда запускать	После каждого деплоя/сборки	После точечного исправления или изменения
Инициатор	Автоматически в CI/CD	Чаще ручной, ad hoc
Автоматизируется	Да, хорошо поддаётся	Реже, зависит от специфики
Покрывает	Всю систему поверхностно	Одну фичу или область глубоко
Если провалился	Сборка отклонена, тестирование стопается	Конкретная фича не готова, остальное может идти дальше

Типичная ошибка на собеседовании — описывать sanity как «узкий smoke». Это не так. Smoke спрашивает «живёт ли сборка?», sanity спрашивает «работает ли вот это?». Они решают разные вопросы и применяются в разных ситуациях.

Другая ошибка — думать, что sanity — это всегда ручное тестирование. На практике если фича стабилизировалась и sanity-сценарии повторяются регулярно, их тоже автоматизируют и включают в нужный уровень тест-сьюта.

6. Как эти виды сочетаются в реальном CI/CD пайплайне

Теперь сложим картину воедино. Посмотрим на три типичных сценария: обычный пул-реквест, деплой на staging и hotfix в прод.

Пул-реквест разработчика

Разработчик открыл PR с новой фичей — модуль уведомлений. Что запускается автоматически:

Первый этап — smoke. Пайплайн собирает артефакт, прогоняет 10 критических сценариев: авторизация, основной CRUD, API-health. Занимает 8 минут. Если smoke не прошёл — PR получает красный статус, разработчик видит проблему до code review. Если прошёл — идём дальше.

Второй этап — функциональные тесты. Прогоняются тесты, связанные с изменёнными модулями: сами уведомления плюс соседние сервисы (очередь, email). 20–30 минут.

Третий этап — регрессия. На ночном прогоне или перед мержем в main: полный тест-сьют. Если что-то упало — PR помечается, разработчик разбирается.

Деплой на staging

После мержа в main и деплоя на staging: снова smoke (теперь уже реальная среда, не собранный артефакт), потом полная регрессия. Staging — последний рубеж перед прод.

Hotfix в прод

Ночью упала оплата. Разработчик нашёл баг в конвертации валюты, исправил, выкатывает хотфикс. Стандартный пайплайн занял бы 3 часа. Вместо него:

Smoke — 8 минут — убеждаемся, что сборка с патчем не сломана совсем.

Sanity — 15 минут — ручная или автоматизированная проверка именно конвертации валюты: оплата в рублях, оплата в долларах, граничные значения, суммы с копейками.

Всё прошло — деплоим. Полная регрессия запускается следующим утром как плановый прогон.

Последовательность как принцип

Порядок всегда одинаковый: smoke → functional → regression. Sanity стоит отдельно — это не место в очереди, это отдельный инструмент для конкретной ситуации. Нарушать порядок дорого: запустить регрессию на битой сборке — потратить 2 часа впустую.

В зрелых командах этот порядок зашит в пайплайн и не требует ручных решений. Тестировщик фокусируется на анализе результатов и исследовательском тестировании, а не на «запустить smoke вручную».

7. Что спросят на собеседовании

Тема видов тестирования — стандартная часть QA-интервью на любом уровне. Вот конкретные вопросы, которые встречаются чаще всего.

«Объясните разницу между smoke и sanity тестированием»

Smoke — проверка жизнеспособности сборки целиком: широко, поверхностно, быстро. Отвечает на вопрос «стоит ли вообще тестировать эту версию?». Sanity — проверка конкретного изменения или исправления: узко, детально, тоже быстро. Отвечает на вопрос «это конкретное исправление работает?». Smoke запускается при каждом деплое, sanity — ad hoc после точечных изменений.

«Что такое регрессионное тестирование и почему без автоматизации оно не работает?»

Регрессия проверяет, что старый функционал не сломан после новых изменений. Без автоматизации тест-сьют растёт с каждым спринтом, а время на прогон — нет. Через полгода полная регрессия занимает неделю — и команда либо делает её формально, либо не делает совсем. Автоматизированная регрессия в CI/CD решает это: прогон на каждом PR, результат до мержа.

«Когда вы применили бы sanity testing вместо regression?»

После hotfix в прод в ночное время. Нет возможности ждать полный трёхчасовой прогон, но нужна уверенность, что патч сработал и не сломал ближайшие функции. Sanity даёт эту уверенность за 15–20 минут. Регрессия догонит утром по расписанию.

«Что входит в smoke-набор и как его поддерживать актуальным?»

5–15 критических сценариев: авторизация, ключевые бизнес-функции, базовые API-эндпоинты, доступность инфраструктуры. Smoke-набор пересматривается при изменении архитектуры или бизнес-приоритетов. Критерий включения в smoke — «если это упадёт, тестировать дальше бессмысленно». Если тест не соответствует этому критерию — он в smoke не нужен.

«Как вы выстраиваете последовательность видов тестирования в CI/CD?»

Smoke — первый барьер при каждом деплое. Функциональные — на PR по затронутым модулям. Регрессия — на ночных прогонах или перед релизом. Sanity — ad hoc инструмент для hotfix и точечных изменений, вне стандартной последовательности. Приоритет — быстрая обратная связь разработчику, поэтому быстрые тесты идут первыми.

«Функциональное тестирование — это всегда black-box?»

В классическом понимании — да, мы смотрим на поведение системы без знания о реализации. Но на практике QA часто имеет доступ к коду и может использовать эту информацию для лучшего покрытия граничных случаев. Это называют grey-box: тестируем через UI/API как пользователь, но знаем о внутренних рисках и строим тест-кейсы с учётом этого.

Подробнее про другие QA-вопросы, которые встречаются на собеседованиях — в нашей статье 50 вопросов QA-собеседования: там разобраны дефект-менеджмент, тест-дизайн, Page Object Model и основы автоматизации.

FAQ