Автоматизація в процесі розробки: shift-left і ownership

Що таке shift-left простими словами?

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

Shift-left — це про більше ручного тестування на ранній стадії?

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

Чи вичерпується shift-left автоматизацією?

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

Що таке self-testing code і чому він важливий для shift-left?

Self-testing code (код, що сам себе перевіряє) — це властивість кодової бази, за якої разом із кодом лежить набір автотестів, а будь-яка збірка автоматично їх проганяє й сама повідомляє, справна вона чи зламана. Без цього shift-left лишається гаслом: немає автоматичного вердикту — немає й швидкого фідбеку. Механізм простий: тести їдуть у тому ж репозиторії, що й код, і запускаються на кожну збірку без ручної команди. Практичний наслідок — розробник не мусить памʼятати «а треба ще перевірити», бо збірка сама червоніє на регресі. Це фундамент, на якому тримається self-testing build і вся дисципліна безперервної інтеграції.

Хто має писати автотести — розробники чи AQA?

Питання не про посади, а про відповідальність (ownership), і сильна відповідь не рубає «звісно AQA». Природний розподіл підказує піраміда: unit- та інтеграційні тести живуть найближче до внутрішнього коду, тож їх логічно писати тим, хто цей код написав — розробникам; API- та e2e-рівень ближчий до автоматизаторів (AQA/SDET). А відповідальність за зелену збірку — спільна: полагодити червоний тест мусить той, хто його зламав, а не абстрактна «команда тестування». Модель, де окрема AQA-команда наздоганяє чужі фічі тестами, структурно програє: тести відстають, розробники не почуваються власниками сьюти, а знання про фічу й про її тест живуть у різних головах. Тому правильна рамка відповіді — розвести рівні й підкреслити спільну відповідальність.

Які є моделі володіння тестами і чим вони відрізняються?

Їх три. Перша — окрема AQA-команда пише всі тести: розробники кидають фічу, автоматизатори наздоганяють; наслідок — тести відстають, ніхто з розробників не власник зеленої збірки, народжуються тести-сироти. Друга — розподіл за рівнями піраміди: розробники володіють unit/інтеграцією, AQA/SDET — API/e2e; розумний компроміс, що спирається на природу рівнів. Третя — спільне володіння (whole-team approach): тест входить у визначення «готово», лежить у тому ж PR, що й код, а червоне чинить автор зміни. Ключові осі порівняння — швидкість фідбеку (від низької до високої), ризик тестів-сиріт (від високого до низького) і хто відповідає за червону збірку. Whole-team дає найшвидший фідбек і найменший ризик сиріт, бо власником якості стає вся команда.

Що таке whole-team approach і що він насправді змінює?

Whole-team approach — усталений термін з Agile-тестування: за якість продукту відповідає вся команда, а не окремий відділ контролю. Він не скасовує спеціалізацію — глибокі e2e-сценарії й тестову архітектуру все одно тягне AQA/SDET, — але лікує головну хворобу сегрегації. Хвороба ця в тому, що коли ніхто не почувається власником червоної збірки, вона просто лишається червоною. У whole-team тест — частина Definition of Done фічі, він у тому ж pull request, що й код, і зламаний тест чинить той, хто його зламав. Практичний наслідок: сьюта перестає бути «чужою» для розробників і не перетворюється на занедбаний цвинтар, який усі бояться чіпати.

Звідки беруться тести-сироти?

Тест-сирота — це тест, за який ніхто не почувається відповідальним, тому його ніхто не лагодить, не оновлює й боїться чіпати. Народжує їх сегрегація: коли окрема AQA-команда пише тести пост-фактум, знання про фічу лишається в розробника, а тест — у автоматизатора, і жоден із них не власник результату. Розробник не писав цей тест і не розуміє його; автоматизатор не писав фічу й не встигає за її змінами. Наслідок — тест структурно відстає від коду, дублює інші перевірки або тихо гниє в червоному стані. Лікування системне, а не косметичне: перенести володіння ближче до автора коду (whole-team або розподіл за рівнями), щоб у кожного тесту був живий власник.

Навіщо вносити тести в Definition of Done?

Бо без цього «написати тест» лишається доброю волею, а добра воля програє наступній фічі, яка вже горить. Definition of Done (визначення «готово») — це командна угода, за якою фіча не вважається завершеною, поки на неї немає тестів відповідного рівня; це рядок у DoD, а не усна домовленість. Логіка проста: якщо тест не входить у «готово», його завжди можна відкласти на «потім», а «потім» на практиці означає «ніколи». Внесення тесту в DoD робить його невідкладним — фіча просто не закривається без нього. Разом із обовʼязковим PR-чеком це перетворює shift-left із гасла на процес.

Що таке required status checks і як branch protection тримає shift-left?

