Smoke vs Sanity тестирование: в чём разница?

Тестирование, как неотъемлемый процесс жизненного цикла разработки программного обеспечения, обеспечивает функциональность, совместимость и производительность разрабатываемых приложений. Среди различных видов тестирования особое место занимают smoke-тесты и sanity-тесты, которые проверяют надёжность и стабильность программных приложений.

Smoke-тестирование обычно является первым этапом тестирования, проводимым после получения новой сборки. Если smoke-тесты успешно пройдены, что указывает на базовый уровень стабильности, то далее переходят к sanity-тестированию, чтобы более детально проверить конкретные изменения. Термины sanity-тестирование и smoke-тестирование часто используются как синонимы, но между ними есть существенные различия, о которых необходимо знать, чтобы выбрать правильную стратегию тестирования.

Что такое smoke-тестирование?

Smoke-тестирование, также известное как тестирование верификации сборки (Build Verification Testing, BVT), — это начальный этап тестирования, который подтверждает корректную работу ключевых функций программного приложения. Оно проводится при значительных изменениях в коде, например, при добавлении новой фичи, чтобы убедиться, что основные рабочие процессы приложения функционируют правильно. Проще говоря, мы проверяем, что критически важные функции приложения работают и что в тестируемом коде нет существенных проблем.

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

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

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

Основная цель smoke-тестирования — проверить все важные компоненты сборки и отклонить приложение в случае обнаружения ошибок или дефектов. Эта практика помогает командам QA-командам экономить время на проверках. Без smoke-тестирования критические проблемы могут остаться незамеченными, что впоследствии может привести к более серьёзным проблемам. Это может быть весьма трудозатратно и дорого.

Например, smoke-тестирование отвечает на такие базовые вопросы, как «Работает ли программа?» или «Открывается ли пользовательский интерфейс?». Если эти базовые тесты не проходят, дальнейшее тестирование становится бессмысленным, что экономит время команды. Таким образом, smoke-тесты позволяют всесторонне оценить функциональность продукта в ограниченные сроки, предоставляя быструю обратную связь по сравнению с более продолжительными тестовыми наборами, требующими значительно больше времени.

Smoke-тестирование проводится при развёртывании новой сборки и при внесении любых изменений в процессе разработки. Это позволяет одновременно проверить работоспособность и стабильность всех критических функциональных возможностей ПО.

После успешного завершения smoke-тестирования ПО интегрируется в существующую сборку в QA- и staging-среде. Впоследствии сборка проходит более строгие тесты, включая модульные и интеграционные. 

Преимущества 

• Smoke-тестирование проверяет стабильность сборки для дальнейшего тестирования.

• Раннее обнаружение ошибок экономит время при исправлении критических проблем.

• Повышение качества ПО за счет раннего устранения критических проблем.

• Снижение риска сбоев на более поздних этапах разработки.

• Минимальные требования к ресурсам и простота процессов.

• Гибкость за счёт использования ручного, автоматизированного и гибридного подходов.

Недостатки

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

• Некоторые баги или проблемы могут остаться незамеченными при smoke-тестировании и обнаружиться позже в процессе разработки.

• Ручное smoke-тестирование занимает больше времени, особенно в крупных проектах.

Пример

Давайте рассмотрим на примере разработки веб-сайта.

• Сценарий: создание веб-сайта электронной коммерции.

• Smoke-тест: регистрация пользователей, вход в систему, просмотр товаров и функциональность корзины.

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

• Результаты: выявление критических проблем на ранней стадии (сбои, неработоспособность), прекращение тестирования при наличии серьёзных проблем и информирование разработчиков о необходимости оперативных исправлений.

• Преимущество: простой тест, который гарантирует базовую стабильность.

Этапы проведения Smoke-тестирования

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

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

3. Написание smoke-тестов: Используйте ручные или автоматизированные процессы для написания и создания набора тестов. Разрабатывайте краткие и целенаправленные тест-кейсы, расставляйте их в порядке приоритета в зависимости от критичности и документируйте необходимые данные для их выполнения. Учитывая, что smoke-тестирование ориентировано на основные фичи, убедитесь, что создаёте тесты, необходимые для их проверки.

