Smoke-, sanity-, regression- и e2e-тестирование — это не альтернативные подходы, а разные по назначению виды проверок одной и той же системы, которые применяются на разных этапах работы с ней. Smoke отвечает на вопрос «стоит ли вообще начинать тестировать эту сборку», sanity — «не сломалось ли конкретное изменение», regression — «не сломалось ли что-то ещё во всём остальном приложении», а e2e — «работает ли весь пользовательский сценарий от начала до конца через все части системы».
Что такое smoke-тестирование?
Smoke-тестирование — это быстрая проверка самых критичных функций системы сразу после получения новой сборки, цель которой не найти все баги, а убедиться, что сборка вообще пригодна для дальнейшего, более подробного тестирования. Название пришло из электроники: если после включения устройства из него пошёл дым — очевидно, что дальше проверять нечего, нужно разбираться с базовой поломкой. В программном обеспечении аналог — приложение вообще запускается, главная страница открывается, авторизация работает: если нет, вся сборка возвращается разработчикам без траты времени на детальное тестирование остальных функций.
Что такое sanity-тестирование?
Sanity-тестирование — узкая по охвату, но при этом достаточно тщательная проверка конкретной функции или недавнего изменения: в отличие от smoke, sanity не пытается охватить всё приложение, зато внимательнее смотрит именно на изменённую область. Обычно проводится сразу после того, как разработчик исправил конкретный баг или внёс небольшое изменение. Цель — быстро подтвердить, что это конкретное изменение работает и не сломало напрямую связанные с ним вещи, без полной проверки всего приложения. Sanity-тест обычно не документируется заранее подробным тест-кейсом — это исследовательская, точечная проверка «на здравый смысл» (отсюда и название), выполняемая сразу после получения информации об изменении.
Что такое регрессионное тестирование?
Регрессионное тестирование — это широкая проверка, что уже работавшая функциональность не сломалась из-за нового кода, будь то новая фича, исправление другого бага или рефакторинг. В отличие от smoke и sanity, регрессия стремится к максимальной полноте покрытия в рамках имеющегося времени — часто выполняется по заранее подготовленному набору тест-кейсов (регрессионному набору), который со временем растёт вместе с приложением. Именно регрессионное тестирование чаще всего автоматизируют в первую очередь — оно наиболее объёмное, повторяется от релиза к релизу почти без изменений и поэтому даёт наибольшую отдачу от вложений в автотесты.
Что такое end-to-end (e2e) тестирование?
End-to-end-тестирование проверяет полный пользовательский сценарий от начала до конца, проходя через все части системы, которые в нём реально участвуют — например, сценарий «оформить заказ» может затрагивать интерфейс, backend, платёжный шлюз, отправку email-уведомления и обновление статуса в базе данных. В отличие от unit- или интеграционного тестирования, где проверяется отдельный компонент или связка двух компонентов изолированно, e2e-тест намеренно не изолирует части системы друг от друга — он воспроизводит то, что реально происходит с точки зрения пользователя, когда все компоненты работают вместе.
Чем smoke отличается от sanity?
Smoke и sanity — оба быстрые виды проверок, не претендующие на полноту покрытия, но различаются по охвату, глубине и моменту применения. Smoke выполняется в начале цикла тестирования новой сборки и проверяет широкий, но неглубокий набор критичных функций всего приложения — «всё ли вообще работает на базовом уровне». Sanity выполняется после конкретного изменения и, наоборот, проверяет узкую область, зато внимательнее — «работает ли именно то, что поменяли, и не задело ли это что-то рядом». Проще говоря: smoke — широкий и поверхностный, sanity — узкий, но более пристальный. Smoke отвечает на вопрос «можно ли вообще начинать тестировать», sanity — «можно ли уже закрывать эту конкретную задачу как исправленную».
Чем sanity отличается от регрессионного тестирования?
Главное отличие — в охвате, а не в тщательности проверки: sanity узкий (проверяет только то, что напрямую связано с конкретным изменением), а регрессия широкая (охватывает функциональность всего приложения, включая области, формально не связанные с последним изменением напрямую). Sanity-тест занимает минуты, тогда как регрессионный набор может занимать часы — или требовать автоматизации, чтобы вообще быть выполнимым за разумное время. На практике команды часто проводят sanity сразу после фикса, чтобы быстро решить, стоит ли вообще запускать полную регрессию: если sanity уже показал явную проблему, гонять весь регрессионный набор пока преждевременно.
Какой вид тестирования когда применять?
Каждый из четырёх видов закрывает свою задачу и не заменяет остальные — ниже прямое сравнение всех четырёх по ключевым параметрам:
— Smoke — когда применять: сразу после получения новой сборки, решить, пригодна ли она для дальнейшего тестирования вообще. Глубина проверки: широкая, но неглубокая, только самые критичные функции. Кто обычно запускает: QA-инженер вручную или автоматически в CI/CD сразу после сборки.
— Sanity — когда применять: сразу после того, как разработчик исправил конкретный баг или внёс точечное изменение. Глубина проверки: узкая по охвату, но тщательная в рамках этой конкретной области. Кто обычно запускает: QA-инженер, проверяющий именно этот фикс, обычно вручную.
— Regression — когда применять: перед релизом или после значительных изменений, когда нужна широкая уверенность, что ничего из уже работавшего не сломалось. Глубина проверки: широкая и по возможности глубокая, по заранее подготовленному набору тест-кейсов. Кто обычно запускает: QA-команда, часто через автотесты.
— E2E — когда применять: когда нужно подтвердить, что критичный пользовательский сценарий целиком работает через все реальные компоненты системы. Глубина проверки: максимальная в рамках сценария, весь путь пользователя от начала до конца. Кто обычно запускает: QA-инженер вручную или автотесты (например, на Playwright), обычно перед релизом.
— Smoke — когда применять: сразу после получения новой сборки, решить, пригодна ли она для дальнейшего тестирования вообще. Глубина проверки: широкая, но неглубокая, только самые критичные функции. Кто обычно запускает: QA-инженер вручную или автоматически в CI/CD сразу после сборки.
— Sanity — когда применять: сразу после того, как разработчик исправил конкретный баг или внёс точечное изменение. Глубина проверки: узкая по охвату, но тщательная в рамках этой конкретной области. Кто обычно запускает: QA-инженер, проверяющий именно этот фикс, обычно вручную.
— Regression — когда применять: перед релизом или после значительных изменений, когда нужна широкая уверенность, что ничего из уже работавшего не сломалось. Глубина проверки: широкая и по возможности глубокая, по заранее подготовленному набору тест-кейсов. Кто обычно запускает: QA-команда, часто через автотесты.
— E2E — когда применять: когда нужно подтвердить, что критичный пользовательский сценарий целиком работает через все реальные компоненты системы. Глубина проверки: максимальная в рамках сценария, весь путь пользователя от начала до конца. Кто обычно запускает: QA-инженер вручную или автотесты (например, на Playwright), обычно перед релизом.
Какие вопросы про виды тестирования чаще всего возникают?
Можно ли автоматизировать все четыре вида тестирования? Да, но с разной степенью оправданности: регрессионные и smoke-тесты автоматизируют чаще всего, потому что они повторяются практически без изменений от прогона к прогону и приносят наибольшую экономию времени при автоматизации. Sanity-тесты автоматизируют реже, потому что они разовые и завязаны на конкретное точечное изменение — писать автотест ради одной проверки часто дороже, чем просто проверить руками. E2E-тесты автоматизируют избирательно, обычно для самых критичных пользовательских сценариев (оформление заказа, регистрация, оплата), потому что они медленные и хрупкие по своей природе — чем больше компонентов задействовано, тем больше точек, где тест может упасть по причине, не связанной с реальным багом.
Регрессионное тестирование — это то же самое, что полное тестирование всего приложения? Нет, «полное» тестирование в строгом смысле почти никогда не проводится заново на каждый релиз — это заняло бы неприемлемо много времени. Регрессионный набор обычно фокусируется на уже известной, стабилизировавшейся функциональности и критичных сценариях, а не буквально на каждой возможной комбинации входных данных во всём приложении — в этом смысле регрессия шире smoke и sanity, но всё равно является выборкой, а не исчерпывающей проверкой.
Что делать, если smoke-тест провалился? Сборка возвращается разработчикам без траты времени на дальнейшее, детальное тестирование — в этом и смысл smoke: не искать мелкие баги там, где базово всё сломано. Продолжать sanity или регрессию поверх проваленного smoke бессмысленно — результаты всё равно окажутся бесполезны, пока не исправлена причина провала.
Правда ли, что smoke-тестирование иногда называют build verification test (BVT), и в каком порядке эти проверки идут в реальном CI/CD-пайплайне? Да, BVT — фактически тот же smoke-тест, только термин исторически закрепился за автоматизированной проверкой, встроенной прямо в сборку: собрали билд → сразу прогнали BVT/smoke → если прошёл, билд допускается к дальнейшему тестированию. Типичный порядок в пайплайне такой: сборка → smoke (BVT), обычно автоматический → sanity точечно, вручную после конкретных фиксов → регрессия перед релизом, по возможности автоматизированная → e2e на самых критичных сценариях как последний рубеж перед выкладкой. На собеседовании smoke и BVT можно считать синонимами — разница скорее в контексте употребления, а не в сути проверки.
Чем e2e-тестирование отличается от интеграционного? Интеграционное тестирование проверяет взаимодействие двух или нескольких конкретных компонентов в изоляции от остальной системы (например, что backend корректно обрабатывает запрос от frontend, без реальной проверки, что происходит дальше с платежами или email). E2e-тестирование не изолирует ничего — оно проходит через весь реальный путь пользователя, задействуя все системы, которые в нём реально участвуют, включая внешние интеграции. E2e даёт наибольшую уверенность в реальной работоспособности, но и наиболее дорог и хрупок — падение может произойти из-за любого из множества задействованных компонентов, и локализовать причину сложнее, чем в изолированном интеграционном тесте.
Нужно ли проводить sanity-тестирование, если и так планируется полная регрессия? Да, это не взаимоисключающие активности, а последовательные шаги: sanity выполняется сразу после получения фикса, чтобы быстро понять, стоит ли вообще запускать регрессию именно сейчас. Если пропустить sanity и сразу запускать долгую регрессию на сборке, где фикс в принципе не работает, время на регрессию будет потрачено впустую — её всё равно придётся повторять после реального исправления.
Регрессионное тестирование — это то же самое, что полное тестирование всего приложения? Нет, «полное» тестирование в строгом смысле почти никогда не проводится заново на каждый релиз — это заняло бы неприемлемо много времени. Регрессионный набор обычно фокусируется на уже известной, стабилизировавшейся функциональности и критичных сценариях, а не буквально на каждой возможной комбинации входных данных во всём приложении — в этом смысле регрессия шире smoke и sanity, но всё равно является выборкой, а не исчерпывающей проверкой.
Что делать, если smoke-тест провалился? Сборка возвращается разработчикам без траты времени на дальнейшее, детальное тестирование — в этом и смысл smoke: не искать мелкие баги там, где базово всё сломано. Продолжать sanity или регрессию поверх проваленного smoke бессмысленно — результаты всё равно окажутся бесполезны, пока не исправлена причина провала.
Правда ли, что smoke-тестирование иногда называют build verification test (BVT), и в каком порядке эти проверки идут в реальном CI/CD-пайплайне? Да, BVT — фактически тот же smoke-тест, только термин исторически закрепился за автоматизированной проверкой, встроенной прямо в сборку: собрали билд → сразу прогнали BVT/smoke → если прошёл, билд допускается к дальнейшему тестированию. Типичный порядок в пайплайне такой: сборка → smoke (BVT), обычно автоматический → sanity точечно, вручную после конкретных фиксов → регрессия перед релизом, по возможности автоматизированная → e2e на самых критичных сценариях как последний рубеж перед выкладкой. На собеседовании smoke и BVT можно считать синонимами — разница скорее в контексте употребления, а не в сути проверки.
Чем e2e-тестирование отличается от интеграционного? Интеграционное тестирование проверяет взаимодействие двух или нескольких конкретных компонентов в изоляции от остальной системы (например, что backend корректно обрабатывает запрос от frontend, без реальной проверки, что происходит дальше с платежами или email). E2e-тестирование не изолирует ничего — оно проходит через весь реальный путь пользователя, задействуя все системы, которые в нём реально участвуют, включая внешние интеграции. E2e даёт наибольшую уверенность в реальной работоспособности, но и наиболее дорог и хрупок — падение может произойти из-за любого из множества задействованных компонентов, и локализовать причину сложнее, чем в изолированном интеграционном тесте.
Нужно ли проводить sanity-тестирование, если и так планируется полная регрессия? Да, это не взаимоисключающие активности, а последовательные шаги: sanity выполняется сразу после получения фикса, чтобы быстро понять, стоит ли вообще запускать регрессию именно сейчас. Если пропустить sanity и сразу запускать долгую регрессию на сборке, где фикс в принципе не работает, время на регрессию будет потрачено впустую — её всё равно придётся повторять после реального исправления.
Где разобраться в видах тестирования на практике?
Разница между smoke и sanity — из тех вещей, которые на словах путают даже опытные тестировщики, а на реальном проекте с настоящими сборками и настоящими багами укладываются в голове гораздо быстрее. В Quality Academy на курсе «Инженер по ручному тестированию» эти понятия разбираются не абстрактно, а на 75+ практических домашних заданиях в Jira с проверкой ментора — и регулярно всплывают на тирах (3 раза в неделю), где тренируются объяснять разницу вслух, ровно как на настоящем собеседовании.
-------
Полезные ссылки школы
Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena