- Что это
- Цели
- Пример
- Характеристики
- Плюсы и минусы
- Отличия от smoke-тестирования
- От регрессионного
- От повторного
Определение
Разновидность регрессионного тестирования. Санитарное, или санити-тестирование, или «тестирование согласованности» это быстрая проверка работоспособности после добавления новой функции. Санитарное тестирование это «небольшая остановка для проверки», будет ли билд работать. Цель QA-команды — валидация базовой функциональности, без подробного тестирования. Обычно такое тестирование проводится на билдах, развертывание которых нужно здесь и сейчас, например после устранения критикал-бага.
О правильном названии санити-тестирования
Данный тип тестирования (быструю проверку работоспособности) наиболее правильно называть «тестом работоспособности»; по крайней мере, такое каноничное определение дает ISTQB — главный авторитет в нашем уютном мире QA.
Однако, в русскоязычном QA-комьюнити уже много лет употребляется «санитарное тестирование»; что явно некорректно, и даже немного комично, как отмечают наши подписчики в Телеграм-канале Тестировщик от Бога; но с этим, наверное, ничего уже не поделать — термин «устоялся».
Имея в виду этот специфический тип тестирования, wannabe-тестировщики ищут в Сети именно «санитарное тестирование» (потому что у них это достаточно часто спрашивают на собеседованиях, как выяснилось). Поскольку мы в своей деятельности больше ориентируемся на поисковые запросы наших любимых пользователей-джунов, чем на мнения педантов-аккуратистов уровня миддл+, то статья о sanity testing называется так как называется («как считает правильным большинство»).
Возмущения по поводу корявой терминологии (вполне обоснованные), с подробным разбором темы, можно почитать, например, здесь; за 5 лет ничего не изменилось.
При этом надо отметить, что даже англоязычный справочник ISTQB (все еще) не дает четкого разделения между санити- и смок-тестированием (несмотря на то, что необходимость как бы назрела уже давно). А в некоторых (более старых) версиях справочник ISTQB вообще объединяет эти понятия, называя sanity- эквивалентом smoke-, и называя санити- «тестом работоспособности». ОК, значит такое определение и мы будем считать самым каноничным, по крайней мере пока; и для собеседования, чтобы «блеснуть», годится такое определение.
Но это справочники; в повседневной жизни QA в англоязычном мире эти понятия уже давно и четко разделены, они не смешиваются — из-за того что процессы уж слишком явно отличаются — об этом ниже. Везде «санитарное тестирование» называется sanity testing; это, в принципе, тоже жаргонный термин, некорректный; но определение прочно устоялось, и оттуда перешло в русский.
Предназначение
Определить, что измененные или добавленные функции работают нормально. Если санити-тест упал, QA-команда вовремя вернет код на доработку, и это экономия времени и денег для компании. Санитарное тестирование проводится после smoke-тестирования.
Иллюстративно, место и роль санитарного тестирования изображается примерно так:
Пример
Есть проект e-commerce, в нем модули страницы входа, домашней страницы, страницы профиля, регистрации и так далее. На странице входа имеем дефект: поле пароля принимает не менее 4 цифр, а в требованиях говорится, что это поле должно содержать не менее 8 цифр. Этот дефект репортится разработчикам, они фиксят его, и отправляют тестировщикам для проверки. QA-команда проверяет, сработали ли изменения; а также проверяет, не повлияли ли эти изменения на другие функции. Таким образом, страница входа и страница профиля валидируются санитарным тестированием.
Характеристики санитарного тестирования
- Подвид регрессионного
Как говорилось в начале, санитарное тестирование типологически является разновидностью регрессионного, и направлено на небольшую часть приложения.
- Без сценариев
Обычно такое тестирование не подразумевает написания тестовых сценариев
- Без документации
Обычно не проводится документирование
- Узконаправленное и тщательное
Небольшой объем кода, отвечающий за одну функцию, тщательно исследуется
- Выполняется QA-инженерами
Выполняется тестировщиками, в отличие от юнит-тестирования
Преимущества
- Быстрая идентификация дефектов ключевой функциональности
- Поскольку не требует оглядки на документацию, делается быстро и просто
- Экономия усилий и средств на ранних этапах цикла
- «Дешевая» разновидность тестирования
- Находит ошибки в зависимостях
- Выгодно при нехватке времени
Недостатки
- Ограниченность: сосредоточено только на небольшой части кода
- Не позволяет покрыть все тест-кейсы в тестовом сценарии
- Относится только к малой части функциональности
- Не документируется
- Не поднимается на структурный уровень дизайна
Дополнительно
Сравнение санитарного и смок-тестирования
Смок-тестирование это «быстрая проверка базовой функциональности». Типологически это подвид приемочного тестирования (тогда как санити-тестирование — регрессионного). «Дымовое» тестирование проверяет всю функциональность системы/продукта.
Санитарное тестирование проверяет отсутствие багов после билда. Часто путают смок- и санити-тестирование, но они имеют отличия, перечисленные далее.
Отличия между санитарным и smoke- тестированием
| Smoke-тестирование | Санити-тестирование |
|---|---|
| Самая базовая функциональность — работает ли | Баги устранены после билда |
| Подвид приемочного | Подвид регрессионного |
| Документируется | Не документируется |
| Выполняется разработчиками и/или тестировщиками | Тестировщиками |
| Могут создаваться тестовые сценарии | Без сценариев |
| Оценка стабильности и работоспособности системы | Оценка работоспособности измененного/исправленного модуля |
| Тестируется функциональность «в общем» | Тестируется измененная/дефектная функция |
| Вручную или возможна автоматизация | Вручную, без автоматизации |
| Когда есть новый билд | После завершения регрессионного тестирования |
| Затрагивает все модули | Только измененный модуль |
| Тестируется промежуточный билд | Тестируется стабильный билд / билд с новыми функциями |
| Возможна сквозная автоматизация | Без автоматизированных тест-кейсов и сценариев |
| End-to-end верификация системы | Верификация только исправленного компонента |
| Билд может быть стабильным или нестабильным | Билд преимущественно стабильный |
| Каждый новый релиз билда проходит смок-тестирование | Когда тщательное тестирование невозможно по недостатку времени |
Сравнение санитарного и регрессионного тестирования
Санитарное тестирование
Санити-тестирование представляет собой анализ (части) продукта после его модификации. Оно является подвидом регрессионного тестирования. Регрессионное тестирование касается многих областей приложения; санитарное — только некоторой части, определяя качество продукта в этой части и готовность продукта к дальнейшему тестированию.
Санитарное тестирование проверяет функцию в продукте после ее добавления/модификации, проверяется стабильный билд.
Регрессионное тестирование
Тщательная проверка всей функциональности приложения, после багфиксов, модификаций, обновления, и подобное. Цель: проверить, что модификации не ухудшили имеющуюся функциональность.
Полная проверка функциональности, выполняемая после частичной проверки санитарным тестированием. Проверятся стабильный билд.
Отличия между санити- и регрессионным
| Санитарное | Регрессионное |
|---|---|
| Тестирование новой функциональности в имеющемся билде | Оценка функциональности всего что затронуто после изменения/добавления кода |
| Подвид регрессионного | Отдельный вид тестирования |
| Выполняется до регрессионного и после смок-тестирования | Время выполнения зависит от особенностей приложения, доступности персонала и запаса времени |
| «Поверхностное» тестирование | «Глубинное» тестирование |
| Проверяет новую функциональность | Проверяет (почти) всю функциональность |
| Не используются сценарии (скрипты) | Предпочтительно использовать сценарии |
| Вручную | Возможна автоматизация |
| Увеличивает стоимость продукта/бюджет проекта | Тоже увеличивает |
| Сквозные тест-кейсы не делаются | Часто сквозные тест-кейсы |
| «Узкое» тестирование | «Глубокое» тестирование |
| Не рутинное, часто специфическое тестирование, длящееся мало времени | «Регрессы» делают даже для самых небольших модулей |
| Иногда бывают базовые тест-кейсы | Почти всегда пишут большой набор тест-кейсов |
Разница между повторным и санитарным тестированием
Повторное тестирование
Называемое также re-testing; это повторная проверка модуля после устранения дефекта; повторное выполнение тест-кейсов, упавших ранее и исправленных. Процесс идет так:
- Дефект найден
- Разработчики устраняют его
- Тестировщики тестируют исправленный код, снова, почему и называется повторным
Санитарное тестирование
Проводимое при получении билда с (часто небольшими) изменениями кода/функциональности, с целью убедиться, что баги устранены, и что в «старом» коде не создалось проблем связанных с этими изменениями. Процесс такой:
- QA-команда получает билд
- Проверяют, что функциональность, в общем, сохранилась
- Проводят санити-тест; если он падает, билд возвращается на доработку
- Если санити-тест проходит, то далее продолжается «обычное» тестирование
Таблица отличий: sanity-тестирование vs повторное тестирование
| Повторное (re-testing) | Санитарное (sanity testing) |
|---|---|
| Проверяет, что тест-кейсы, упавшие ранее — теперь, после устранения дефектов, успешно проходят | Проверяет, что сохранилась функциональность после багфикса / просто изменений в коде |
| Предусмотрена верификация дефектов | Не предусмотрена верификация дефектов |
| Проводится до санитарного и регрессионного | Проводится до регрессионного и после дымового |
| Тест-кейсы трудно автоматизировать | Тоже — все делается вручную |
| Завершается после устранения багов | Подтверждает «общую работоспособность» перед дальнейшим тестированием |
| Выполняется с ранее запускавшимися тест-кейсами (повторно) | Выполняется без тест-кейсов, на своем понимании особенностей системы |
| Приоритетнее, чем санитарное | Ниже приоритет, чем у повторного |
| Плюсы — Верификация найденных дефектов — Быстрая верификация — дефектов мало, масштаб ограничен — Повышение общего качества — Используется существующее окружение и наборы данных на новом билде | Плюсы — Экономится время, фокус на небольших участках кода — Верификация, что функциональность сохраняется после небольших изменений — Без тестовых сценариев и документации — Поэтому быстрое |
| Минусы — Для верификации дефектов нужен новый билд — Нет автоматизации тест-кейсов — Иногда много времени на повторное упавших тест-кейсов — Тест-кейсы только после начала тестирования | Минусы — Иногда сложно устранить дефекты без консультации с разработчиками, не зная структуры приложения — Проверка только некоторых функций, если в остальных есть баги, останутся незамеченными Не документируется |