4. Выполнение и документирование тестов: Запустите smoke-тесты и систематизируйте процесс записи результатов каждого теста. Это документирование может осуществляться вручную или автоматически.

5. Анализ результатов smoke-тестирования: если ПО не прошло smoke-тест, верните его команде разработки для дальнейшего тестирования. Если оно прошло smoke-тест, считается, что оно готово к более обширному функциональному тестированию.

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

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

Лучшие практики

Даже если вы тщательно соблюдаете процедуры при проведении smoke-тестов, не исключено, что вы столкнётесь с проблемами. Сэкономить время и силы в таких ситуациях вам помогут следующие лучшие практики:

• Настройте набор smoke-тестов в конвейере непрерывной интеграции (CI), чтобы он автоматически выполнялся при появлении новой сборки.

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

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

• Разработайте несложные тест-кейсы, сфокусированные на основных функциях.

• Регулярно пересматривайте набор smoke-тестов, чтобы убедиться, что он соответствует текущим требованиям программного обеспечения.

В следующем разделе рассмотрим подробнее Sanity-тестирование.

Что такое sanity-тестирование?

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

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

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

Цель проведения sanity-тестирования 

Основная цель sanity-тестирования — проверить, работает ли функциональность программного приложения так, как ожидается. Тестировщики проводят sanity-тесты для проверки работоспособности приложения без выполнения детального тестирования. Sanity-тестирование помогает оперативно выявить ошибки в основной функциональности.

Sanity-тестирование выполняется перед развёртыванием в продакшен среде и после получения сборки с незначительными изменениями в коде, и преследует следующие цели:

• Проверить базовые, критические функции и оценить вновь добавленные.

• Быстро обнаружить дефекты.

• Убедиться, что внесенные изменения согласуются с существующей функциональностью.

• Определить, необходимо ли полное тестирование. Если результаты sanity-тестирования отрицательные, потребуется более тщательное тестирование или возврат сборки команде разработки.

• Минимизировать бизнес-риски без чрезмерного расхода ресурсов и усилий команды тестирования.

Преимущества

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

• Раннее выявление критических проблем, предотвращающее лишние затраты на регрессионное тестирование.

• Быстрые и целенаправленные sanity-тесты экономят время разработки, быстро выявляя проблемы.

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

Недостатки

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

• Отсутствие задокументированных тестов затрудняет воспроизведение проблем и отслеживание прогресса.

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

• Эффективность зависит от понимания тестировщиками критической функциональности.

• Ненаписанные тесты затрудняют их повторное использование для будущих сборок.

• Хотя оно и быстрее, чем регрессионное тестирование, sanity-тестирование всё же может отнимать много времени.

Пример

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

• Управление информацией о клиентах: можно ли без проблем создавать, редактировать и просматривать информацию о клиентах?

• Отслеживание задач: можно ли эффективно назначать задачи, устанавливать сроки и отслеживать прогресс?

Если эти начальные sanity-тесты пройдены, команда переходит к следующему этапу разработки.

• Добавление новой фичи и предотвращение регрессий: предположим, что в следующей сборке добавлена функция синхронизации с календарем. Важно убедиться, что эта новая фича не нарушает существующую функциональность. Здесь на помощь приходит sanity-тестирование.

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

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

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

• Тестировщики запускают sanity-тесты на назначение задач, чтобы проверить баг-фикс.

• Это обеспечивает устранение бага без введения новых осложнений.

Когда выполняется sanity-тестирование?

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

• При незначительных изменениях в коде приложения.

• При добавлении новых фич, которые необходимо интегрировать в программное приложение.

• После завершения серии регрессионных тестов и создания новой сборки.

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

• Перед развёртыванием в продакшен среде.

Частота выполнения sanity-тестирования в рамках жизненного цикла разработки ПО зависит от конкретных требований и сложности продукта.

Как работает sanity-тестирование?

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

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

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

