Какими принципами руководствоваться при отборе тест кейсов на смоук
Что проверяют
Понимаете ли вы, что смоук это быстрый фильтр «можно ли вообще тестировать эту сборку», а не урезанная регрессия. Следом обычно спрашивают, чем смоук отличается от санити и сколько времени он у вас занимает.
Как отвечать
Сначала назначение: смоук запускают на каждой новой сборке, и он отвечает на один вопрос, стоит ли тратить на неё время. Упала хотя бы одна проверка, сборка возвращается разработке без дальнейшего тестирования. Отсюда принципы отбора:
- критичный путь: сценарии, без которых продукт бесполезен. Для магазина это вход, поиск, корзина и оформление заказа, для банковского приложения вход и перевод;
- широта, а не глубина: по одному позитивному сценарию на ключевой модуль. Граничные значения, негативные проверки и редкие комбинации уходят в регрессию;
- инфраструктура: приложение развернулось, главная открывается, API отвечает, есть связь с базой и внешними сервисами, например с платёжным шлюзом в тестовом режиме;
- стабильность: в смоук берут только кейсы, которые не флакают. Нестабильный тест блокирует сборки ложными падениями;
- время: ориентир от нескольких минут до получаса. Разросшийся набор режут, а не терпят;
- автоматизация: смоук первым уходит в CI и запускается после каждого деплоя на стенд.
Добавьте, что набор живой: появилась ключевая фича, кейс на неё добавляют, фичу убрали, кейс удаляют. И назовите отличие от санити: санити узкий и глубокий, он проверяет конкретное исправление или изменённый модуль уже после смоука.
Где спотыкаются
Тащат в смоук всё «важное» и получают набор на три часа. Это уже регрессия, и быстрой обратной связи она не даёт.
Говорят, что смоук проверяет изменённые участки кода. Проверки по изменениям это задача санити и регрессии, состав смоука от конкретного диффа не зависит.
Добавляют негативные сценарии и проверки вёрстки. Опечатка в тексте кнопки не повод отклонять сборку, а смоук должен падать только на блокирующих проблемах.