Manual Testing

БЛОК 8. Процессы тестирования — 24. Smoke, Sanity и Regression testing

📚 25 вопросовПройти тест →
Лекция

БЛОК 8. Процессы тестирования — 24. Smoke, Sanity и Regression testing

Manual Testing

БЛОК 8. Процессы тестирования — 24. Smoke, Sanity и Regression testing

🧭 Введение: зачем QA различать Smoke, Sanity и Regression

Это три похожих слова, которые в работе часто путают.
Из-за путаницы команда либо тратит лишние часы на «слишком глубокий» прогон, либо пропускает критичные риски перед релизом.
💡 Совет:
Перед запуском тестов сначала сформулируй цель прогона в одной фразе.
✅ Вывод:
Smoke, Sanity и Regression — это не «термины ради терминов», а три разных инструмента под три разные цели.

⚠️ Проблема -> решение

Проблема: junior QA часто называет любой набор проверок словом «регресс».
В итоге коммуникация ломается: команда не понимает, что реально проверили.
Решение: использовать простой рабочий выбор по ситуации:
  • Smoke — новый build, нужно понять, можно ли вообще тестировать дальше;
  • Retest + Sanity — пришёл фикс, нужно подтвердить исправление и проверить соседнюю зону;
  • Regression — нужно убедиться, что старый функционал не деградировал после изменений.
🟢 Если совсем просто:
Smoke = «сборка тестопригодна?»
Sanity = «исправили именно нужную область?»
Regression = «старое не сломали?»
🎯 Как понять, что этап прошел успешно:
В отчёте QA видно не только результат, но и цель прогона.

🛠️ Чем помогает и как работает

Эта модель помогает быстро принимать понятные релизные решения без хаоса.
Логика простая: сначала входной фильтр сборки, потом проверка фикса, потом защита от побочных поломок.
Как это работает:
  • Шаг 1: новый build -> Smoke.
  • Шаг 2: фикс бага -> Retest, затем Sanity.
  • Шаг 3: перед релизом/после крупных изменений -> Regression.
  • Шаг 4: QA summary -> рекомендация по релизу.
✅ Вывод:
Правильный порядок прогонов экономит время и снижает риск «аварийного» релиза.

📚 Ключевые термины (простыми словами)

  • Smoke testing — короткий базовый прогон, чтобы понять, пригодна ли сборка к дальнейшему тестированию.
  • Retest — повторная проверка конкретного бага после фикса.
  • Sanity testing — узкий прогон по изменённой зоне и рядом с ней после фикса/патча.
  • Regression testing — проверка ранее рабочего функционала после изменений.
  • Targeted regression — выборочный regression по зонам риска.
  • Full regression — максимально широкий регрессионный прогон.

1. Smoke testing

Smoke нужен первым на новом build.
🟢 Если совсем просто:
Smoke — это «входной фильтр» сборки.
🎯 Как понять, что этап прошел успешно:
Критичный поток запускается, блокеров старта нет.
Назначение:
Быстро отсечь «неживые» сборки.
Простыми словами:
Короткая проверка «дышит / не дышит».
Для новичка:
Smoke не должен превращаться в мини-регрессию.
Пример:
  • логин доступен;
  • корзина открывается;
  • checkout открывается;
  • базовый платежный запрос не падает в 500.
🔎 Как это происходит на практике:
QA запускает фиксированный короткий checklist и принимает бинарное решение: pass/fail.
⚠️ Важно:
Smoke не подтверждает качество релиза.
Он подтверждает только то, что сборку есть смысл тестировать дальше.
✅ Вывод:
Smoke экономит часы работы, потому что рано ловит непригодные сборки.

2. Sanity testing

