Среди часто используемых терминов в QA встречаются Smoke testing, Regression testing и Sanity testing. Их нередко путают, особенно начинающие тестировщики, потому что все три вида тестирования связаны с проверкой работоспособности программного продукта.

Однако задачи у них разные.

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

Разберём каждый вид тестирования подробно и сравним их между собой.

Что такое Smoke testing?

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

Главная задача Smoke testing — быстро ответить на вопрос:

Можно ли продолжать тестировать эту сборку или в ней есть критические проблемы?

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

Например, представим интернет-магазин. После выхода новой сборки тестировщик может проверить:

• открывается ли сайт;
• работает ли авторизация;
• отображается ли каталог;
• открывается ли карточка товара;
• можно ли добавить товар в корзину;
• работает ли переход к оформлению заказа.

Если сайт не открывается или пользователь вообще не может войти в аккаунт, проводить десятки других тестов может быть бессмысленно.

В таком случае сборка может быть отклонена и возвращена разработчикам.

Почему тестирование называется Smoke testing?

Название происходит от аналогии с проверкой электроники или оборудования.

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

В программном обеспечении ситуация похожая: если основные функции приложения не работают, команда сначала должна исправить критические проблемы.

Цели Smoke testing

Основные задачи Smoke testing:

1. Проверить стабильность новой сборки.
2. Найти критические ошибки на раннем этапе.
3. Убедиться, что приложение запускается.
4. Проверить ключевые пользовательские сценарии.
5. Решить, можно ли передавать сборку на дальнейшее тестирование.
6. Сэкономить время QA-команды.

Smoke testing особенно полезно проводить после получения новой версии приложения от разработчиков.

Когда проводится Smoke testing?

Smoke testing обычно выполняется после появления новой сборки продукта.

Например:

Разработчики → новая сборка → Smoke testing → дальнейшее тестирование

Если Smoke testing пройден успешно, QA-команда может переходить к более подробным проверкам.

Если обнаружены критические проблемы, сборку могут вернуть разработчикам.

Smoke testing может выполняться:

• после нового билда;
• после значительных изменений;
• перед началом основного цикла тестирования;
• после развёртывания новой версии;
• в рамках CI/CD-процесса.

Пример Smoke testing

Представим мобильное приложение интернет-банка.

После выхода новой версии тестировщик выполняет несколько быстрых проверок:

1. Приложение устанавливается.
2. Приложение запускается.
3. Пользователь может войти в аккаунт.
4. Отображается баланс.
5. Открывается список операций.
6. Работает перевод денег.
7. Пользователь может выйти из аккаунта.

Если все основные функции работают, можно переходить к более подробному тестированию.

При этом тестировщик пока не обязан проверять каждую настройку профиля, все возможные варианты переводов или редкие сценарии.

Что такое Regression testing?

Regression testing, или регрессионное тестирование, — это проверка уже существующего функционала после внесения изменений в программный продукт.

Основной вопрос здесь:

Не сломали ли новые изменения то, что раньше работало?

Любое изменение в коде потенциально может повлиять на другие части системы.

Разработчик исправил одну ошибку — и случайно нарушил работу другой функции.

Добавили новый способ оплаты — перестал работать старый.

Изменили форму регистрации — появилась ошибка при восстановлении пароля.

Именно такие ситуации помогает обнаруживать Regression testing.

Зачем нужно Regression testing?

Современные программные продукты постоянно изменяются.

Разработчики:

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

Каждое изменение может повлиять на уже существующий функционал.

Поэтому после внесения изменений необходимо убедиться, что старые возможности продолжают работать.

Пример Regression testing

Представим интернет-магазин.

Команда добавила возможность оплаты банковской картой.

После этого необходимо проверить не только новую оплату, но и существующие функции:

• регистрация;
• авторизация;
• каталог;
• поиск;
• фильтры;
• карточка товара;
• корзина;
• промокоды;
• оформление заказа;
• доставка;
• личный кабинет;
• история заказов.

Почему?

Потому что новый код может неожиданно повлиять на уже существующие компоненты.

Например, после изменения модуля оплаты перестала применяться скидка по промокоду.

Это и есть типичная регрессионная ошибка.

Регрессионное тестирование и автоматизация

Regression testing часто хорошо подходит для автоматизации.

Представим, что в проекте уже есть 1000 автоматизированных тестов.

После внесения изменений тестировщик может запустить их повторно и проверить, не появились ли новые проблемы.

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

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

Что такое Sanity testing?

Sanity testing — это узкая проверка конкретной области приложения после небольших изменений или исправлений.

