Стратегія автоматизації з нуля: аудит, пріоритети, метрики

Що таке стратегія автоматизації і чим вона відрізняється від «написати автотести»?

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

Приходиш на проєкт без автотестів. З чого почнеш?

З аудиту, а не з коду. Перш ніж писати перший expect, треба зрозуміти, що ми захищаємо і від чого: які флоу приносять гроші, як часто релізять, що вже є з інфраструктури. Стрибок одразу в написання тестів — типова пастка, яку інтерв'юер і перевіряє: можна місяць вилизувати елегантну сьюту навколо фічі, яку скоро виріжуть, і проґавити оплату, що ламається щоп'ятниці. Правильна послідовність: аудит, потім тонкий смоук і критичний шлях, далі решта ризику на нижчих рівнях піраміди. Тобто спершу карта ризику, і лише потім код під найгарячіші його зони.

Що входить в аудит перед стартом автоматизації?

Аудит — це інвентаризація трьох речей: продукту, процесу і того, що вже є. Продукт: які флоу критичні для бізнесу, які найчастіші, які найскладніші (а отже, найкрихкіші). Процес: частота релізів, тривалість ручної регресії, де в пайплайні взагалі є місце для автотестів. Наявне: чи є хоч якісь тести і в якому вони стані, чи є тестове середовище, дані, доступ до API і бази. Результат аудиту — не документ на 40 сторінок, а коротка карта: топ критичних флоу, топ проблемних зон, стан інфраструктури і чесна оцінка, що можна автоматизувати вже завтра, а що заблоковане браком середовища чи даних. Ця карта — вхід для всіх подальших рішень.

Чому історія багів у проді — найцінніше джерело під час аудиту?

Бо це факти, а не гіпотези. Баг-трекер за останній рік показує, які модулі реально ламалися, які регресії дійшли до користувача і скільки кожне падіння коштувало. Інтуїція команди про «слабкі місця» часто помиляється, а історія дефектів — ні: вона напряму вказує, де ризик матеріалізується найчастіше. Якщо escaped-дефекти купчаться навколо оформлення замовлення, там і має стояти перший автотест, навіть якщо цей код страшний і незручний для тестування. Це той самий принцип «найдорожчі баги», але поставлений на дані, а не на здогади.

Що автоматизувати першим?

Три орієнтири в порядку пріоритету: критичний шлях, смоук і найдорожчі та найчастіші баги. Критичний шлях (critical path) — флоу, без яких продукт не має сенсу: логін, оформлення, оплата, ключова дія користувача; якщо це впаде, впаде бізнес, а не одна фіча. Смоук (smoke) — тонкий зріз «система взагалі жива», дешевий і швидкий воротар на кожен деплой. Найдорожчі баги — перетин «часто ламається» і «дорого, коли ламається». Важлива поправка рівня senior: вибір коригують на стабільність фічі — нестабільне вигідніше брати не через UI, а на рівні API. «Автоматизувати все» — це не відповідь, а ознака відсутності пріоритетів.

Як вирішити, автоматизувати кейс чи лишити ручним?

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

Чому свіжу нестабільну фічу краще покривати на API, а не e2e через UI?

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

За якими критеріями обирають інструмент автоматизації?