Sanity запускают после изменения в конкретной зоне.
🟢 Если совсем просто:
Sanity — это прицельная проверка изменённой области.
🎯 Как понять, что этап прошел успешно:
Фикс работает, а соседние сценарии в этой зоне не сломаны.
Назначение:
Проверить изменение глубже, чем smoke, но уже, чем regression.
Простыми словами:
«Посмотреть вокруг фикса», а не только в одну точку.
⚠️ Важно: Retest vs Sanity
Retest — это перепроверка конкретного бага после фикса.
Sanity — это проверка изменённой зоны и ближайших рисков после этого фикса.
🧩 Рабочая последовательность после фикса:
  • баг исправили;
  • делаем Retest исходного сценария;
  • делаем Sanity соседней области;
  • если релизный риск выше — добавляем targeted/full regression.
Пример: Исправили двойное списание при timeout:
  • retest исходного кейса;
  • sanity: double-click pay, retry, статус заказа, журнал транзакций.
✅ Вывод:
Sanity подтверждает не только «баг закрыт», но и «зона изменений стабильна».

3. Regression testing

Regression нужен, когда важно убедиться, что изменения не сломали уже рабочие функции.
🟢 Если совсем просто:
Regression — защита от побочных поломок.
🎯 Как понять, что этап прошел успешно:
Критичные старые потоки после изменений остаются рабочими.
Назначение:
Поймать деградацию в ранее стабильном функционале.
Простыми словами:
Проверка «старое всё ещё работает».
Для новичка:
Regression может быть полным или целевым (targeted), и это нормальный выбор по риску.
Пример: После изменений в checkout проверяют:
  • платежи;
  • промокоды;
  • историю заказов;
  • возвраты.
✅ Вывод:
Regression — главный инструмент контроля риска перед выкладкой.

4. Сравнение Smoke vs Sanity vs Regression

Эти процессы не заменяют друг друга: у каждого своя задача и своя глубина.
🟢 Если совсем просто:
Не «что круче», а «что уместно в текущей ситуации».
🎯 Как понять, что этап прошел успешно:
QA может объяснить выбор процесса одной фразой.
ПроцессГлавный вопросОхватГлубинаКогда запускать
SmokeСборка тестопригодна?ШирокийНеглубокийНа новый build
SanityИзменённая зона работает?УзкийГлубже в зоне измененияПосле fix/patch
RegressionСтарое не сломали?Широкий/выборочныйГлубокий по рискамПеред релизом/после крупных изменений
📏 Мини-правило глубины:
Smoke — широкий, но неглубокий.
Sanity — узкий, но глубже в зоне изменений.
Regression — широкий/выборочный и глубже по рискам.
✅ Вывод:
Сильный QA выбирает процесс по цели, а не по привычке.

5. Как выбрать быстро: decision-rule для junior

Это короткий алгоритм, который реально работает каждый день.
🟢 Если совсем просто:
Сначала вопрос «что именно мне сейчас нужно доказать?».
🎯 Как понять, что этап прошел успешно:
Тип прогона выбран без споров и двусмысленности.
🧩 Мини-чеклист выбора процесса:
  • новый build -> Smoke;
  • проверка фикса -> Retest + Sanity;
  • нужно проверить, не сломали ли старое -> Regression;
  • мало времени -> Targeted regression по риску.
✅ Вывод:
Чёткое правило выбора убирает «туманные» формулировки в отчётах.

6. Full vs Targeted regression: когда что нужно

Полный regression нужен не всегда.
В большинстве релизов достаточно правильно собранного targeted regression.
🟢 Если совсем просто:
Чем выше риск и шире изменения, тем шире регрессионный прогон.
🎯 Как понять, что этап прошел успешно:
Объём regression обоснован риском, а не «на всякий случай».
Когда обычно хватает targeted regression:
  • изменение локальное;
  • зона затронута ограниченно;
  • shared/core логика не менялась;
  • релизный риск умеренный.
Когда ближе к full regression:
  • крупный релиз;
  • рефакторинг общих модулей;
  • изменения в критичных потоках (оплата, логин, доступы);
  • высокий риск побочных эффектов.
✅ Вывод:
Правильный regression — это не «самый большой», а «самый уместный по риску».

