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

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

Юніт, інтеграційний і наскрізний — це рівні: вони описують, скільки системи зачіпає тест. Smoke не є одним із них. Це призначення, і його можна скласти з тестів будь-якого рівня — виклик API, сценарій у браузері, health-проба, будь-що, що відповість найшвидше. Питання завжди те саме, і воно про білд, а не про фічу: чи піднялося це розгортання в стані, у якому подальша робота має сенс?

Назва прийшла з апаратури. Ви збираєте плату, подаєте живлення й дивитеся, чи не пішов дим, — ви нічого не вимірюєте, ви перевіряєте, що річ явно не знищила себе, перш ніж вкладатися у вимірювання. Програмна інженерія запозичила метафору буквально. У безперервній доставці той самий набір часто називають build verification test, і обидві назви описують один обʼєкт: малий фіксований набір перевірок, що запускається одразу після розгортання білда й видає один бінарний вердикт.

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

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

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

Де він запускається — а запускається він не в одному місці

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

• Після розгортання в тест

  Класична позиція. Відповідає «чи вартий цей білд передачі в QA», і результат має блокувати передачу, а не супроводжувати її приміткою.

• Після розгортання в стейджинг

  Відповідає на інше питання: чи правильно налаштоване СЕРЕДОВИЩЕ. Більшість падінь тут — секрети, рядки підключення й DNS, а не код.

• Після розгортання в продакшн

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

• За розкладом у продакшні

  Ті самі перевірки кожні кілька хвилин — це синтетичний моніторинг: він знаходить поломки, яких не спричинило жодне розгортання: сертифікат, що сплив, залежність, що впала сама.

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

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

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

• Smoke

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

• Sanity

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

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

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

Що має бути правдою, щоб ворота справді працювали

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

• Він блокує. Червоний smoke зупиняє передачу, зупиняє промоушн або автоматично запускає відкат. Набір, падіння якого обговорюють, а не виконують, — це дашборд.
• Йому вірять, а отже, нестабільність — це інцидент. Одна перевірка, що випадково падає двічі на тиждень, привчає всіх перезапускати набір замість читати його, і ця звичка коштує вам справжнього падіння.
• У нього є власник. Не «QA» як відділ, а названа людина чи ротація, від якої очікують полагодити червоний smoke сьогодні, а не завести тікет.
• Він достатньо швидкий, щоб на нього чекали. Кожна додана хвилина — це хвилина чийогось простою, і саме цей тиск змушує команди починати роботу до появи результату.

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

Антипатерни, які варто назвати

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

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

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

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