Інструмент — похідне від контексту, а не від моди. Ключові критерії: стек команди (тести тією ж мовою, що й продукт, легше рев'ювати й ділити ownership), об'єкт тесту (web, mobile, desktop чи лише API — один інструмент рідко закриває все однаково добре), навички команди (потужний інструмент без експертизи дає флак, а не стабільність), інтеграція з CI (headless, паралелізація, збір артефактів для тріажу) і зрілість екосистеми (підтримка, спільнота, документація — тест житиме роками). Найпоширеніша помилка тут — почати з важкого e2e-інструмента «бо так по-дорослому», коли 80% ризику закрилося б API-тестами, які пишуться швидше й майже не флакають. Інструмент обирають під рівень, а не рівень під інструмент.

У вас 80% покриття — це добре?

Це питання-пастка, і правильна реакція — уточнити: 80% чого і що ці 80% реально перевіряють. Покриття коду (code coverage) — це частка рядків чи гілок, які виконалися під час прогону, а не частка перевіреної поведінки. Тест може прогнати весь модуль без жодного змістовного асерту: рядки «покриті», а поведінка ні. 100% code coverage гарантує лише, що код не падає з винятком на щасливому шляху, а не що він робить правильну річ. Це інструмент розробника для пошуку зовсім неторканих ділянок, а не доказ якості. Тому число саме по собі не означає майже нічого, поки не сказано, який ризик за ним стоїть.

Що таке чесне покриття і чому список «що НЕ покрито» такий важливий?

Чесне покриття вимірюють у термінах ризику і вимог, а не рядків коду: питання не «скільки відсотків виконано», а «які критичні флоу і продуктові ризики захищені автоматично, а які ні». Найчесніша частина звіту про покриття — це явний перелік прогалин: «оплата криптою — лише вручну», «експорт у PDF — ловимо exploratory». Метрика, яка ховає діри, гірша за відсутність метрики, бо створює хибне відчуття безпеки: команда думає, що захищена, а ризик лишається відкритим. Список непокритого перетворює покриття з цифри для звіту на інструмент для рішень — він прямо показує, куди вкладати наступний тест.

Чому «кількість автотестів» — оманлива метрика?

Бо кількість тестів — це витрати, а не результат. Тисяча тестів, з яких половина дублює одне й те саме, а третина флакі й вимкнена, — це технічний борг, а не сила. Кожен тест треба не лише написати, а й підтримувати роками; тому «написали 500 тестів за квартал» звучить як досягнення, а насправді може бути тисячею порожніх дублів. Один надійний e2e на критичний шлях цінніший за сотню тестів навколо кнопки, яку ніхто не натискає. Коли метрику кількості ставлять команді як KPI, отримують рівно те, що виміряли, — багато тестів і мало захищеного ризику.

Якими метриками ти міряєш здоров'я тестової сьюти?

Автотести — це продукт, який експлуатують, тож дивляться не лише «скільки написали», а чи набору взагалі довіряють. Ключові показники: pass rate на стабільній гілці (яка частка прогонів зелена без втручання), flaky rate (частка тестів, що падають і проходять без змін коду — метрика №1 довіри), час прогону (смоук на PR має вкладатися в хвилини), escape rate або defect leakage (скільки багів просочилося в прод попри зелену сьюту), час на діагностику падіння і частка ручної регресії, вже покрита автоматично. Слабка відповідь називає лише pass rate; сильна згадує flaky rate і escape rate, бо саме вони ловлять реальні проблеми. Мертва сьюта, якій ніхто не вірить, гірша за її відсутність, бо ще й з'їдає час на прогони.

Що таке escape rate і чому він важливіший за pass rate?

Escape rate (defect leakage) — скільки дефектів дійшло до прода попри те, що сьюта була зелена. Ця метрика ловить головну ілюзію автоматизації: тести зелені, звіт красивий, а користувач бачить помилку. Pass rate показує, чи проходять наявні тести, але нічого не каже про те, чи вони перевіряють правильні речі; escape rate б'є саме по цьому сліпому місці. Зростання escape rate — прямий сигнал, що покриття не там, де ризик: сьюта старанно перевіряє одне, а ламається інше. Тому дозріла команда стежить за витоком дефектів, а не милується зеленим pass rate.

Що таке ефект Ґудгарта і як він проявляється в метриках тестів?

Ефект Ґудгарта: щойно метрика стає ціллю, вона перестає бути хорошою метрикою. У тестуванні це видно одразу. Поставиш команді KPI «кількість автотестів» — отримаєш тисячу порожніх тестів без асертів. Поставиш «pass rate 100%» — отримаєш try/catch навколо перевірок, щоб нічого не червоніло. Механізм у тому, що люди оптимізують саме те число, за яким їх оцінюють, а не мету, яку число мало відображати. Практичний наслідок: метрики здоров'я потрібні, щоб приймати рішення всередині команди, а не щоб ними звітувати вгору; щойно показник стає предметом звіту, його починають «малювати».

Як розкласти roadmap автоматизації фазами?

Фазами, де кожна приносить відчутну цінність сама по собі, щоб проєкт можна було зупинити чи перепріоритезувати будь-коли, не лишившись із наполовину написаним нічим. Фаза 0 — інфраструктура: обраний інструмент, конфігурація середовищ, тестові дані, стабільні локатори, запуск у CI (без цього перший же тест обросте болем). Фаза 1 — тонкий смоук плюс кілька e2e на критичний шлях: команда одразу отримує воротаря, який ловить катастрофи до релізу. Фаза 2 — розширення в глибину за пріоритетом ризику. Фаза 3 — коли набір великий, фокус зміщується на час прогону, стабільність і вартість підтримки. Кожна фаза замкнена на результат, а не на «дописати ще трохи».

Чому віху roadmap прив'язують до захищеного ризику, а не до кількості тестів?

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

Що НЕ треба автоматизувати?

Улюблене senior-питання, бо демонструє зрілість. Не автоматизують: exploratory-тестування, оцінку usability, візуальну естетику й разові дослідження — там незамінне людське судження; рідкісні та дешеві в ручній перевірці сценарії (одноразова міграція, екзотичний крайовий випадок); нестабільний UI на ранній фічі, де тест переписуватимеш щодня; і будь-що, де вартість підтримки перевищує цінність — іноді чесніше видалити тест, ніж тримати. За цим стоїть закон спадної віддачі: перші тести на критичний шлях окупаються миттєво, а кожен наступний на дедалі рідший сценарій приносить дедалі менше за ту саму ціну підтримки. Настає точка, де година в новий тест дає менше, ніж та сама година в exploratory чи стабілізацію наявного.

Як довести цінність автоматизації менеджменту?

Не кількістю тестів і не відсотком покриття, а мовою ризику й грошей. Три робочі аргументи: скільки ручної праці звільнено (частка регресії, яку більше не ганяють руками), скільки дорогих багів спіймано до прода (і скільки коштувало б кожне падіння в проді), наскільки скоротився час регресії перед релізом. Менеджмент мислить наслідками для бізнесу, а не піраміда-це-добре; «покрили критичний платіжний флоу, тепер він не зламається непомітно між релізами» звучить переконливіше за «маємо 80% покриття». Зрілий інженер міряє успіх автоматизації саме звільненою працею і спійманими багами, а коли ці показники перестають рости від нових тестів — переносить ресурс з написання на підтримку й швидкість того, що вже є.

Три кейси, які показують стратегію в дії, а не в теорії: як зібрати карту аудиту з баг-трекера, як прогнати кандидатів через матрицю пріоритету «цінність × вартість × стабільність» і як зашити roadmap у теги прогонів. Скрізь — не «що правильно взагалі», а що робити з конкретними цифрами на столі.

Кейс 1. Аудит: перетворити баг-трекер на карту ризику

Заходиш на маркетплейс без автотестів. Замість «покрию все підряд» відкриваєш баг-трекер за останній рік і рахуєш дефекти по модулях плюс їхню вагу (втрачені гроші, зачеплені користувачі, час на хотфікс). Виходить не гіпотеза, а факт про те, де продукт реально ламається:

Що з цього читається і чому:

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

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

Кейс 2. Матриця пріоритету: цінність × вартість підтримки × стабільність

Аудит дав список кандидатів. Тепер кожного проганяємо через три питання: наскільки цінний (критичний шлях чи дорогий баг), наскільки стабільна фіча під ним, скільки коштуватиме підтримка. Рішення випадає майже автоматично:

Логіка рішень:

• Висока цінність + стабільна фіча — беззаперечне «автоматизувати зараз». Оплата сюди підходить ідеально: впаде — впаде бізнес, а верстка усталена, тож тест не переписуватимеш щотижня.
• Висока цінність, але нестабільна фіча — не привід для e2e. Редизайн чекауту цінний, але поки екран міняється щодня, e2e-тест на нього — переписування коду замість тестування. Бізнес-логіку беруть на API, e2e додають після стабілізації.
• Та сама перевірка на найнижчому рівні. Знижку рахують юнітом чи API-тестом, а не кліками через кошик: результат той самий, ціна підтримки в рази менша.
• Низька цінність або разовість — свідоме «ні». PDF-експорт і одноразова міграція не варті автотеста; чесніше залишити їх ручним, ніж роздувати сьюту тим, що майже не окупається.

Головне, що ловить ця матриця: пріоритет за ризиком, а не за легкістю. Найгірший сценарій — покрити просте й стабільне (бо швидко пишеться), а критичну оплату лишити ручною, бо вона «складна».

Кейс 3. Roadmap у тегах: смоук на PR, регресія вночі

Roadmap не живе в презентації — він зашитий у те, що і коли ганяє CI. Розкладку прогонів розводять тегами: критичний шлях і смоук ловлять катастрофи за хвилини на кожному PR, широка регресія їде вночі або перед релізом, коли час прогону вже не критичний.

import { test, expect } from '@playwright/test';

// Фаза 1: критичний шлях — воротар на кожен деплой
test('checkout: оплата картою проходить', { tag: ['@critical', '@smoke'] }, async ({ page }) => {
  // ...тонкий наскрізний сценарій, ганяємо на кожен PR
});

// Фаза 2: ширша регресія — не блокує PR, їде вночі
test('checkout: експорт історії замовлень у CSV', { tag: ['@regression'] }, async ({ page }) => {
  // ...покриття в глибину за пріоритетом ризику
});

У PR-чеку ганяють лише швидкий зріз, щоб фідбек був за хвилини, а не години:

# На кожен PR — тільки смоук і критичний шлях
npx playwright test --grep "@smoke|@critical"

# Повна регресія — окремий нічний прогін
npx playwright test --grep @regression

Що тут важливо для стратегії, а не лише для конфіга:

• Фази roadmap = теги. @smoke/@critical — це фаза 1 (воротар), @regression — фаза 2 (глибина). Розкладка прогонів прямо відображає пріоритет за ризиком, а не «ганяємо все й чекаємо годину».
• Час прогону — метрика здоров'я, а не дрібниця. Смоук на PR має вкладатися в хвилини; якщо повний набір розрісся до годин, це вже гальмо, а не швидкий фідбек — лікується паралелізацією та шардінгом, а не тим, щоб ганяти все підряд на кожен коміт.
• Віха формулюється мовою ризику. «Критичний шлях оплати покрито наскрізним тестом на кожен деплой» — це віха roadmap; «додали 40 @regression-тестів» — це витрати, які самі по собі нічого не гарантують.
• Сьюту супроводжує команда, а не герой. Теги й розкладка мають бути зрозумілі всім, хто робить рев'ю: ownership тестів — частина стратегії, інакше набір тихо помирає разом із тим, хто його писав.

Аудит і вхід на проєкт

• Розумію, що стратегія починається з аудиту, а не з коду: спершу карта ризику, потім перший expect.
• Можу перелічити три предмети аудиту: продукт (критичні й часті флоу), процес (частота релізів, ручна регресія, місце в пайплайні), наявне (тести, середовище, дані, доступи).
• Знаю, чому історія багів у проді — найцінніше джерело: це факти про реальні поломки, а не інтуїція про «слабкі місця».

Вибір кейсів і пріоритети

• Можу назвати три орієнтири в порядку пріоритету: критичний шлях, смоук, найдорожчі та найчастіші баги.
• Розумію, чому «автоматизувати все» — це відсутність стратегії, а не стратегія (вичерпне тестування неможливе, а кожен тест дорогий у підтримці).
• Можу пояснити квадрант «цінність проти вартості підтримки» і чому нестабільну фічу автоматизувати зараз — негативна окупність.
• Знаю, що пріоритет ставлять за ризиком, а не за легкістю написання: складний платіжний флоу важливіший за просту стабільну кнопку.

Рівні й інструменти

• Розумію правило піраміди в стратегії: кожну перевірку роблю на найнижчому рівні, де вона ще має сенс.
• Можу пояснити, чому свіжу нестабільну фічу вигідніше брати на API/юніті, а не e2e через UI.
• Знаю критерії вибору інструмента: стек команди, об'єкт тесту, навички, інтеграція з CI, зрілість екосистеми.

Чесне покриття

• Знаю різницю: «80% покриття» саме по собі нічого не значить — покриття рядків (code coverage) ≠ перевірена поведінка ≠ покритий ризик.
• Розумію, що чесне покриття міряють у термінах ризику й вимог, а найчесніша його частина — явний список того, що НЕ покрито.
• Можу пояснити, чому «кількість автотестів» — метрика марнославства: тисяча дублів це борг, а не сила.

Метрики здоров'я сьюти

• Знаю ключові метрики: pass rate, flaky rate, час прогону, escape rate, час на діагностику, частка автоматизованої регресії.
• Розумію, чому flaky rate — метрика №1 довіри, а один живучий флакі в quality gate знецінює весь набір.
• Можу пояснити, чому escape rate важливіший за pass rate: він ловить ілюзію «тести зелені, а користувач бачить помилку».
• Розумію ефект Ґудгарта: метрика-ціль перестає бути метрикою (KPI «pass rate 100%» → try/catch навколо асертів).

Roadmap і коли зупинитися

• Можу розкласти roadmap фазами (0 — інфраструктура, 1 — смоук і критичний шлях, 2 — регресія за ризиком, 3 — оптимізація), де кожна фаза цінна сама по собі.
• Розумію, що віха прив'язана до захищеного ризику, а не до кількості тестів («критичний шлях оплати покрито» — віха; «500 тестів» — витрати).
• Знаю ознаки «пора зупинитися»: вартість підтримки понад цінність, рідкісний і дешевий у ручній перевірці сценарій, зона за природою ручна, нестабільний UI.