Обычно люди запутываются в значениях дымового и санитарного тестирования. Прежде всего, эти два понятия очень разные, да и QA выполняет их на разных этапах цикла тестирования.
Дымовое тестирование (англ. smoke testing)
Дымовое тестирование– это особый вид проверки программного обеспечения, направленный на тщательный анализ работоспособности разрабатываемого веб-продукта, а именно наиболее важных и критических моментов. Итоги подобных проверок применяются для того, чтобы понять, можно ли характеризовать созданное ПО как максимально стабильную сборку для последующего тестирования.
Выполнение дымового тестирования проводиться тогда, когда QA-отдел внутри компаний по обеспечению качества получает в работу новую версию ПО, изначально считая ее не до конца доработанной и исправной. При подобной проверке крайне важно убедиться в том, что все самые важные параметры тестируемого продукта функционируют корректно и согласно заявленным ожиданиям.
Философия подобного вида тестирования основывается на том, что тестировщики должны как можно ранее найти источник и причины возникновения багов и отклонить проверяемую версию на последующую доработку программистам.
Дымовые тесты очень важны, так как позволяют не проводить сложные проверки уже на стадии официального релиза, дабы не выпустить потребителям некачественное ПО.
Базовая задача такого рода тестов заключается в быстрой проверке работоспособности и стабильности программного обеспечения в целом, без надобности проведения тщательных проверок в будущем.
Ключевые преимущества дымовых тестов
- Позволяют находить проблемы еще на стадии интеграции ПО в реальную среду функционирования;
- Процесс тестирования позволяет отлавливать баги еще на ранних стадиях развертывания веб-компонентов;
- Дает определенную уверенность в том, что редактирование ПО не оказало негативного воздействия на базовые структуры системы;
- Критический сбой при таких тестах немедленно приводит к отказу от ранее оцененной версии сборки.
Санитарное тестирование (англ. sanity testing)
Санитарное тестирование – очень специфическая проверка работоспособности отдельных функциональных элементов, систем, веб-архитектур и расчетов. Она выполняется с единственной целью – дать 100% понятие того, что создаваемая система работает именно так, как того и требовалось.
Подобный тип тестирования нередко выполняется до старта полного цикла проведения регрессионных проверок, но только после окончания дымового тестирования.Традиционно, санитарные проверки выполняются тогда, когда исправлен незначительный дефект внутри системы или ранее выполнялись работы по частичном редактировании логики работы ПО.
Как только изменения были внесены в код, новая сборка программного обеспечения передается на проверку в отдел тестирования. После установки сборки QA-специалисты могут выполнять эффективную проверку отредактированной функциональности вместо полной регрессии программного обеспечения, которое занимает существенно больше времени.
Если исправленные баги и редакции кода работают неверно, тогда тестировщик не имеет права принимать сборку на тест. Отметим, что любые дефекты, найденные на такой ранней стадии, смогут сэкономить массу времени на процессе проверки недоработанной сборки.
Ключевые особенности санитарного тестирования
- По своей сути является процессом поверхностного тестирования с точной концентрацией на детализированной проверке избранной функциональности.
- Является подмножеством регрессионного тестирования.
- Проводится тогда, когда у QA нет запаса времени на выполнение детальной проверки всей сборки.
- Процесс тестирования по обыкновению не документируется.
- Представляет собой быстрое тестирование для наглядности убеждения в том, что внесенные изменения в конфигурацию ПО работают не так, как ожидалось.
- Выполняется для быстрой проверки того, что незначительные погрешности в работе ПО были исправлены и не привели к глобальным конфигурационным ошибкам.
Преимущества санитарного тестирования
- Существенным образом экономит время и технологический ресурс, так как фокусируется исключительно на одной или нескольких функциональностях;
- Помогает в поиске зависимых и отсутствующих объектов;
- Применяется для проверки правильности функционирования определенной части продукта после небольших изменений.
Недостатки
- Фокус исключительно на некоторых функциональных областях;
- Не затрагивает суммарный уровень ПО, и группе разработчиков очень трудно понять, как отредактировать баги, найденные во время тестирования работоспособности;
- Выполняется при тестировании лишь некоторых функциональностей, а значит, если есть проблемы с другими функциями, они не будут заранее найдены;
- Проверки зачастую не документируются, а значит, в будущем такие тесты запросто могут быть упущены.
Сравнение дымового и санитарного тестирования
| Дымовое тестирование | Санитарное тестирование |
|---|---|
| Выполняется исключительно на начальных стадиях разработки ПО еще до начала проведения регрессионных проверок | Осуществляется на сборках, которые успешно прошли дымовое тестирование и им еще предстоит полный цикл регрессионных проверок |
| Сборка может быть как стабильной, так и нестабильной | Сборка отличается максимально стабильной работой |
| Мотивы подобного тестирования основываются на надобности знакомства с новыми версиями ПО | Базовая цель – тестирование рациональности работы внедренных конфигураций для последующего тщательного тестирования |
| Критические ошибки при дымовом тестировании моментально приводят к отказу от использования этой сборки ПО | Найденные ошибки позволяют переместить сборку в список отклоненных, с которыми еще предстоит иметь дело |
| Проводиться в равной степени что QA-специалистами, что отделом разработки | Традиционно работа тестировщика |
| Состоит из определенной документации и работы по заранее созданным сценариям | Четко выраженного акцента на работе по сценариям нет |
| Выполняется как вручную, так и с помощью запрограммированных автотестов | Проводится исключительно вручную |
Наглядные примеры использования данных тестов
Детально рассмотрим реальные примеры проведения подобных видов проверок на основе настоящих тестовых случаев.
Пример дымового тестирования
Допустим, в проверяемом ПО есть 5 модулей, а именно:
- Регистрация в системе;
- ЛК клиента;
- Просмотр пользователей;
- Создание клиента;
- Создание клиентских задач.
То есть, внутри данных модулей QA проводит тестирование, проверяя основную функциональность этих модулей, а точнее:
- Вход в систему со сторонними клиентскими данными;
- Клиент не может войти с недействительными данными;
- После авторизации может быть создан новый пользователь;
- Можно ли пользоваться аккаунтом пользователя после его создания.
Пример санитарного тестирования
Снова представим, что есть 5 модулей:
- Авторизация в системе;
- Просмотр страницы пользователя;
- Его ЛК;
- Создание нового пользователя;
- Создание задач.
При тестировании был найден дефект на странице авторизации. К примеру, поле для ввода пароля воспринимает комбинацию исключительно из 6 символов, что категорически не соответствует ТЗ, где указанно, что пароль может быть от 4 символов.
Тестер сообщил разработчику о найденном дефекте, чтобы он исправил его. Ошибка была исправлена, и модуль возвращается на тест QA-специалистам, которые также должны проверить работу и остальных 4 модулей. Они должны убедится в том, что тестирование исправленного бага не повлияло на корректную функциональность остальных систем и логик.
Но важно понимать, что при таком подходе тестируется только экстремальная функциональность модулей, нет никакого углубления в проверку деталей из-за отсутствия времени. Это и есть процедура санитарного тестирования.
Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.
Оставить комментарий