Всем привет, коллеги-тестировщики и интересующиеся. Я Сергей, Senior Manual QA Engineer в “Петрович‑Тех”.

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

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

Начнем с определений

“Санитарное тестирование – специализированный вид тестирования, целью которого является подтверждение того, что определённая функция работает в соответствии с установленными в спецификации требованиями”. 

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

Зачем оно вообще надо

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

Я выделил два основных пункта на языке бизнеса:

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

2. Улучшение пользовательского опыта. Санитарное тестирование позволяет прожить реальный пользовательский опыт. То есть – увидеть и проанализировать всё удобство использования функционала. Такие проверки работают на повышение лояльности заказчика.

Когда нужно проводить санитарное тестирование

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

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

3. При интеграции нового функционала. Если в программу добавляются новые модули или функции, санитарное тестирование поможет удостовериться, что базовая функциональность приложения остается стабильной. Важно проверять не только формочки на фронте, но и правильность записей в БД, CRM, логи и т.д.

Когда лучше выбрать другой вид тестирования

1. В условиях сильно ограниченного времени. Санитарное тестирование требует вдумчивой и глубокой проработки. Наспех сделанные проверки не помогут.

2. Недостаточность тестовых данных. Например, если вы тестируете систему лояльности с разными уровнями для разных клиентов, важно иметь полный набор этих уровней. Т.к. санитарное тестирование подразумевает полный охват функционала.

3. Неадекватная документация. Если у тестировщиков нет четкой документации о том, какие именно функции и сценарии следует проверять, это приведет к хаосу. Хорошо структурированная и актуальная документация – залог качественного санитарного тестирования. Знаю, что вести документацию не всегда удается – в таком случае требуется тесный контакт с разработчиком, аналитиком или другим специалистом, который в курсе работы всего функционала.

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

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

Отличие санитарного тестирования от дымного

Некоторые источники ошибочно считают, что санитарное и дымовое тестирование – это одно и то же. 

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

Теперь пройдемся по более тонким различиям:

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

2. Цель санитарного тестирования – проверка конкретных функций, а дымовое тестирование направлено на выявление грубых ошибок, препятствующих дальнейшему тестированию.

3. Санитарное тестирование обычно выполняется вручную, в то время как дымовое тестирование часто автоматизировано.

4. Санитарное тестирование проводится после внесения небольших изменений или исправлений, в отличие от дымового тестирования, которое осуществляется после крупных релизов или сборок.

5. Санитарное тестирование требует глубокое понимание области изменений, в то время как дымовое тестирование охватывает широкий спектр общих случаев использования системы.

Можно ли автоматизировать санитарное тестирование

И да, и нет. Санитарное тестирование хуже поддается автоматизации, нежели дымное. Оно требует погружения в роль живого пользователя. 

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

Кто должен заниматься санитарным тестированием

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

Также смотрят программисты, со стороны кода и аналитики со стороны своих требований.

Как организовать санитарное тестирование

1. Определение целей

Что именно вы хотите проверить? Какие функции в результате изменений могут заафектиться?

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

2. Определение мест, где могут быть изменения

Пример: Вы тестируете форму оплаты. Вам важно будет посмотреть как на дизайн на фронте, все кнопочки как по оформлению, так и по отмене заказов, правильность записей в БД, правильность записей в CRM-системе, где хранятся заказы, правильность получения чеков, ошибки в логах и так далее.

3. Выбор инструментов

Подходящими инструментами могут быть автоматизированные тесты, различные браузерные расширения или средства для тестирования API.

Пример: вы тестируете оформление заказа. Вам нужно посмотреть оформление заказа как онлайн и как оффлайн – покупатель. Как оформить онлайн – понятно. А для оффлайн-заказа может потребоваться специальный софт в виде той же CRM или расширение для браузера имитирующий терминал покупателя.

4. Создание тестовых сценариев

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

Обычно они включают следующие шаги:
- Вход в систему.
- Выполнение базовых операций (например, создание записи, редактирование данных).
- Выход из системы.

5. Проведение самого тестирования. Тут всё понятно :-)
    

6. Документирование результатов

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

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

7. Анализ результатов

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

8. Обратная связь и улучшение процесса 

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

Итого

В завершении хочется обратиться к актуальному, пусть и чуть запоздалому: новый 2025 год на дворе. Дорогие айтишники, хочу пожелать вам запусков проектов без ошибок, легких обновлений, оптимизации процессов и никакой “антисанитарии” в коде ;-)

Вспоминаем базу и покоряем новые вершины в качестве вашего продукта!