7. Где junior чаще ошибается

Ошибки чаще процессные, а не технические.
🟢 Если совсем просто:
Главная ошибка — неправильно назвать и выбрать тип прогона.
🎯 Как понять, что этап прошел успешно:
По QA-отчёту видно: цель, охват, ограничения и итог.
Типичные ловушки:
  • называть любой набор проверок «регрессом»;
  • считать, что Smoke pass = «релиз готов»;
  • ограничиваться только retest и называть это sanity;
  • делать full regression без обоснования по риску;
  • не фиксировать, был regression full или targeted.
✅ Вывод:
Точные названия процессов = точная коммуникация и меньше релизных ошибок.

📌 Must-know факты

  • Smoke проверяет пригодность сборки, а не качество релиза.
  • Retest и sanity — не одно и то же.
  • Sanity обычно идёт после retest бага.
  • Regression нужен для защиты от побочных поломок.
  • Full/targeted regression выбирается по риску.

❗ Частые мифы

❌ Миф: Smoke = быстрый regression.
✅ Как правильно: Smoke — только входной фильтр тестопригодности.
📎 Почему это важно: Иначе команда теряет скорость на раннем этапе.
❌ Миф: Retest и sanity — одно и то же.
✅ Как правильно: Retest проверяет конкретный баг, sanity проверяет зону изменений вокруг него.
📎 Почему это важно: Без sanity можно пропустить побочные поломки рядом с фиксом.
❌ Миф: Если sanity прошёл, regression не нужен.
✅ Как правильно: Sanity локальный, regression проверяет более широкий риск.
📎 Почему это важно: Иначе релиз уходит с незамеченными регрессиями.
❌ Миф: Regression всегда должен быть полным.
✅ Как правильно: Часто достаточно targeted regression, если риск ограничен.
📎 Почему это важно: Это балансирует качество и сроки.

Часто спрашивают на собеседованиях

❓ Вопрос: Чем отличается retest от sanity? ✅ Ответ: Retest проверяет конкретный исправленный баг, sanity проверяет изменённую область и соседние риски.
❓ Вопрос: Почему smoke нельзя считать подтверждением качества релиза? ✅ Ответ: Smoke проверяет только базовую тестопригодность сборки, а не полное качество фичи.
❓ Вопрос: Когда выбирать full regression, а когда targeted? ✅ Ответ: Full — при широких/рискованных изменениях, targeted — при локальных изменениях с ограниченным риском.
❓ Вопрос: Какой базовый порядок прогонов после фикса? ✅ Ответ: Retest бага -> sanity в зоне изменений -> при повышенном риске regression.

🚨 Типичные ошибки

❌ Неправильно: После прохождения smoke писать «релиз готов».
✅ Правильно: После smoke писать «сборка тестопригодна», а релизное решение делать после нужной глубины проверок.
❌ Неправильно: Проверить один баг и назвать это sanity.
✅ Правильно: Сначала retest, затем sanity по соседним сценариям в изменённой зоне.
❌ Неправильно: Всегда запускать full regression без оценки риска.
✅ Правильно: Выбирать full или targeted regression по масштабу изменений и релизному риску.

✅ Best Practices

  • Держи короткий стабильный smoke-checklist на каждый build.
  • Разделяй в отчёте Retest и Sanity.
  • Перед regression явно фиксируй: full или targeted.
  • Для targeted regression сначала покрывай критичные бизнес-потоки.
  • В QA summary всегда указывай: что проверено и что осталось риском.

🏁 Заключение

Smoke, Sanity и Regression — это базовая рабочая модель QA-процесса в релизном цикле.
Если правильно выбирать и называть эти прогоны, команда быстрее понимает качество сборки и принимает точные решения по релизу.
✅ Вывод:
Сильный junior QA — это тот, кто не просто «проверил», а может чётко объяснить что проверил, зачем и с каким уровнем риска.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 8. Процессы тестирования — 24. Smoke, Sanity и Regression testing»

Пройти тест →