Уявіть, що ви щойно зібрали новий автомобіль. Перш ніж випустити його на трасу для повноцінних випробувань, ви спершу перевірите найпростіші речі: чи заводиться двигун, чи крутяться колеса, чи горять фари. Якщо машина навіть не заводиться — немає сенсу перевіряти гальма на швидкості 200 км/год. Саме так працює QA-інженер із трьома базовими видами тестування: smoke, sanity та regression. Це не просто три галочки в чек-листі — це фільтр, який рятує команди від хаосу, дорогих багів і зіпсованої репутації продукту.
У цій статті розберемо кожен вид тестування окремо, покажемо, чим вони відрізняються, наведемо живі приклади з практики та подивимось, як із подібними викликами справляються великі компанії на кшталт Google, Microsoft чи Netflix.
НАВІЩО ВЗАГАЛІ ДІЛИТИ ТЕСТУВАННЯ НА ЕТАПИ
Новачки в QA часто думають, що тестування — це один суцільний процес: взяли білд, протестували все підряд, знайшли баги, здали. На практиці все набагато прагматичніше. Часу завжди мало, реліз горить, а тестове покриття продукту може налічувати тисячі сценаріїв. Тому тестування структурують за принципом «від грубого до тонкого»: спочатку швидко перевіряємо, чи продукт взагалі живий, потім — чи конкретна зміна працює як слід, і насамкінець — чи ми нічого не зламали в тому, що вже працювало раніше.
Це схоже на медичний огляд. Лікар спочатку заміряє тиск і пульс (базові показники життя), потім, якщо ви прийшли з болем у коліні, огляне саме коліно (цільова перевірка), а вже потім, якщо є підозра на щось серйозніше, призначить повне обстеження всього організму (комплексна перевірка). Ніхто не робить МРТ всього тіла заради нежитю.
SMOKE-ТЕСТУВАННЯ: ЧИ ВЗАГАЛІ «ДИХАЄ» ПРОДУКТ
Smoke testing — це найшвидша і найповерхневіша перевірка, яка відповідає на одне-єдине питання: чи можна взагалі працювати з цим білдом?
Термін прийшов з електротехніки: коли інженери вмикали новий пристрій уперше, вони перевіряли найпростішу річ — чи не пішов з нього дим. Якщо пішов — подальше тестування безглузде, пристрій одразу вимикали. У software-розробці логіка та сама: якщо застосунок не відкривається, не логінить користувача або падає на головному екрані — немає сенсу перевіряти щось складніше.
Уявіть інтернет-магазин. Команда випустила новий білд напередодні Black Friday. QA-інженер запускає smoke-тест — короткий сценарій на 10-15 хвилин:
- Застосунок запускається без крашу
- Користувач може зареєструватися і залогінитися
- Головна сторінка й каталог товарів відкриваються
- Товар можна додати в кошик
- Кошик відкривається, і сума рахується коректно
- Процес оплати ініціюється (без обов'язкового завершення транзакції)
Якщо хоча б один із цих пунктів провалюється — білд одразу відхиляють і повертають розробникам, не витрачаючи часу команди на подальше тестування. Це принцип fail fast — краще втратити 15 хвилин на smoke-тест, ніж 8 годин на повне регресійне тестування білда, який все одно доведеться відкинути.
ЯК ЦЕ РОБЛЯТЬ ВЕЛИКІ КОМПАНІЇ
У Google практика smoke-тестування настільки автоматизована, що вона вбудована прямо в CI/CD-пайплайн. Кожен коміт, який потрапляє в основну гілку коду, автоматично проганяється через набір presubmit tests — по суті, це той самий smoke-тест, тільки виконує його не людина, а автоматизована система за лічені хвилини. Якщо presubmit провалюється, коміт просто не потрапляє в основну гілку — розробник отримує миттєвий фідбек і виправляє проблему до того, як вона зачепить когось іншого.
Схожий підхід і в Netflix: перед тим, як новий реліз потрапляє бодай на невеликий відсоток користувачів (канарковий реліз), система автоматично перевіряє базову працездатність сервісу — чи стартує відео, чи працює рекомендаційний алгоритм, чи не зростає різко кількість помилок 500.
Ключова характеристика smoke-тесту: він широкий, але неглибокий. Ми перевіряємо кожну ключову функцію по верхах, не заглиблюючись у деталі й edge-кейси.
SANITY-ТЕСТУВАННЯ: ЧИ ПРАЦЮЄ ТЕ, ЩО ЗМІНИЛИ
Якщо smoke-тест — це перевірка «продукт живий загалом», то sanity testing — це точковий, сфокусований аналіз конкретної зміни або конкретного бага, який щойно виправили.
Уявіть, що ви віддали автомобіль в сервіс через скрип гальм. Механік каже: «Готово, забирайте». Перш ніж їхати в довгу подорож, ви не будете перевіряти весь автомобіль заново (це вже було зроблено раніше) — ви натиснете на гальма кілька разів на невеликій швидкості, переконаєтесь, що скрипу немає, і що машина зупиняється нормально. Це і є sanity-check: вузька, глибока, цільова перевірка саме тієї зміни, яка була внесена.
Розробник виправив баг: при застосуванні промокоду на суму знижки 100% ціна товару йшла в мінус. QA отримує білд і робить sanity-тест:
- Застосовує саме той промокод, який спричиняв баг
- Перевіряє, що ціна коректно стає 0, а не негативною
- Перевіряє кілька сусідніх сценаріїв — промокод на 50%, промокод, що вже не діє, промокод з мінімальною сумою замовлення
Зверніть увагу: QA-інженер не перевіряє весь функціонал кошика заново, не тестує доставку, не перевіряє реєстрацію нового користувача. Фокус — виключно на зоні, яку торкнулася зміна, плюс найближче логічне оточення цієї зміни.
ПРИКЛАД З ПРАКТИКИ ВЕЛИКИЙ КОМПАНІЙ
У Microsoft, коли команда Windows випускає патч, що виправляє конкретну вразливість або баг у певному модулі (наприклад, у драйвері принтера), QA-команда спершу проводить cаніті-перевірку саме цього модуля на обмеженому наборі конфігурацій, перш ніж патч потрапить у широке регресійне тестування на десятках комбінацій «версія Windows + драйвер + периферія». Це економить величезну кількість машинного часу й людських ресурсів — навіщо ганяти повний regression-набір, якщо є підозра, що фікс взагалі не спрацював?
Головна відмінність sanity від smoke: smoke — широкий і неглибокий (перевіряємо все по трошки), sanity — вузький і глибокий (перевіряємо мало, але детально).
РЕГРЕСІЙНЕ ТЕСТУВАННЯ: ЧИ НЕ ЗЛАМАЛИ МИ ЩОСЬ СТАРЕ
Найбільш ресурсоємний і водночас найважливіший вид перевірки — regression testing. Його мета: переконатися, що нові зміни (нова функція, фікс бага, оновлення бібліотеки) не зламали функціонал, який раніше працював коректно.
Ця проблема має назву regression («регрес», відкат назад) саме тому, що продукт ніби «відкочується» у гіршому напрямку — щось, що вчора працювало, сьогодні перестало.
ЧОМУ ЦЕ СПРАВДІ СКЛАДНО
Уявіть будинок із карткової колоди. Кожна нова картка (фіча) спирається на попередні. Додаючи нову картку зверху, ви ризикуєте похитнути всю конструкцію знизу. У складному програмному продукті модулі переплетені так само: зміна в системі оплати може несподівано вплинути на систему знижок, зміна в бібліотеці авторизації — на роботу пуш-сповіщень, і так далі. Що більший і старіший продукт, то вища ймовірність таких прихованих зв'язків.
Команда розробила нову функцію — можливість оплати частинами (Buy Now, Pay Later). Функція начебто ізольована: новий екран, нова кнопка, новий бекенд-сервіс. Але після релізу з'ясувалося, що:
- У користувачів, які обирали оплату частинами, переставав коректно рахуватися кешбек за програмою лояльності (бо кешбек рахувався від суми одноразової транзакції, а не часткової)
- Email-сповіщення про підтвердження замовлення дублювалися, бо тепер створювалось два записи в базі замість одного
Жоден з цих двох багів не пов'язаний напряму з новою кнопкою оплати частинами. Але вони виникли через цю зміну — і саме такі приховані наслідки й покликане виявляти регресійне тестування.
ЯК ВЕЛИКІ КОМПАНІЇ БОРЮТЬСЯ З ЦІЄЮ ПРОБЛЕМОЮ
Facebook (Meta) свого часу зіткнулися з класичною проблемою масштабу: команда з тисяч інженерів комітить код у монолітний репозиторій десятки разів на день. Ручний регрес такого обсягу фізично неможливий. Рішення — масштабна автоматизація: тисячі автоматизованих регресійних тестів запускаються на кожен pull request, а система пріоритизації тестів (test impact analysis) визначає, які саме тести варто запустити залежно від того, які файли змінилися, щоб не ганяти весь набір щоразу.
Amazon пішов ще далі: у них є принцип «you build it, you run it» — команда, яка розробляє фічу, сама відповідає за її регресійне покриття автотестами. Це знижує ризик того, що QA-команда, не занурена в контекст конкретного модуля, пропустить неочевидний зв'язок між компонентами.
Але навіть у гігантів регресія час від часу «прориває оборону». Класичний приклад — масштабний збій Facebook, Instagram та WhatsApp у жовтні 2021 року, коли помилкова конфігураційна зміна в мережевій інфраструктурі призвела до того, що сервіси стали недоступні на кілька годин для мільярдів користувачів. Це нагадування: чим складніша система, тим важче передбачити всі побічні ефекти навіть за наявності потужної автоматизації.
Регресія — це страховка, яку ви купуєте не тому, що плануєте аварію, а тому що знаєте: рано чи пізно щось піде не так, і краще дізнатися про це до релізу, а не після скарг користувачів.
Рекомендуємо курси по темі
ТИПОВІ ПОМИЛКИ ПОЧАТКІВЦІВ
Розглядаючи цю тему зі студентами курсів QA, я регулярно бачу одні й ті самі помилки:
Плутанина між smoke і sanity. Багато хто вважає, що це синоніми, бо обидва «швидкі». Але ключова відмінність — у меті. Smoke відповідає на питання «чи варто взагалі тестувати цей білд», sanity — «чи працює саме ця конкретна зміна».
Спроба зробити повний регрес вручну щоразу. На маленьких проєктах це можливо, але на продукті з тисячами тест-кейсів це фізично нездійсненно без автоматизації. Тому регресійні набори — перший кандидат на автоматизацію в будь-якій QA-стратегії.
Ігнорування smoke-тесту через «економію часу». Часта помилка молодих команд: «та ми і так все перевіримо в регресії, навіщо ще й смоук». Але саме smoke дозволяє відсіяти зовсім непрацездатні білди на ранньому етапі, до того, як команда витратить години на детальне тестування того, що все одно доведеться відкинути.
Нерозуміння, що regression — це не «тестування всього підряд». Грамотний QA-інженер не запускає весь набір тестів наосліп щоразу, а аналізує, які зони продукту потенційно могли постраждати від конкретної зміни (так званий impact analysis), і пріоритизує тести відповідно.
Рекомендуємо публікації по темі