Required status checks (обовʼязкові перевірки статусу) — це технічне втілення Definition of Done у системі контролю версій. Через branch protection (захист гілки) репозиторій налаштовують так, що злити гілку в основну не можна, поки обовʼязкові перевірки не позеленіли: лінт, перевірка типів, unit-тести, вузький смоук. Гейт стоїть саме там, де дефект найдешевший — до потрапляння коду в main. Ключова властивість — його не обійти домовленістю: якщо перевірка червона, кнопка мержу заблокована фізично. Саме тому DoD плюс PR-чек — єдина надійна пара, що не дає відкласти тест на «колись»: зміна просто не доїде до основної гілки без нього.

Чому один флакі-тест здатен знецінити всю сьюту?

Гейт має цінність рівно доти, доки червоне означає реальну проблему — це негласний контракт між сьютою і командою. Один стабільно-нестабільний (flaky) тест цей контракт ламає: команда бачить червоне, знизує плечима, перезапускає прогін — і він зеленіє сам собою. Одного разу спрацювало, другого, третього, і формується звичка не дивитися на падіння. Проблема не в тому, що флакі ламає один сценарій, а в тому, що він вчить команду не вірити гейту взагалі. І в день, коли червоним стане справжній регрес, його теж перезапустять у забуття тим самим рефлексом. Тому терпимий флакі — це не косметичний дефект одного тесту, а підрив довіри до всієї сьюти.

Що таке нормалізація відхилень і до чого вона в тестах?

Нормалізація відхилень (normalization of deviance) — це поступове звикання команди до того, що раніше вважалося неприпустимим, доки воно не стане фоновою нормою. У тестах вона розгортається так: спершу червоне падіння — це стоп-сигнал, потім «та це знову той флакі, клікни retry», а далі «червоне — це нормально». Кожен успішний перезапуск підкріплює звичку не сприймати падіння всерйоз. Небезпека в тому, що межа між «терпимим шумом» і «реальним регресом» стирається — команда перезапускає все підряд, не дивлячись. Саме тому дисципліна вимагає не терпіти флакі як фон, а лікувати його або виносити в карантин, поки контракт «червоне = проблема» ще живий.

Тест іноді падає в CI, а локально зелений. Який твій перший рух?

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

Що таке дисципліна зеленої збірки і хто чинить червоне?

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

Що ганяти на кожен PR, а що — вночі?

Тут працює компроміс швидкість проти повноти покриття: чим ширший набір тестів, тим довший прогін, а довгий прогін на кожен PR зупиняє команду. Тому сьюту розкладають по стадіях. На PR — швидкий блокувальний набір: лінт, перевірка типів, unit-тести і вузький смоук найкритичніших шляхів; ціль тут хвилини, бо саме цей прогін стоїть між розробником і мержем. Уночі (nightly) — повна регресія: e2e на всіх браузерах, довгі сценарії, крос-конфігурації; вона йде довго й зазвичай не блокує мерж, а дає команді ранковий звіт про стан продукту. Перед релізом — повний прогін плюс ручні й дослідницькі перевірки, результат яких входить у рішення про готовність. Сильна відповідь називає смоук на PR, повну регресію вночі й пояснює чому саме так.

Чому nightly зазвичай не блокує мерж?

Бо повна регресія довга й ширша, і якби вона блокувала кожен PR, команда стояла б годинами замість хвилин. Nightly радше грає роль ранкового звіту: вночі проганяється весь набір e2e на всіх конфігураціях, а вранці команда бачить, у якому стані продукт, і розбирає падіння окремою дисципліною тріажу. Швидкість тут забезпечує паралелізація, а не звуження набору. Блокувати мерж лишається швидкий надійний смоук на PR — там гейт має право зупиняти, бо він короткий і стабільний. Виносити повільні й історично флакі e2e з блокувальних PR-чеків у nightly — типове й розумне інженерне рішення: PR не гальмується, а покриття не втрачається, просто зсувається за часом.

Що таке quality gate?

Quality gate (гейт якості) — це автоматичний критерій, який блокує просування зміни далі конвеєром: не пройшов — не мержиш або не деплоїш. Найтиповіший приклад — обовʼязкові PR-чеки: лінт, типи, unit, смоук мають бути зеленими, інакше кнопка мержу заблокована. Головна властивість гейта — він має право зупиняти рух, тому те, що робити блокувальним, є інженерним рішенням із наслідками. Зробиш блокувальним повільний флакі e2e — команда буде стояти й перезапускати; лишиш надто мало — регрес просочиться. Гейт працює рівно доти, доки його вердикт вартий довіри: щойно червоне перестає означати реальну проблему, гейт втрачає сенс, навіть якщо технічно він на місці.

Чи має падіння e2e блокувати мерж?

