Дымовое и санитарное тестирование: в чем разница

• Суть
• Дымовое
• Санитарное
• Вопрос на засыпку: может ли быть в одном проекте и санити и дымовое (да)
• Табличка-сравнение для ленивых

Кратко

Хотя термин «санити-тестирование» часто используется как синоним «дымового тестирования», эти понятия не идентичны.

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

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

Дымовое тестирование — значение

Дымовое тестирование, иначе называемое тестирование уверенности (confidence testing), тестирование продвижения билда (build promotion testing) или тестирование верификации билда (build verification testing) — это тип тестирования программного обеспечения, направленный на проверку того, что критические функциональные возможности системы работают так как ожидается, после обновления билда.

Цель «смока» — выявить основные проблемы и определить, является ли билд достаточно стабильным для дальнейшего тестирования. Как объясняют в фундаментальной книге Тестирование программного обеспечения: «Фраза smoke test пришла из тестирования электронного оборудования. Вы подключаете новую плату и включаете питание. Если вы видите, что из платы идет дым, выключайте питание. Пока не нужно проводить тестирование» — есть явные дефекты, требующие внимания.

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

Как применяется эта методика

В основе дымового тестирования лежит достаточно простой процесс, изображенный на картинке ниже:

Процесс начинается с разработки новой фичи, обновлений в ПО, или совершенно новой версии ПО. После завершения этого этапа разработки создается сборка ПО, которая отправляется в CI/CD-конвейер для развертывания.

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

Если дымовые тесты прошли успешно, процесс развертывания продолжается на более узконаправленных этапах тестирования, таких как регрессионные или интеграционные тесты. Напротив, если дымовой набор не прошел, развертывание останавливается. Билд отклоняется и отправляется обратно команде разработчиков, для устранения выявленных проблем. После их устранения создается новый билд, и этот цикл повторяется до тех пор, пока программное обеспечение не пройдет этап дымового тестирования.

Другими словами, дымовое тестирование — это критическая контрольная точка в разработке программного обеспечения. Оно выступает в качестве «первой линии обороны», гарантирующей, что новые билды стабильны и готовы к развертыванию. Это особенно эффективно при наличии автоматизированного конвейера тестирования, так как помогает командам быстро понять, стоит ли продолжать развертывание, или же немедленно остановить его, экономя время и ресурсы.

Пример сценария дымового тестирования

Имеем платформу электронной коммерции, в которой в процесс оформления заказа была добавлена интеграция с новым платежным шлюзом. Команда разработчиков изменила код приложения, чтобы включить этот новый шлюз (который, например, позволяет клиентам выбирать между несколькими способами оплаты).

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

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

В этом сценарии дымовые тесты подтверждают, что приложение по-прежнему работает корректно в новом билде.

Фреймворки и инструменты дымового тестирования

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

Например, в одном приложении ключевыми функциями могут быть конечные точки API, а в другом — корректность процесса входа в систему. Для тестирования конечных точек API будут эффективны такие инструменты, как Postman или Swagger. Если дымовые тесты нацелены на основную бизнес-логику, в таком случае подойдут фреймворки для юнит-тестирования, такие как JUnit, Jest или Mocha. А если смок-тестирование включает верификацию полного пользовательского пути в приложении, хорошим выбором будут такие инструменты, как Playwright, Cypress или Selenium.

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

Преимущества и недостатки смок-тестов

👍 Плюсы:

• Раннее обнаружение критических проблем
• Может выполняться часто и быстро, поскольку как правило это небольшой набор тест-кейсов
• Повышает качество билдов
• Может интегрироваться в CI/CD-конвейер для ускорения автоматизации
• Повышает производительность команд, экономя время благодаря сдвигу влево

👎 Минусы:

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

Теперь перейдем к так называемому «санитарному тестированию». 

Дисклеймер: Слово «санитарное» в данном случае — некорректное, об этом подробно здесь или здесь. Но поскольку мы видим, что это понятие в Google, Яндексе и Bing ищут именно в такой формулировке (то есть поисковых запросов с «санитарным» везде в разы больше чем с «санити» и прочими вариантами), то мы вынуждены здесь в тексте упоминать и эту формулировку; среди прочих, более корректных.

Что такое санитарное тестирование — значение

Mens sana in corpore sano, говорили римляне. Английское слово «sanity» до 17 века означало здоровье вообще, сейчас это слово соответствует более узким понятиям «душевное здоровье, адекватность, рациональное поведение». Sanity test в медицинском смысле — «тестирование на вменяемость», проверка общей адекватности человека (чаще всего призывника, или кандидата на серьезную должность). Sanity check или sanity test в математическом/техническом смысле — базовая проверка, позволяющая быстро оценить, может ли утверждение или результат вычислений быть истинным.

В ИТ-сфере санити-тестирование, также называемое «тестированием на поверхностном уровне» (surface level testing) — это тип тестирования программного обеспечения, направленный на проверку того, что определенные функциональные возможности (или исправления багов) в сборке ПО работают так, как ожидалось. 

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

Итак, sanity testing — это быстрая проверка, подтверждающая, что программное обеспечение достаточно стабильно для более комплексного тестирования. В большинстве случаев оно проводится после дымового тестирования.

Как применяется санити-тестирование

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

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

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

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

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

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

Фреймворки и инструменты санити-тестирования

В большинстве случаев санити-тестирование не требует специальных фреймворков, поскольку выполняется вручную и без скриптов. Однако в тех случаях, когда требуется более надежный и/или автоматизированный процесс, те же соображения, которые применяются к дымовым тестам, применимы и к «санитарным».

Преимущества и недостатки

👍 Плюсы:

• Экономичность, поскольку метод прост и не регламентирован
• Узкая и быстрая проверка, сфокусированная на измененных областях приложения
• Повышает уверенность в надежности данной сборки

👎 Минусы:

• Может потребовать ручного тестирования, так как не может быть легко автоматизирована
• Эффективность зависит от способности тестировщика (в данный конкретный момент) точно определить проблемы

Могут ли проводиться дымовые тесты и санити-тесты в одном проекте?

TL;DR: Да, дымовые и санитарные тесты могут проводиться в одном проекте.

Санитарные и дымовые тесты могут сосуществовать в одном цикле разработки, поскольку они служат разным, но взаимодополняющим целям:

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

Хотя оба подхода к тестированию могут использоваться вместе, обычно они применяются в разных сценариях. Дымовое тестирование нередко автоматизируется и интегрируется в конвейеры CI/CD, в то время как санитарное тестирование обычно выполняется вручную. В типичном процессе дымовое тестирование может быть автоматизировано, а после его прохождения проводится ручное санитарное тестирование измененных фич, чтобы убедиться, что они работают так как ожидалось.

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

Сводная таблица различий

Semaphore blog