Що таке smoke test і як швидко перевірити, що реліз не зламав головне

Smoke test часто плутають із повним тестуванням. Насправді це коротка, швидка перевірка, яка відповідає на дуже просте питання: після релізу головний сценарій ще працює чи вже ні?

Назва походить із поняття “першого диму” в техніці: якщо після запуску щось одразу ламається, не має сенсу рухатися далі. Для команди це зручний спосіб швидко відсіяти зовсім очевидні проблеми після деплою.

Що таке smoke test

Smoke test - це мінімальна перевірка найважливіших функцій застосунку після зміни, релізу або розгортання. Вона не повинна покривати все. Її завдання - швидко показати, чи система взагалі придатна до подальшого використання або детальнішого тестування.

Зазвичай smoke test дивиться на критичний шлях:

• чи відкривається застосунок;
• чи проходить логін або ключова авторизація;
• чи працює основна дія користувача;
• чи не падає бекенд;
• чи відповідає health endpoint або базовий API-запит.

Якщо smoke test проходить, команда отримує зелений сигнал: можна переходити до ширших перевірок, моніторингу або поступового спокійнішого спостереження.

Де новачок це бачить

• одразу після production deploy;
• після hotfix;
• перед запуском повного регресу;
• у staging перед ручним review;
• у pipeline, де треба швидко вирішити, чи release взагалі життєздатний.

Іноді smoke test роблять вручну. Іноді автоматизують як дуже короткий набір перевірок. Обидва варіанти нормальні, якщо вони швидко відповідають на одне питання: “головне живе чи ні?”.

Чого smoke test не робить

Smoke test не повинен замінювати:

• регресійне тестування;
• інтеграційні тести;
• навантажувальні перевірки;
• security checks;
• повний acceptance flow.

Це важливо, бо новачки часто очікують від нього забагато. Якщо smoke test перевіряє все підряд, він стає повільним, нестабільним і перестає виконувати свою головну роль.

Як виглядає хороший smoke test

Хороший smoke test:

• короткий;
• стабільний;
• пов’язаний із критичним користувацьким шляхом;
• запускається відразу після релізу;
• дає чіткий verdict без зайвого шуму.

Наприклад, для інтернет-магазину це може бути:

1. відкрити головну сторінку;
2. виконати логін;
3. додати товар у кошик;
4. відкрити checkout;
5. перевірити, що сервер не повертає помилку на базовому запиті.

Цього достатньо, щоб зрозуміти, чи реліз не зламав головне.

Типові помилки

Помилка 1: робити smoke test занадто великим

Якщо в нього додати десятки сценаріїв, він стане повільним і почне падати з випадкових причин.

Помилка 2: перевіряти другорядні речі замість критичних

Smoke test має захищати головний сценарій, а не колекціонувати усе, що можна автоматизувати.

Помилка 3: плутати його з регресією

Регресія відповідає на ширше питання: чи не зламалися важливі частини продукту. Smoke test відповідає на вужче: чи продукт не розвалився одразу після релізу.

Помилка 4: не знати, що робити після провалу

Якщо smoke test не пройшов, команда має мати заздалегідь визначений план: зупинити rollout, відкотити реліз, перевірити логі, сповістити відповідальних.

Що перевірити перед запуском

• Чи є один чіткий головний сценарій.
• Чи тест не дублює повний suite.
• Чи він запускається досить швидко, щоб бути корисним після деплою.
• Чи є зрозумілий owner для провалу.
• Чи відомо, де шукати перший сигнал: health check, лог, API, UI.

Короткий приклад

Якщо команда щойно викотила нову версію сервісу, smoke test може включати лише:

• перевірку доступності сторінки або API;
• базову авторизацію;
• один ключовий сценарій;
• один health check.

Якщо цей мінімум провалився, немає сенсу одразу вірити, що “все інше, мабуть, нормально”. Спершу треба зупинити rollout і розібратися, що саме зламалося.

Підсумок

Smoke test - це коротка перевірка, яка швидко показує, чи реліз не зламав головне. Він не замінює інші види тестування, але дуже корисний як перший фільтр після деплою.

Коротко: якщо full test suite перевіряє все, то smoke test перевіряє, чи взагалі є сенс іти далі.