Шаги проведения sanity-тестирования

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

2. Определите объём. На основе выявленных изменений определите, какую функциональность необходимо протестировать в рамках sanity-тестирования. Сосредоточьтесь на критически важных областях и основной функциональности приложения.

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

4. Настройте тестовую среду. Убедитесь, что у вас чистая тестовая среда, настроенная с новой сборкой. Эта среда должна максимально точно отражать конфигурацию продакшен среды.

5. Выполните тесты. Начните выполнять тесты вручную или используйте инструменты автоматизации для проверки основной функциональности, определённой на шаге 2. Сосредоточьтесь на проверке того, работают ли новые фичи как ожидается, и не нарушили ли изменения существующую функциональность.

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

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

Лучшие практики 

Чтобы устранить недостатки sanity-тестирования, вы можете следовать следующим лучшим практикам:

• Выполняйте sanity-тестирование при каждом изменении или добавлении компонента, а также после исправления бага.

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

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

• Всегда составляйте план тестирования и изучайте спецификацию требований к программному обеспечению (SRS) перед началом sanity-тестирования.

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

Smoke vs Sanity тестирование: ключевые различия

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

Хотите понять разницу между smoke-тестированием и sanity-тестированием? Вот их ключевые отличия:

Инструменты для проведения Smoke- и Sanity-тестирования

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

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

Некоторые из распространённых инструментов автоматизированного тестирования:

• LambdaTest: платформа для оркестрации и выполнения тестов на основе искусственного интеллекта, которая позволяет проводить smoke- и sanity-тестирование в более чем 3000 браузерах, операционных системах и на реальных мобильных устройствах.

• Selenium: инструмент с открытым исходным кодом, позволяющий автоматизировать тесты в различных веб-браузерах. Selenium надёжен и гибок, он позволяет создавать скрипты для smoke- и sanity-тестирования для имитации взаимодействия пользователей и проверки поведения приложения.

• Playwright: относительно новый и мощный инструмент от Microsoft для автоматизации тестов в браузерах и Node.js. Playwright предлагает унифицированный API для тестирования в различных браузерах (Chromium, WebKit, Firefox) и «безголовых средах». Как и Selenium, Playwright предоставляет базу для построения автоматизированных наборов smoke- и sanity-тестов.

• Cypress: популярный инструмент для автоматизации тестирования веб-приложений. Известен своей дружелюбностью к разработчикам благодаря синтаксису на JavaScript и упрощению процесса написания, выполнения и отладки автоматизированных тестов.

• Appium: ещё один инструмент с открытым исходным кодом для автоматизации тестирования мобильных приложений. Appium позволяет писать тестовые сценарии с использованием различных языков программирования для взаимодействия с мобильными приложениями на реальных устройствах или эмуляторах. Appium помогает автоматизировать smoke- и sanity-тестирование для мобильных приложений.

Кроме того, вы можете использовать потенциал этих инструментов вместе с облачными платформами тестирования, такими как LambdaTest. Обладая доступом к удаленной лаборатории тестирования с более чем 3000 устройствами и версиями браузеров, она поддерживает беспрепятственное выполнение тестов с использованием различных фреймворков автоматизации тестирования, таких как Selenium, Playwright, Cypress, Appium и другие.

В облачной среде sanity- и smoke-тестирование предлагают такие преимущества, как сокращение затрат на инфраструктуру, обеспечение масштабируемости автоматизированных тестов, содействие командной работе и гибкость в настройке тестовой среды.

---

В заключение приглашаем всех начинающих тестировщиков на открытые уроки:

• 8 октября: «Введение в тестирование мобильных приложений». Вы получите практические советы по тестированию, узнаете о лучших инструментах и методах, а также познакомитесь с основными принципами работы тестировщика. Запись по ссылке

• 17 октября: «Основы тест-дизайна для ручного тестировщика». Узнаете, зачем нужен тест-дизайн и какие задачи он помогает решать. Также поговорим об основных типах тестирования и о роли документации. Запись по ссылке