Єдиної правильної відповіді тут немає, і саме на це дивиться інтервʼюер — на аргументацію, а не на «так» чи «ні». Зважувати треба кілька осей: стабільність сьюти (наскільки цей e2e надійний чи історично флакі), критичність шляху (це checkout чи другорядний екран), час прогону (хвилини чи 40 хвилин на кожен пуш) і ціну помилково заблокованого мержу. Часто розумний баланс — лишити на PR тільки швидкий надійний смоук найкритичніших шляхів, а повільні й флакі e2e винести в nightly, де вони дають звіт, а не блокують. Якщо ж e2e стабільний, короткий і покриває критичний шлях — його блокувальність виправдана. Слабка відповідь — категоричне «завжди блокувати» або «ніколи не блокувати» без аналізу компромісів.

Coverage як quality gate — чому це палиця з двома кінцями?

Бо жорсткий поріг на цифру покриття (coverage) оптимізує метрику, а не якість перевірок. Коли гейт вимагає умовних 90%, зʼявляються тести, написані заради відсотка, а не заради перевірки: код виконується, рядки «покриті», але асертів немає або вони порожні. Формально гейт зелений, фактично ці тести нічого не гарантують — вони прогнали код і не перевірили результат. Тобто метрика показує, що код виконувався в тесті, але не те, що його поведінку хтось перевірив. Coverage корисний як орієнтир і сигнал про голі зони, але як жорсткий блокувальний гейт він частіше народжує імітацію тестування, ніж реальне покриття. Сильна відповідь розрізняє «покриття як індикатор» і «покриття як самоціль».

Як технічно розкласти сьюту по стадіях?

На рівні коду розкладка спирається на теги: критичні смоук-сценарії позначають тегом, і PR ганяє лише їх, а nightly — увесь набір. У Playwright це виглядає як позначка в назві тесту, наприклад @smoke, і різні команди запуску: npx playwright test --grep @smoke на PR і npx playwright test уночі. Так один і той самий набір тестів обслуговує різні стадії з різними вимогами до швидкості й до права блокувати. Перевага підходу — не треба тримати окремі копії тестів чи окремі проєкти: розкладка задається фільтром на прогоні. Головне — дисципліновано тегувати саме критичні швидкі шляхи як смоук, інакше PR-прогін або роздується, або пропустить важливе.

Три ситуації, у яких shift-left і ownership перестають бути теорією: таблиця рішень «що робити блокувальним на PR, а що зсувати в nightly», розбір занедбаної сьюти з діагнозом по симптомах, і природна прив'язка до коду — теги, якими одна сьюта обслуговує дві стадії.

Кейс 1. Що ставити блокувальним на PR: таблиця рішень

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

Що дивитися і чому:

• Блокувальним ставлять швидке й надійне. Гейт стоїть між розробником і мержем, тому його ціль — хвилини. Лінт, типи, unit і вузький смоук дають дешевий вердикт «не зламав очевидне» за той час, поки людина не встигла перемкнутися на іншу задачу.
• Повільне й широке зсувають у nightly. Повна регресія на всіх конфігураціях довга; якби вона блокувала кожен пуш, команда стояла б годинами. Уночі вона встигає прогнатися й дає ранковий звіт, а не гальмує мерж.
• Історично флакі e2e — не на PR. Тест із низькою стабільністю в блокувальному чеку не захищає, а руйнує довіру: команда звикає перезапускати його не дивлячись. Його місце — карантин або nightly, доки причину не полагоджено.
• Coverage у цій таблиці навмисно немає як блокувального гейта. Жорсткий поріг на цифру покриття породжує тести без асертів, написані заради метрики. Покриття корисне як індикатор голих зон, але блокувати мерж «бо 89%, а треба 90%» — це оптимізація числа, а не якості.

Кейс 2. Занедбана сьюта: діагноз по симптомах

На проєкт приходить новий інженер і бачить класичну картину: автотести є, але фічі виходять раніше за тести; сьюта тижнями червона; половина падінь «іноді сама зеленіє після retry». Формально автоматизація є — фактично вона нічого не гарантує. Розбір іде по симптомах, а не по «перепишімо все».

Симптом 1: тести відстають від фіч на кілька спринтів. Це не лінь конкретної людини, а наслідок моделі володіння. Якщо тести пише окрема AQA-команда пост-фактум, вони структурно приречені відставати: розробник уже зробив фічу й пішов далі, автоматизатор наздоганяє. Лікування — зсунути володіння: unit/інтеграцію до авторів коду, тест у Definition of Done фічі, щоб вона не закривалася без нього.

Симптом 2: червону збірку ніхто не чинить, коли одна людина у відпустці. Це діагноз «немає власника зеленого». Поки за сьюту відповідає абстрактна «команда тестування», а не автор зміни, збірка просто лишається червоною. Whole-team approach прибиває відповідальність до того, хто зламав: червоне чинить він, зараз, або відкочує зміну.