Главный вопрос Sanity testing:

Работает ли конкретный изменённый функционал так, как ожидается?

В отличие от Regression testing, здесь обычно не проверяется весь продукт.

Тестировщик концентрируется на определённой области.

Пример Sanity testing

Представим, что в интернет-магазине была обнаружена ошибка:

Промокод не применяется при оформлении заказа.

Разработчик исправил эту проблему.

После получения новой сборки тестировщик может выполнить Sanity testing:

1. Добавить товар в корзину.
2. Перейти к оформлению заказа.
3. Ввести промокод.
4. Проверить применение скидки.
5. Убедиться, что итоговая сумма рассчитана правильно.

Если промокод теперь работает, конкретное исправление можно считать успешно проверенным.

Затем команда может перейти к более широкому Regression testing.

Чем Sanity testing отличается от Regression testing?

Главное отличие заключается в масштабе.

Sanity testing обычно сосредоточено на конкретной изменённой области.

Regression testing охватывает более широкий набор существующего функционала.

Например, разработчик исправил форму регистрации.

Sanity testing может включать:

• регистрацию нового пользователя;
• проверку обязательных полей;
• создание аккаунта;
• отображение сообщения об успешной регистрации.

Regression testing может дополнительно проверить:

• авторизацию;
• восстановление пароля;
• личный кабинет;
• редактирование профиля;
• выход из аккаунта;
• связанные пользовательские сценарии.

Smoke testing vs Sanity testing

Эти два вида тестирования особенно часто путают.

Разница заключается прежде всего в цели.

Smoke testing

Проверяет:

«Работает ли сборка в целом?»

Sanity testing

Проверяет:

«Работает ли конкретная изменённая часть?»

Smoke testing имеет более широкий, но поверхностный характер.

Sanity testing обычно более узкое и сфокусированное.

Smoke testing vs Regression testing

Smoke testing отвечает на вопрос:

«Можно ли вообще тестировать эту сборку?»

Regression testing отвечает на вопрос:

«Не сломали ли изменения уже существующий функционал?»

Например, новая сборка приложения поступила в QA.

Сначала тестировщик может выполнить Smoke testing.

Если приложение запускается и основные функции работают, начинается дальнейшее тестирование.

После изменений команда проводит Regression testing, чтобы убедиться, что существующие функции продолжают работать.

Sanity testing vs Regression testing

Здесь отличие прежде всего в объёме.

Сравнение Smoke, Sanity и Regression testing

Чтобы окончательно разобраться в различиях, рассмотрим все три вида тестирования одновременно.

Как эти виды тестирования могут работать вместе?

Smoke, Sanity и Regression testing не обязательно являются взаимоисключающими подходами.

На реальном проекте они могут использоваться последовательно.

Представим, что команда разрабатывает интернет-магазин.

Разработчики выпустили новую сборку.

Шаг 1. Smoke testing

Тестировщик проверяет:

• запускается ли сайт;
• работает ли авторизация;
• открывается ли каталог;
• работает ли корзина;
• можно ли оформить заказ.

Если критическая функция не работает, сборка возвращается разработчикам.

Шаг 2. Sanity testing

Разработчики исправили конкретную ошибку в корзине.

Тестировщик проверяет именно этот функционал:

• добавление товара;
• изменение количества;
• удаление товара;
• расчёт стоимости.

Если исправление работает, можно двигаться дальше.

Шаг 3. Regression testing

После изменений команда запускает более широкий набор проверок:

• регистрация;
• авторизация;
• поиск;
• каталог;
• фильтры;
• корзина;
• промокоды;
• оплата;
• доставка;
• личный кабинет.

Цель — убедиться, что изменения не вызвали проблем в других частях системы.

Какие ошибки часто допускают начинающие тестировщики?

Ошибка 1. Считать Smoke testing полным тестированием

Smoke testing не заменяет полноценное тестирование.

Его задача — быстро проверить основные функции.

Если Smoke testing пройден, это ещё не означает, что приложение полностью исправно.

Ошибка 2. Путать Smoke и Sanity testing

Запомнить различие можно с помощью двух вопросов:

Smoke:
«Можно ли продолжать тестировать эту сборку?»

Sanity:
«Работает ли конкретное изменение?»

Ошибка 3. Проверять только новую функцию при Regression testing

Регрессионное тестирование как раз направлено на поиск проблем в уже существующем функционале.

Если добавили новую форму оплаты, недостаточно проверить только её.

Необходимо подумать, какие существующие функции могут быть затронуты изменениями.

