Smoke-тестування

Smoke-набір одного магазину на одному екрані — одинадцять перевірок, що доводить кожна і що зупиняє червоний результат

Ніхто не відкриває сторінку про smoke-тестування заради історії слова. Її відкривають, бо пайплайну потрібен набір, або бо наявний набір триває сорок хвилин і на нього ніхто не чекає. Нижче — готовий набір для інтернет-магазину, чий асистент замовлень тестують сторінки про тестування AI. Він запускається після кожного розгортання в кожне середовище. Рядки 1–2 питають, чи це той білд, що розгортали, 3–6 — чи він підключений, 7–8 — чи може людина увійти, а 9–11 — чи завершується сценарій, що заробляє гроші. Наступні розділи посилаються на рядки за номерами.

Ворота, а не рівень тестування

Юніт, інтеграційний і наскрізний — це шари піраміди: вони описують, скільки системи зачіпає тест. Smoke не є одним із них. Глосарій ISTQBISTQBInternational Software Testing Qualifications Board — орган сертифікації тестувальниківМіжнародна організація, що стоїть за найпоширенішими сертифікаціями з тестування ПЗ і видає глосарій термінів тестування. Її визначення — поширене спільне джерело на співбесідах і в контрактах; вони фіксують словник, а не те, як має працювати команда.Усі терміни називає його типом тестування й визначає через призначення — здобути достатню впевненість, що обʼєкт тестування готовий до запланованого тестування. Рядки вище показують, що це означає на практиці. Рядок 1 — простий HTTPHTTPHyperText Transfer Protocol — протокол вебуПротокол, яким спілкуються браузер і сервер: клієнт надсилає метод і адресу, сервер відповідає кодом стану й тілом. Між запитами він нічого не памʼятає — кожен запит стоїть сам по собі, тому все, що треба памʼятати, передається явно.Усі терміни-запит, рядок 5 — виклик APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни, рядок 9 — сценарій у браузері, а рядок 11 — розмова з моделлю. Спільне в них — питання, і це питання про білд, а не про якусь одну фічу.

У програмну інженерію термін прийшов через щоденні білди Microsoft. 1996 року Стів Макконнелл описав цю практику в IEEE Software: щодня кожен файл компілюють і збирають у продукт, а результат проганяють через smoke-тест — «відносно просту перевірку, чи не “димить” продукт, коли працює». Образ — електриків: увімкніть нову плату й подивіться, чи не йде дим, перш ніж щось вимірювати. Макконнелл назвав smoke-тест вартовим проти проблем інтеграції, що підкрадаються непомітно, і написав, що без нього щоденний білд майже нічого не вартий.

Що належить набору — одне правило й бюджет, що його тримає

Правило відбору одне, і його варто сформулювати реченням, до якого можна прикласти будь-якого кандидата: включайте перевірку, лише якщо її падіння означає, що на цьому білді ніхто не зможе робити корисну роботу. Не «це важливо». Не «це колись зламалося». Якщо перевірка впала, а тестувальник усе одно міг би провести продуктивні пів дня, її місце в регресійному наборі. Чесно застосоване, це правило дає від пʼяти до пʼятнадцяти перевірок для звичайного продукту — у магазину їх одинадцять.

Те, як перевірка проходить, важить не менше, ніж те, які перевірки є. Код статусу доводить, що щось відповіло, а не що відповіло правильно: сторінка з написом «Щось пішло не так» усередині цілком справної відповіді 200 проходить будь-яку перевірку статусу, яку будь-коли написали. Тож кожен рядок перевіряє зміст — хеш коміту, назву товару, номер замовлення, статус, який повернув інструмент. Колонку «Проходить, лише якщо» команди пропускають найчастіше.

Бюджет часу — не побажання, а механізм. Ворота працюють, лише якщо відповідь приходить до рішення, яке вона має підказати, а рішення тут — чи починати наступному. До пʼяти хвилин — добра ціль, до десяти — стеля, яку ще можна захистити. Далі люди перестають чекати, починають паралельно, і ворота перетворюються на звіт, що приходить після шкоди.

