Как писал Smoke чек лист на проекте

Smoke Checklist в тестировании: цели, структура и практические примеры

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

Ключевые цели Smoke Checklist

• Определить стабильность релиза: подтвердить, что основные функции работают после сборки/деплоя.
• Экономия времени: быстрая проверка (от 15 до 60 минут) перед запуском глубокого тестирования.
• Раннее обнаружение критических дефектов: если smoke тест не проходит, дальнейшее тестирование приостанавливается, чтобы не тратить ресурсы.
• Верификация готовности среды: проверка, что сервер, БД, сетевые подключения функционируют.

Принципы составления Smoke Checklist

1. Фокусировка на критическом пути пользователя: тестируются сценарии, которые выполняет большинство пользователей при первом использовании.
2. Независимость от данных: тесты должны проходить на чистой или стандартной среде, без сложных подготовок.
3. Минимализм: обычно 10-20 проверок, не более.
4. Высокая скорость выполнения: ручные тесты должны быть быстрыми; автоматизация smoke тестов идеальна для CI/CD.
5. Стабильность: проверки должны быть надежными и не зависеть от нестабильных элементов (например, временных всплывающих окон).

Структура чек-листа на примере веб-приложения

Чек-лист обычно составляется в виде таблицы в Excel/Google Sheets, Confluence или в инструментах для тест-менеджмента (TestRail, Zephyr). Пример структуры:

Пример Smoke Checklist для веб**-приложения онлайн-банка**

### 1. Доступность системы
- **S1**: Главная страница загружается.
    - Шаги: Перейти по базовому URL (https://bank.example.com).
    - Ожидаемый: Страница отображается, нет ошибок "Server Error" или "Connection Refused".

### 2. Авторизация (ключевой бизнес-путь)
- **S2**: Логин существующего пользователя.
    - Шаги: Ввести валидные логин/пароль в форму, нажать "Войти".
    - Ожидаемый: Успешный переход в личный кабинет, отображается имя пользователя.
- **S3**: Выход из системы.
    - Шаги: Нажать "Logout" в личном кабинете.
    - Ожидаемый: Переход на страницу логина, сессия завершена.

### 3. Основные функции после логина
- **S4**: Отображение баланса на главной странице кабинета.
    - Шаги: После логина проверить блок "Current Balance".
    - Ожидаемый: Баланс отображается (число > 0 или 0.00).
- **S5**: Доступность списка последних транзакций.
    - Шаги: Нажать раздел "Recent Transactions".
    - Ожидаемый: Таблица транзакций загружается, есть хотя бы одна запись.

### 4. Критические операции
- **S6**: Открытие формы для создания платежа.
    - Шаги: Нажать кнопку "Pay" -> "New Payment".
    - Ожидаемый: Форма открывается, поля для суммы, получателя видимы.
- **S7**: Валидация формы платежа (позитивный сценарий не требуется в smoke, только доступность).

Пример Smoke Checklist для мобильного приложения (Android/iOS)

### 1. Установка и запуск
- **M1**: Установка приложения из магазина (TestFlight/Google Play внутренний релиз).
    - Ожидаемый: Установка завершается без ошибок.
- **M2**: Первый запуск приложения.
    - Ожидаемый: Приложение открывается, нет краша на стартовом экране.

### 2. Основной поток
- **M3**: Регистрация/логин (если требуется).
    - Шаги: Ввести тестовые credentials.
    - Ожидаемый: Успешный вход, переход на главный экран.
- **M4**: Навигация между основными табами (Home, Profile, Settings).
    - Шаги: Тапать по каждому табу.
    - Ожидаемый: Контент каждого таба загружается без задержек.

Автоматизация Smoke тестов

Идеально автоматизировать smoke тесты для интеграции в CI/CD pipeline. Пример простого теста на Python + Selenium для проверки доступности и логина:

import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By

def test_smoke_homepage_and_login():
    driver = webdriver.Chrome()
    driver.get("https://bank.example.com")
    
    # S1: Проверка доступности главной страницы
    assert "Online Bank" in driver.title, "Homepage title mismatch"
    
    # S2: Проверка логина
    login_field = driver.find_element(By.ID, "username")
    login_field.send_keys("test_user")
    
    password_field = driver.find_element(By.ID, "password")
    password_field.send_keys("secure_pass")
    
    submit_button = driver.find_element(By.XPATH, "//button[@type='submit']")
    submit_button.click()
    
    # Проверка успешного логина
    welcome_message = driver.find_element(By.CLASS_NAME, "welcome-text")
    assert "Welcome, test_user" in welcome_message.text, "Login failed"
    
    driver.quit()

Как мы писали чек-лист на реальном проекте (опыт)

На проекте ERP-системы мы разрабатывали smoke чек-лист следующим образом:

1. Совместная сессия с разработчиками и продукт-менеджером для определения "критического пути": какие операции выполняются 80% пользователей ежедневно? (Логин → Проверка dashboard → Создание заказа → Отчет по заказу).
2. Документирование в Confluence в виде таблицы с приоритизацией: каждый пункт оценивали по риску (High/Medium/Low). High — обязательно в smoke.
3. Интеграция с Jenkins: автоматические тесты (на основе вышеописанного кода) запускались после каждой сборки в ветке release. Если хотя бы один smoke тест падал — сборка маркировалась как unstable, и тестирование не продолжалось.
4. Регулярный ревизий чек-листа: после каждого крупного релиза мы пересматривали список, добавляя новые ключевые функции или удаляя ставшие менее важными.

Критерии успешного Smoke Checklist

• Все проверки выполняются быстро (не более 30 минут для ручного выполнения).
• Чек-лист покрывает все ключевые модули (не только фронтенд, но и базовые API, если система API-centric).
• Результаты четко документируются: статус Pass/Fail с комментариями сразу виден всей команде.
• Чек-лист живёт рядом с процессом: не забыт, а используется перед каждым циклом тестирования.

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