Регресс, ретест и смоук

Регресс, ретест и смоук

Введение

«Мы исправили баг, можете проверить» — и ты идёшь проверять. Но что именно ты делаешь? Проверяешь только этот баг? Или проверяешь, не сломалось ли что-то ещё? Или сначала убеждаешься, что билд вообще стабильный? Для каждого из этих сценариев есть своё название и своя задача.

Smoke-тестирование (Смоук)

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

Название пришло из электроники: когда включаешь новое устройство первый раз, смотришь — идёт ли дым? Если дыма нет — можно тестировать дальше.

Когда запускать: При получении нового билда/сборки от разработчиков.

Что проверяет:

• Приложение запускается
• Основные страницы открываются
• Ключевые функции хотя бы формально работают (войти, создать, сохранить)

Характеристики:

• Охватывает 10–20% от всех тест-кейсов
• Быстро (30 минут — максимум несколько часов)
• Не глубокое — только «дышит ли пациент»

Результат smoke-теста:

• Пройден → сборка принята для полного тестирования
• Провален → сборка возвращается разработчикам без полного тестирования

Почему это важно: Зачем тратить 2 дня на полное тестирование, если кнопка входа вообще не работает? Smoke экономит время.

Ретестирование (Retest)

Retest — повторное выполнение конкретного тест-кейса, который ранее упал, чтобы подтвердить, что дефект устранён.

Когда запускать: После того как разработчик исправил конкретный баг и пометил его как Fixed.

Что делаешь:

1. Открываешь баг-репорт
2. Выполняешь ровно те же шаги воспроизведения
3. Проверяешь, соответствует ли результат ожидаемому

Характеристики:

• Очень целенаправленное: проверяешь только исправленное
• Следуешь тем же шагам из баг-репорта
• Не проверяешь соседние функции — это не задача ретеста

Результат ретеста:

• Баг воспроизводится → статус меняется на Reopened
• Баг не воспроизводится → статус меняется на Closed

Регрессионное тестирование (Regression)

Regression testing — проверка того, что исправление бага (или новая функция) не сломало уже работавшую функциональность.

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

Почему это нужно: Код взаимосвязан. Изменение в одном месте может неожиданно сломать другое.

Пример: Разработчик исправил баг в системе скидок. Ты проверяешь не только скидки, но и: расчёт итоговой суммы, оформление заказа, уведомления на email — всё, что могло быть затронуто.

Что входит в регрессионный набор:

• Тест-кейсы для ключевых функций всей системы
• Тест-кейсы для областей, смежных с изменением
• Ранее найденные и исправленные баги (чтобы они не вернулись)

Характеристики:

• Широкое покрытие
• Может занимать много времени — поэтому часто автоматизируют
• Запускается регулярно (при каждом релизе, часто — при каждом слиянии кода)

Сравнение трёх видов

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

При получении нового билда с исправлениями:

1. Smoke-тест → билд стабилен?
   Нет → вернуть разработчику
   Да ↓
2. Retest → конкретные баги исправлены?
3. Regression → ничего не сломалось в других местах?

Распространённые ошибки

• Путать retest и regression. Retest — только конкретный баг. Regression — вся система.
• Пропускать smoke-тест. Тратить часы на тестирование нестабильного билда — потеря времени.
• Не делать регрессию после «маленьких» исправлений. Маленькие изменения тоже ломают систему.

Что запомнить

• Smoke — быстрая проверка «живёт ли билд» перед полным тестированием
• Retest — проверка конкретного исправленного бага по тем же шагам
• Regression — широкая проверка, что изменения не сломали существующий функционал
• Правильный порядок: Smoke → Retest → Regression