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

Классификации спрашивают почти всегда — и почти всегда кандидат путает smoke с sanity, а regression с re-testing.

Виды тестирования удобно раскладывать по трём независимым осям: по уровню (что тестируем), по цели (зачем), по доступу к коду (как).

Вопрос 1: «Какие виды тестирования вы знаете?»

Что на самом деле проверяет интервьюер

Есть ли у вас система в голове. Кандидат, который вываливает случайный список из двадцати терминов, проигрывает тому, кто называет три оси и по каждой даёт примеры.

Развёрнутый ответ

По уровню (по объекту):

• Unit — отдельная функция или класс в изоляции. Пишут разработчики, гоняются за секунды.
• Integration — связка модулей: сервис и база, бэкенд и внешний платёжный шлюз, два микросервиса.
• System — продукт целиком в окружении, приближённом к боевому.
• Acceptance (UAT) — приёмка заказчиком или бизнесом: «это то, что мы просили?»

По цели: функциональное (что делает система) и нефункциональное — производительность, безопасность, удобство, совместимость, локализация, доступность.

По доступу к коду: чёрный ящик (только через интерфейс, по требованиям), белый ящик (со знанием реализации, отсюда покрытие ветвей), серый ящик (интерфейс снаружи, но со знанием структуры БД и API — типичный режим работы тестировщика).

Вопрос 2: «Чем smoke отличается от sanity и от регрессии?»

Что на самом деле проверяет интервьюер

Работали ли вы в реальном релизном цикле. Эти три слова используются каждый день, и путаница в них — сразу минус.

Развёрнутый ответ

Практический пример. Билд приехал на стенд: логин, открытие каталога, добавление в корзину, оформление заказа — это smoke, 15 минут, без деталей. Если корзина не открывается, сборку возвращают разработчикам, не тратя день на детальные проверки. Разработчик починил расчёт скидки — вы делаете re-testing по шагам из бага и sanity вокруг скидок (промокоды, суммы, округление). Перед релизом гоняете регрессию: старые оплаты, доставка, личный кабинет.

Важная деталь для сильного ответа: re-testing нельзя заменить регрессией и наоборот. Первое проверяет, что баг исчез; второе — что исправление не задело соседей. Оба нужны.

Вопрос 3: «Что такое интеграционное тестирование и зачем оно, если модули покрыты unit-тестами?»

Что на самом деле проверяет интервьюер

Понимаете ли вы, что большая часть боли живёт на стыках.

Развёрнутый ответ

Unit-тесты проверяют модуль в изоляции — а изоляция достигается заглушками (mock/stub). Заглушка возвращает то, что придумал разработчик, и потому unit-тесты остаются зелёными, даже когда реальный контракт изменился: партнёр стал присылать дату в другом формате, поле amount приехало строкой, сервис отвечает 200 с пустым телом.

Интеграционное тестирование как раз и ловит расхождения контрактов, таймауты, кодировки, транзакции и порядок вызовов. Стратегии стоит назвать: big bang (собрали всё и проверяем — быстро, но локализовать дефект тяжело), сверху вниз и снизу вверх (постепенно, с заглушками и драйверами), сэндвич как комбинация.

{
  "order_id": 1024,
  "amount": "1990.00",
  "created_at": "05.08.2026 13:40"
}

Здесь два типичных интеграционных дефекта в одном ответе: сумма пришла строкой вместо числа, дата — в локальном формате вместо ISO 8601. Unit-тесты потребителя с моком этого не увидят никогда.

Типичные ошибки кандидатов

• Называют smoke «поверхностным тестированием всего подряд в конце релиза» — smoke делается в начале, на входном контроле сборки.
• Считают re-testing частью регрессии. Это разные проверки с разными целями.
• Говорят «регрессию всегда прогоняем полностью». В реальности набор приоритизируют по риску и по зоне изменений, иначе он перестаёт помещаться в релизный цикл.
• Путают уровень и вид: «нагрузочное — это уровень тестирования». Нет, нагрузочное — цель, а уровень у него системный.

Как ответить кратко

Виды удобно раскладывать по трём осям: по уровню — unit, интеграционное, системное, приёмочное; по цели — функциональное и нефункциональное (производительность, безопасность, юзабилити, совместимость); по доступу к коду — чёрный, белый и серый ящик. Smoke — быстрая широкая проверка новой сборки, чтобы понять, стоит ли её вообще тестировать. Sanity — узкая глубокая проверка конкретной функции после правки. Re-testing — прогон шагов из баг-репорта, чтобы убедиться, что дефект исчез. Регрессия — проверка, что исправление не сломало то, что уже работало. Интеграционное нужно, потому что unit-тесты работают с заглушками и не видят расхождений реальных контрактов.