Функциональное, нефункциональное, smoke, sanity, regression, retest

На старте карьеры QA легко запутаться в терминах: functional, non-functional, smoke, sanity, regression, retest. Они часто звучат рядом, но отвечают за разные задачи. Чтобы не путаться, полезно смотреть на них не как на набор слов для собеседования, а как на разные цели тестирования в реальной работе команды.

Функциональное тестирование

Функциональное тестирование проверяет, что система делает то, что должна делать по требованиям. Работает ли логин, создается ли заказ, отправляется ли письмо, правильно ли считает калькулятор — все это функциональные проверки. Здесь главный вопрос: корректно ли реализовано поведение системы?

→Функциональное тестирование опирается на требования и бизнес-логику.
→Оно отвечает за корректность действий и результатов.

Нефункциональное тестирование

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

→Функционально правильно не всегда значит качественно.
→Нефункциональные риски часто критичны для бизнеса.

Smoke testing

Smoke testing — это короткая быстрая проверка того, что сборка вообще жива и ключевые функции работают на базовом уровне. После нового билда команда часто сначала гоняет smoke, а уже потом решает, идти ли глубже в тестирование.

→Smoke отвечает на вопрос: сборка пригодна для дальнейшей проверки?
→Обычно smoke проверяет самые критичные пользовательские пути.

Sanity testing

Sanity testing — это быстрая проверка конкретной области после изменений. Например, после фикса скидок в корзине QA не гоняет весь продукт, а проверяет, что именно измененная зона ведет себя разумно. Sanity уже уже по охвату, чем regression, и обычно идет после точечных доработок.

→Sanity — это узкая проверка здравого смысла после изменения.
→Она полезна после багфиксов и локальных доработок.

Regression testing

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

→Regression защищает уже работавший функционал.
→Его состав должен опираться на риски и историю дефектов.

Retest

Retest — это повторная проверка конкретного дефекта после его исправления. Если regression отвечает на вопрос не поломали ли что-то вокруг, то retest отвечает на вопрос исправили ли именно эту проблему. Эти два типа проверки часто выполняются рядом, но это не одно и то же.

→Retest проверяет конкретный фикс.
→Regression проверяет побочные последствия изменений.

Как это выглядит на практике

На реальном проекте после нового билда команда может сначала сделать smoke. Если все живо, QA идет в sanity по измененной функциональности, затем делает retest по исправленным дефектам, а перед релизом или по крупному обновлению выполняет regression. Параллельно могут существовать и нефункциональные проверки — например, performance или security.

→Один и тот же релиз может включать сразу несколько типов тестирования.
→Полезно думать не терминами, а целями каждой проверки.

Вывод

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