Ошибка 4. Считать Regression testing только ручным

Регрессионные проверки часто автоматизируют.

Это особенно актуально для проектов, где функционал регулярно меняется, а количество тестов постоянно увеличивается.

Ошибка 5. Не учитывать взаимосвязи между функциями

В сложных системах компоненты связаны между собой.

Например:

регистрация → авторизация → личный кабинет → заказ → оплата → уведомление.

Изменение одного компонента может повлиять на другие.

Поэтому тестировщик должен понимать не только отдельную функцию, но и связи между частями системы.

Что должен знать начинающий QA-инженер?

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

Хороший фундамент QA включает несколько направлений.

Основы тестирования

Нужно понимать:

• что такое тестирование;
• зачем оно нужно;
• какие бывают виды тестирования;
• что такое тест-кейс;
• что такое чек-лист;
• что такое баг-репорт;
• как описывать дефекты.

Тест-дизайн

Полезно изучить:

• классы эквивалентности;
• анализ граничных значений;
• таблицы решений;
• диаграммы состояний;
• позитивные и негативные сценарии.

Работа с багами

QA-инженер должен уметь правильно описывать найденную проблему.

Хороший баг-репорт обычно содержит:

• краткое описание;
• шаги воспроизведения;
• ожидаемый результат;
• фактический результат;
• окружение;
• приоритет;
• серьёзность.

API и HTTP

Современному тестировщику полезно понимать:

• HTTP-запросы;
• HTTP-методы;
• статус-коды;
• JSON;
• API;
• REST;
• работу с инструментами для тестирования API.

DevTools

Браузерные инструменты разработчика помогают анализировать:

• сетевые запросы;
• ошибки JavaScript;
• cookies;
• local storage;
• HTTP-заголовки;
• ответы сервера.

Автоматизация

После освоения основ ручного тестирования можно переходить к автоматизации.

В зависимости от проекта используются разные языки программирования и инструменты автоматизированного тестирования.

Smoke, Sanity и Regression testing: что важно запомнить?

Можно использовать простую схему:

Smoke testing

Широко → быстро → основные функции

Цель: понять, можно ли тестировать сборку.

Sanity testing

Узко → конкретно → изменённая область

Цель: проверить, работает ли конкретное исправление или изменение.

Regression testing

Широко → существующий функционал → поиск побочных эффектов

Цель: убедиться, что новые изменения ничего не сломали.

Если запомнить эту разницу, ориентироваться в основных видах тестирования становится значительно проще.

FAQ: часто задаваемые вопросы

Что такое Smoke testing простыми словами?

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

Что такое Regression testing?

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

Что такое Sanity testing?

Sanity testing — сфокусированная проверка конкретной функциональной области после небольших изменений или исправлений.

Что сначала: Smoke или Regression testing?

Обычно сначала имеет смысл убедиться, что сборка вообще пригодна для тестирования, поэтому Smoke testing может предшествовать более подробным проверкам. Конкретный порядок зависит от процесса разработки и тестирования в проекте.

Можно ли автоматизировать Smoke testing?

Да. Smoke-тесты можно автоматизировать, особенно если набор основных проверок повторяется при каждом новом билде.

Можно ли автоматизировать Regression testing?

Да. Regression testing часто автоматизируют, поскольку регрессионный набор может содержать большое количество повторяющихся тестов.

Чем Smoke testing отличается от Sanity testing?

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

Какой вид тестирования сложнее?

У Smoke, Sanity и Regression testing разные задачи, поэтому некорректно просто считать один из них «сложнее». Сложность зависит от проекта, количества функций, связей между компонентами и объёма тестов.

Smoke testing, Regression testing и Sanity testing — три важных понятия, которые необходимо знать начинающему QA-инженеру.

Smoke testing помогает быстро определить, пригодна ли новая сборка для дальнейшей проверки. Sanity testing позволяет сфокусироваться на конкретном изменении или исправлении. Regression testing помогает убедиться, что новые изменения не повредили уже существующий функционал.

На практике эти подходы дополняют друг друга. Вместе они помогают QA-команде быстрее находить проблемы и поддерживать качество программного продукта на разных этапах разработки.

Если вы планируете начать карьеру в тестировании, важно изучать не только отдельные термины, но и весь процесс QA: от составления тест-кейсов и поиска багов до работы с API, DevTools и автоматизированными тестами.

В IT ШАГ можно изучать тестирование на практике, знакомиться с инструментами QA и постепенно формировать навыки, необходимые для работы в IT.