Тут сторінка розходиться зі статтею, що дала практиці назву, і цю розбіжність варто тримати на виду. Макконнелл очікував, що smoke-тест ростиме разом із системою — від секунд на початку до «30 хвилин, години чи більше». 1996 року це було слушно: білд збирався раз на ніч, і smoke-тест, що завершувався до приходу тестувальників уранці, встигав вчасно. Команда, що розгортає десять разів на день, живе за іншим годинником. Наступна людина починає за кілька хвилин після розгортання, тож відповідь має прийти за хвилини, а набір має перестати рости. Мета та сама; розмір вирішує годинник.

Перевірки справності, smoke-тести й моніторинг відповідають на різні питання

Більшість платформ уже запускають перевірки проти сервісу, і команди іноді зараховують їх як свій smoke-набір. Це не одне й те саме, і різниця в тому, який висновок дозволено робити кожній. Kubernetes визначає три проби. Startup-проба чекає, доки повільний контейнер завершить запуск. Liveness-проба вирішує, коли перезапустити контейнер, — приклад у документації взаємне блокування. Readiness-проба вирішує, чи контейнер узагалі отримує трафік. Усі три питають про один процес, і жодна не питає, чи може клієнт купити светр.

Ті самі перевірки, що й у smoke-наборі, запущені за розкладом проти продакшну, — це синтетичний моніторинг. Він знаходить те, чого не спричинило жодне розгортання, — сертифікат, що сплив о третій ночі в неділю, платіжного провайдера, що щось змінив на своєму боці. На схемі це єдина колонка, що ловить сертифікат. Їх варто тримати як один набір скриптів із двома розкладами: те, що ворота перевіряють після розгортання, — рівно те, що ви хочете знати кожні пʼять хвилин після нього.

Де він запускається — один набір у пʼяти місцях, із пʼятьма наслідками

Більшість команд запускають smoke-набір в одному місці — зазвичай після розгортання в тестове середовище. Ті самі скрипти вартують більшого, бо в кожному середовищі відповідають на трохи інше питання, а повторний запуск коштує хвилини. Від місця до місця змінюється те, які рядки можуть виконуватися і що дозволено робити червоному результату.

Обидва варті існування й не заміняють один одного, бо падають із різних причин. Якщо можна дозволити лише один — беріть той, що після розгортання. Зламана гілка коштує одному розробнику години; зламане середовище коштує команді дня, а в продакшні — клієнтів.

Smoke, build verification, sanity, підтвердження — чотири назви, які плутають

Ці слова плутають і на співбесідах, і в командному чаті, і плутанину варто розібрати один раз. Три з них мають визначення в глосарії ISTQB. Smoke-тестування — призначення, наведене вище. Build verification test — це автоматизований тест, що перевіряє цілісність кожного нового білда та його ключову функціональність, стабільність і придатність до тестування: ті самі ворота, названі на честь білда й обовʼязково автоматизовані. Підтверджувальне тестування, або повторне тестування, виконують після виправлення дефекту, щоб підтвердити, що спричинений ним збій не повторюється. Четверте слово, sanity-тестування, у чинному глосарії не має запису взагалі — тому суперечки про нього й не закінчуються.

• Smoke

  Запускається білдом чи розгортанням. Фіксований набір, щоразу той самий. Його вердикт вирішує, чи починає роботу хтось інший.

• Build verification test

  Ті самі ворота під назвою, яку ISTQB дає їм у контексті білдів: автоматизовані, запускаються на кожному новому білді, перевіряють, чи його взагалі можна тестувати.

• Sanity

  Стандартного визначення немає. У більшості команд — короткий погляд без сценарію на ділянку, якої торкнулася конкретна зміна, щоб вирішити, чи варто планувати глибше тестування.

• Підтвердження

  Запускається виправленням. Точні кроки з баг-репорту, повторені, щоб показати, що дефекту немає. Далі це стає регресійним кейсом.

Чотири розгортання — і перевірка, якої бракувало або яку проігнорували