Симптом 3: «цей тест іноді падає, просто перезапусти». Це вже нормалізація відхилень у дії. Кожен retry підкріплює звичку не дивитися на падіння, і в день, коли червоним стане справжній регрес, його перезапустять у забуття тим самим рефлексом. Тут не можна лишати як є: флакі або лікують, або виносять у карантин, щоб він не блокував чужі мержі й не отруював контракт «червоне = проблема».

Порядок дій, який випливає з діагнозу: спершу відновити довіру до гейта (карантин флакі, зелене за замовчуванням), паралельно перенести володіння ближче до авторів коду й закріпити тест у DoD та обовʼязкових PR-чеках. Переписувати тести гуртом — останнє, а не перше: без зміни процесу нова сьюта згниє так само.

Кейс 3. Одна сьюта, дві стадії: розкладка тегами

Розкладка «смоук на PR, усе вночі» тримається не на копіюванні тестів у різні проєкти, а на тегах: критичні швидкі шляхи позначають, і фільтр на прогоні вирішує, що бігти.

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

// смоук — критичний шлях, позначаємо тегом; біжить і на PR, і вночі
test('логін відкриває дашборд @smoke', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('qa@example.com');
  await page.getByLabel('Пароль').fill('secret');
  await page.getByRole('button', { name: 'Увійти' }).click();
  await expect(page.getByRole('heading', { name: 'Дашборд' })).toBeVisible();
});

// довгий крос-браузерний сценарій без тегу — тільки в nightly
test('експорт звіту в PDF на всіх ролях', async ({ page }) => {
  // ...повільний e2e, що не має блокувати мерж
});

Запуск різниться лише фільтром:

# на PR: лише швидкий блокувальний смоук
npx playwright test --grep @smoke

# вночі: увесь набір, повна регресія
npx playwright test

Що дивитися і чому:

• Тег @smoke живе в назві тесту, а стадію задає --grep. Одна й та сама сьюта обслуговує PR і nightly з різними вимогами до швидкості й права блокувати — без дублікатів і без окремих репозиторіїв.
• Смоук-тегом позначають саме критичні швидкі шляхи. Якщо начепити @smoke на повільний e2e, PR-прогін роздується й перестане бути хвилинним гейтом. Дисципліна тегування — частина розкладки, а не дрібниця.
• Локатори прив'язані до ролі й лейбла, а не до крихких селекторів. Смоук на PR має бути надійним, бо він блокувальний: флакі-локатор у ньому одразу підриває довіру до гейта, з якої починається вся ця глава.

Shift-left

• Можу пояснити shift-left через ціну дефекту: чим раніше спійманий баг, тим дешевше, і саме тому перевірки зсувають вліво по таймлайну.
• Розумію, що для автоматизації shift-left означає тест у тому ж PR, що й код фічі (коротка петля фідбеку — розробник дізнається про поломку ще до код-рев'ю), а не окрему задачу через кілька спринтів.
• Не плутаю shift-left із «більше ручного тестування раніше» — це про дешеві автоматичні повторювані перевірки, а не про ранній ручний прогін.
• Розумію, що shift-left ширший за автоматизацію: рев'ю вимог, статичний аналіз і тест-дизайн — теж зсув вліво.
• Можу пояснити self-testing code: збірка сама проганяє свій набір тестів і сама каже, справна вона чи ні.

Володіння тестами (ownership)

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

Definition of Done і PR-чеки

• Можу пояснити, чому тест у Definition of Done — це рядок у DoD, а не усна домовленість: інакше його відкладуть на «потім», тобто ніколи.
• Знаю, що required status checks (PR-чеки) — технічне втілення DoD через branch protection: злити гілку не можна, поки перевірки червоні (лінт, типи, unit, смоук).
• Розумію, що DoD плюс обовʼязковий PR-чек — єдина надійна пара, яка не дає відкласти тест, бо зміна фізично не доїде до main.

Довіра до сьюти й флакі

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

Розкладка прогонів і quality gates

• Розумію компроміс швидкість проти покриття: ширший набір = довший прогін, а довгий прогін на кожен PR зупиняє команду.
• Знаю розкладку по стадіях: смоук + unit блокують PR за хвилини, повна регресія йде nightly (не блокує мерж, дає ранковий звіт), релізний прогін годує рішення про реліз.
• Знаю, що таке quality gate: автоматичний критерій, що блокує просування зміни; повільні й історично флакі e2e часто виносять із PR-чеків у nightly.
• Можу пояснити, чому coverage як жорсткий гейт — палиця з двома кінцями: поріг на цифру народжує тести без асертів.