Как вы составляете чек-листы для Smoke-тестирования?

«Как вы составляете чек-листы для Smoke-тестирования?» — вопрос из категории Тестовая документация, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

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

Принципы составления smoke-чек-листа:

  1. Минимализм: 5-10 ключевых сценариев, которые выполняются за 10-30 минут.
  2. Фокус на ядро: Проверяются только функции, без которых продукт не может быть использован.
  3. Стабильность: Включаются только стабильные, хорошо известные сценарии с минимальным количеством шагов.
  4. Независимость: Сценарии должны быть максимально независимы друг от друга.
  5. Актуальность: Чек-лист регулярно пересматривается и обновляется вместе с продуктом.

Пример smoke-чек-листа для интернет-магазина:

### Smoke Test Checklist v2.1 (E-Commerce App)
**Сборка:** #BUILD_ID | **Среда:** Staging

- [ ] **1. Доступность приложения**
    - Главная страница загружается (HTTP 200).
    - Отсутствуют критические JS-ошибки в консоли.

- [ ] **2. Критичные пользовательские сценарии**
    - **Авторизация:** Вход с валидными учётными данными.
    - **Поиск:** Поиск по существующему товару возвращает результаты.
    - **Карточка товара:** Страница товара открывается, отображаются цена, описание, кнопка "В корзину".
    - **Корзина:**
        *   Добавление товара в корзину.
        *   Отображение товара в корзине.
        *   Переход к оформлению заказа (до шага оплаты).

- [ ] **3. Базовая навигация**
    - Переходы между основными разделами (Каталог, Акции, О нас) работают.

- [ ] **4. Критичная интеграция (если есть)**
    - Получение списка товаров с бэкенда (проверка работы API).

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