Жодній із цих компаній не бракувало тестів. Кожна мала перевірку, що могла зупинити розгортання, і кожна з чотирьох загубила її в іншому місці: перевірки не було там, де вона була потрібна; вона була, але її пропустили; вона спрацювала, але її ніхто не послухав; або вона запустилася тоді, коли зміна вже дісталася всім.

Де це вироджується

Чесне обмеження в тому, що smoke-набір перевіряє один білд, щасливим шляхом, в один момент. Він не бачить шляху в коді, який ще ніщо не виконувало. У червні 2025 року нова перевірка в Service Control від Google Cloud два тижні працювала в продакшні, і всі перевірки білда проходили, — доки до неї нарешті не дійшла зміна політики з порожніми полями й не поклала сервіси по всьому світу; цей випадок розповідає сторінка «Планування релізу». Конфігурація й дані змінюються після розгортання, і їм потрібні власні ворота. Зелений smoke каже, що білд вартий тестування, але ніколи — що він правильний.

Саме через нестабільність smoke-набори зазвичай і гниють. Нестабільна перевірка в регресійному наборі дратує; у smoke-наборі вона розʼїдає, бо весь механізм тримається на тому, що червоному результату вірять без обговорення. Одна перевірка, що випадково падає двічі на тиждень, привчає всіх перезапускати набір замість читати його, і ця звичка коштує вам справжнього падіння. Працює груба політика: перевірку, що падає без справжньої причини, того ж дня відправляють у карантин — прибирають із воріт, але лишають запущеною й звітують окремо, — а потім або лагодять у визначений строк, або видаляють.

• Набір перевірок «HTTP 200», який проходить і сторінка з помилкою всередині.
• Питати версію в балансувальника, тож сім правильних серверів ховають восьмий.
• Smoke, який запускають вручну, коли хтось згадає; день, коли його пропустили, — це день, коли він був потрібен.
• Результати в каналі без жодних наслідків: червоний запуск стає інформацією, а не вказівкою.
• Ворота, чий червоний результат ще жодного разу не зупинив нічого, бо самі ворота ніхто не тестував.
• Набір, лишений незмінним у продакшні, поки він пише справжні дані: одне забуте тестове замовлення на розгортання до кінця кварталу стає питанням до фінансів.
• Двадцять розумних доповнень — і набір, що тепер триває сорок хвилин і досі зветься smoke.
• Власник на імʼя «QA» — це відділ, а не людина, що полагодить червоний запуск сьогодні.
• Сприймати зелений запуск як заяву про якість.

Коли це застосовувати

Пов’язані сторінки

• QAРегресійне тестуванняРегресійне тестування — це повторний запуск тестів після зміни, щоб спіймати все, що працювало й перестало, у частинах системи, яких ніхто не збирався чіпати. Сторінка починається з шістнадцяти кейсів із набору одного магазину — чому кожен там, який рівень його доводить і коли він запускається, — далі що заслуговує на кейс і що його прибирає, яка підмножина запускається коли, нестабільні тести в цифрах, витрати, яких ніхто не планує, і чотири регресії, де кейса бракувало.
• QAНаскрізне тестування (E2E)Наскрізне тестування проводить бізнес-процес через зібрану систему від початку до кінця, як це зробив би клієнт, в умовах, близьких до продакшну. Сторінка починається з повного набору одного магазину — дванадцять маршрутів, шов, який доводить лише кожен із них, і що в ньому справжнє, а що підмінене, — далі що не доведе жоден нижчий рівень, яких форм набуває набір тестів, чого коштує червоний маршрут, як обирати маршрути й тримати їх надійними, і три збої, де тест зупинився за крок до кінця.
• ІнфраструктураCI/CDБезперервна інтеграція — це не сервер, що ганяє ваші тести, а звичка зливатися в одну спільну гілку достатньо часто, щоб конфлікти лишалися малими; автоматизація існує, щоб зробити цю звичку безпечною. Безперервна доставка — друга половина: один артефакт, зібраний один раз і просунутий середовищами без перезбирання. На цій сторінці — як упорядкувати етапи, чому нестабільний тест руйнує авторитет конвеєра, чим насправді торгують стратегії розгортання і які чотири числа кажуть, чи все це працює.