Підтримка тестів і аналіз падінь

Що таке тріаж червоного прогону і чому якість AI-діагнозу впирається саме в контекст?

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

Які артефакти падіння варто передавати AI і чому голого повідомлення помилки замало?

Повідомлення помилки — лише верхівка: воно каже тип винятку й рядок, але не показує, що було на екрані й чи взагалі дійшов запит до бекенду. Інформативний набір складають стек-трейс (який виклик упав), локатор, що не зматчився (чого тест не знайшов на сторінці), скриншот моменту падіння (реальний стан екрана), trace або відео (послідовність кроків, мережа, консоль, DOM-снапшоти), HAR мережевих запитів (чи прийшла відповідь, який статус, що в тілі) і серверні логи (виняток на бекенді, correlation id). Найбагатший з них — trace: він єдиний зшиває дію, стан сторінки й мережу в одну картину. У Playwright цей архів збирається автоматично, наприклад опцією trace: 'on-first-retry', яка пише трейс лише для повторного прогону впалого тесту. Що ширший контекст, то менше моделі лишається домислювати.

Чому не варто давати AI власний переказ падіння замість сирих фактів прогону?

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

Червоний тест має три різні причини. Назвіть їх і поясніть, чому їх дорого плутати.

Падіння тесту означає одне з трьох, і кожне лікується інакше. Перше — баг продукту: застосунок справді працює неправильно, і саме заради цього тест існує. Друге — баг тесту: крихкий локатор, забутий await, гонка в самому коді тесту, застарілий крок після зміни UI; продукт при цьому здоровий. Третє — інфраструктура або флак: моргнуло оточення, впав сусідній сервіс, тестові дані перехопив паралельний воркер. Плутати їх дорого, бо реакції протилежні: на баг продукту заводять дефект, баг тесту чинять у своєму коді, а флак стабілізують ізоляцією й ретраями. Найдорожча помилка — завести дефект на здоровий продукт: це спалює довіру команди до всього набору тестів.

Як саме AI помиляється, коли ставить діагноз падінню?

Модель видає найправдоподібніший текст, а не найправильніший, і має три впізнавані патерни хиб. Приякорення до симптому: побачивши Timeout, вона радить збільшити таймаут, хоча час спливає і при реальній відсутності елемента, і коли тест чекає не на те. Звинувачення застосунку за замовчуванням: фраза «схоже, у продукті баг» правдоподібна, тож AI пише її навіть тоді, коли винен тест. Вигаданий root cause: модель конструює зв'язну причинну історію, яка ідеально пояснює лог і водночас не має нічого спільного з реальністю. Спільний корінь усіх трьох — гладкість формулювання не корелює з його правильністю. Тому AI-діагноз завжди трактують як гіпотезу на перевірку, а не як вирок.

AI побачив Timeout і радить збільшити таймаут. Чому це небезпечна порада?

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

Де в аналізі флаку AI приносить найбільше чесної користі?

У пошуку патерну по великому масиву падінь, який людське око не охоплює. Один флакі-фейл інженер розбере й сам, а от закономірність у сотні прогонів — які тести, коли, на яких воркерах, у якому оточенні — руками не побачиш. Тут LLM сильна за своєю природою: вона добре підсумовує й кластеризує накидані дані, тож згодуйте їй історію падінь і попросіть згрупувати за спільними ознаками. На виході — напрямок пошуку: «ці п'ять валяться разом на одному воркері», «ця група червоніє тільки вночі». Це економить години читання логів, але саме напрямок, а не готовий вирок — межу треба тримати чітко.

Тест червоніє лише вночі, лише на воркері N або лише в CI. Про що зазвичай сигналить кожен патерн?

Це класичні кластери, кожен зі своїм типовим коренем. «Лише вночі» майже завжди вказує на таймзону чи межу доби в даних — тест переступає північ або рахує «сьогодні» не в тому поясі. «Лише на воркері N при паралельному запуску» — конфлікт за спільними тест-даними: два потоки правлять один акаунт чи запис. «Зелений локально, червоний лише в CI» — headless-таймінги, повільніше оточення, інший стан кешу. «Серія тестів валиться після одного конкретного» — протікання стану й порушена ізоляція: попередній тест лишив по собі сміття. Важливий нюанс: усе це кластери-підказки, а не діагнози — чому саме воркер 3 чи саме ніч, доводите ви перевіркою.

Чому кажуть, що AI групує симптоми, а не встановлює причину?

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

Чому рефакторинг тестів вважають відносно безпечною задачею для AI?

Бо більшість рефакторингу — механічні трансформації з детермінованим і перевірюваним результатом. Витягнути повторюваний блок у page object, прибрати дублювання, перейменувати, замінити застарілий патерн на сучасний — тут тест або проходить після зміни, або ні, а diff видно очима. Класика — масова заміна хардвейтів на web-first асерти: await page.waitForTimeout(3000) перед перевіркою тексту перетворюється на await expect(locator).toHaveText(...) з авторетраєм. Petля зворотного зв'язку коротка: прогнав набір, подивився diff — і одразу ясно, чи не зламалося. Саме ця перевірюваність робить задачу зручною для моделі, на відміну від питань інтенту, де правильної відповіді в самому коді немає.

Який головний ризик AI-рефакторингу асертів, навіть якщо тест після нього зелений?

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

Що таке self-healing локатори і як вони працюють?

Self-healing локатори (самовідновні локатори) — механізм, коли інструмент, не знайшовши елемент за основним селектором, не падає одразу, а намагається знайти «той самий» елемент за іншими ознаками (текст, ARIA-роль, сусідні вузли, позиція) і продовжити прогін. Ідея — менше червоних білдів і ручної правки локаторів після кожної зміни верстки. Це фіча низки комерційних платформ (Testim, Mabl, testRigor) та опенсорсних надбудов на кшталт Healenium для Selenium. У Playwright такого «з коробки» немає: там ставку зроблено на стабільні локатори за замовчуванням, а не на автовідновлення крихких. Рішення про «схожість» тут завжди евристичне, тобто імовірнісне.

Який концептуальний конфлікт між self-healing і самою метою тесту?

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

Назвіть конкретні ризики self-healing локаторів.

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

Як тоді можна вбудувати self-healing, щоб він не шкодив?

Прийнятна форма — підказка людині, а не тихе автопродовження зеленим. Тобто інструмент має право сказати «локатор ось-ось зламається, ось кандидат на заміну — підтвердь», але не має права мовчки перемкнутися на інший елемент і зарахувати білд як успішний. У першому випадку рішення лишається за інженером, який звірить кандидата з реальністю; у другому механізм сам виносить вирок, до якого не має компетенції. Фундамент при цьому той самий, що й без AI, — стабільні локатори (data-testid, ARIA-ролі) як контракт із розробкою. Self-healing у здоровій конфігурації доповнює цей контракт сигналом про дрейф, а не заміняє його евристикою.

Як AI прискорює оновлення тестів після зміни UI чи API і за якої умови?

Коли фіча свідомо змінилася, десятки тестів червоніють законно, і привести їх у відповідність — механічна рутина, з якою модель справляється швидко. Умова одна: давати їй diff зміни, а не змушувати вгадувати. Модель не бачила ні старого, ні нового застосунку, тож здогад «як тепер виглядає форма» — чиста вигадка. А от diff PR-у, зміна в OpenAPI-специфікації чи розмітка «до/після» — це факти, з якими вона працює предметно. На зміні API згодуйте новий приклад відповіді або diff схеми — і AI оновить асерти на статуси, тіло, назви полів (тут доречні контрактні перевірки схемою, а не звірка полів очима). На зміні UI новий data-testid чи переміщений елемент з diff-ом розмітки оновлюються так само швидко.

Яка головна пастка при оновленні впалого тесту руками AI?

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

Що AI-рев'ю в пул-реквесті ловить добре, а що — принципово ні?

Добре ловить механічні дефекти й запахи, які око проскакує на великому diff: забутий await перед web-first асертом, тавтологічні перевірки на кшталт expect(true).toBeTruthy(), хардвейти замість авторетраю, крихкі локатори за згенерованими класами, відсутність очевидних негативних сценаріїв. Це швидкий перший фільтр, що знімає рутину з людини-рев'юера. Чого AI не бачить: чи перевіряє тест правильний інваріант, чи відповідає очікуваний результат реальній вимозі, чи має зміна доменний сенс. Модель читає форму коду, а не його намір. Тому AI-рев'ю працює як фільтр, а не як gate, і фінальне слово на PR лишається за інженером.

Чому «зелене AI-рев'ю» небезпечно трактувати як гарантію якості?

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

Сформулюйте загальне правило роботи з будь-яким AI-діагнозом у супроводі тестів.

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

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

Кейс 1. Один фейл, два промпти: чому контекст вирішує все

Уранці впав тест оформлення замовлення. Помилка сама по собі скупа:

TimeoutError: locator.click: Timeout 30000ms exceeded.
Call log:
  - waiting for getByRole('button', { name: 'Оплатити' })

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

Хороший промпт — додати артефакти прогону з trace. Тоді в контексті з'являються мережа й DOM-снапшот моменту падіння:

Network (з trace):
  POST /api/cart/checkout   →  200 OK
  GET  /api/user/profile    →  401 Unauthorized

DOM-снапшот на момент падіння:
  <div class="session-expired-modal">Сесія завершилася. Увійдіть знову.</div>

Тепер картина інша: кнопки «Оплатити» немає не тому, що вона повільна, а тому що поверх сторінки — модалка простроченої сесії через 401. Збільшення таймауту тут не допомогло б ніколи. AI з таким контекстом дасть предметну гіпотезу («токен протух до кроку оплати»), яку легко перевірити.

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

• Голе повідомлення помилки несе тип і рядок, але не стан екрана. Timeout на кліку однаково виглядає і коли елемент повільний, і коли його перекрила модалка, і коли його взагалі немає через баг. Розрізняє ці випадки саме DOM-снапшот і мережа з trace.
• 401 у мережі — це напрямок, а не вирок. Він каже, куди копати (автентифікація перед оплатою), але чому саме протух токен — короткий TTL, гонка з рефрешем, кривий сетап тесту — з'ясовуєте ви. AI звузив пошук з усієї сторінки до одного запиту; діагноз усе одно за вами.
• Переказ отруює діагноз. Якби в промпті було «кнопка оплати не завантажується, здається, баг рендеру», модель приякорилась би до рендеру й могла б не помітити 401. Сирий trace такого упередження не має.

Кейс 2. «AI сказав, що це баг застосунку» — класифікація по кроках

Частий ранковий діалог: інженер кинув боту лог 500, той відповів «схоже на баг бекенда», і виникає спокуса завести дефект і закрити тікет. Але 5xx міг тригернути будь-хто, тож спершу — класифікація. Таблиця рішень для трьох причин червоного:

Найдешевша перевірка — відтворити той самий запит руками, а не вірити на слово:

# той самий виклик, що впав у тесті — валідним запитом
curl -i -X POST https://staging.example.com/api/orders \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"productId": 42, "qty": 1}'

• Відтворюється валідним запитом → кандидат на баг бекенда, і стектрейс у логах це підтвердить.
• Не відтворюється, а тест усе одно падає → підозра зміщується на тест: не підставилась змінна, протух токен, крива фікстура, не те середовище.

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

• AI звинувачує застосунок за замовчуванням. «Схоже на баг продукту» — правдоподібна фраза, яку модель пише й тоді, коли винен крихкий тест. Це найдорожча помилка тріажу: дефект на здоровий продукт палить довіру команди.
• Гіпотеза коштує один curl. Заявляти причину без перевірки — антипатерн; «стектрейс указує на конкретний контролер» варте рівно стільки, скільки під ним доказів.
• 500 на завідомо кривому вводі — окремий дефект бекенда. Навіть якщо тригер прийшов від тесту, добре спроєктований сервер мав відповісти 400/422, а не впасти. Тобто винних тут може бути двоє одночасно.

Кейс 3. Self-healing проти стабільного локатора: як регресія стає зеленою

Розробники перейменували кнопку кошика й заразом випадково прибрали в неї обробник кліку — покупку зламано. Дивимось, як на це реагують два підходи.

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

// Стабільний локатор: контракт із розробкою через data-testid
test('кнопка "Купити" додає товар у кошик', async ({ page }) => {
  await page.goto('https://shop.example.com/product/42');
  await page.getByTestId('add-to-cart').click();
  await expect(page.getByTestId('cart-badge')).toHaveText('1');
});

Якщо data-testid на місці, але обробник зник — тест чесно червоніє на асерті cart-badge: лічильник кошика лишився 0. Це і є сенс тесту — впасти на несподівану зміну поведінки. Регресію спіймано до продакшену.

Тепер уявімо той самий сценарій під платформою із self-healing, де локатор прив'язаний до тексту кнопки:

Крок: click button "Додати в кошик"
  ⚠ основний селектор не знайдено (кнопку перейменували на "Купити")
  ✓ self-healing: знайдено схожий елемент за роллю/позицією → "Купити"
  ✓ клік виконано, крок пройдено
Результат білда: PASSED

Локатор «загоївся», клік формально відбувся — але обробник зламано, товар у кошик не потрапив, а білд зелений. Самовідновлення прибрало рівно той сигнал, заради якого тест існував.

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

• Self-healing протидіє меті тесту. Перейменування кнопки могло бути свідомим рішенням продукту, а могло бути регресією; механізм робить білд зеленим в обох випадках, і другий — це пропущений баг під виглядом успіху.
• Загоєння буває на неправильний елемент. Якби поруч була ще одна кнопка, евристика могла вибрати не ту — тест лишався б зеленим, перевіряючи не те. Рішення про «схожість» імовірнісне, тож ще й недетерміноване між прогонами.
• Здорова конфігурація — підказка, не автопродовження. Прийнятний варіант: «локатор ось-ось зламається, кандидат на заміну — "Купити", підтвердь». Тоді інженер звірить зміну з вимогою, а не бот винесе вирок, до якого не має компетенції.
• Фундамент той самий, що й без AI. Стабільні локатори (data-testid, ARIA-ролі) як контракт із розробкою надійніші за будь-яку евристику схожості; self-healing у кращому разі доповнює їх сигналом про дрейф, а не заміняє.

Тріаж і контекст для AI

• Розумію, що AI не бачить мого CI, екрана й бекенду — його діагноз рівно такий, як факти, вставлені в промпт.
• Знаю набір інформативних артефактів падіння: стек-трейс, локатор, що не зматчився, скриншот, trace/відео, HAR, серверні логи.
• Можу пояснити, чому trace — найбагатший артефакт: він зшиває дію, стан DOM і мережу в одну картину.

Фейл ≠ баг

• Тримаю три причини червоного тесту: баг продукту, баг тесту, інфраструктура/флак — і знаю, що реакція на кожну різна.
• Розумію, чому завести дефект на здоровий продукт — найдорожча помилка: вона палить довіру команди до тестів.
• Знаю три патерни хиб AI: приякорення до симптому, звинувачення застосунку за замовчуванням, вигаданий root cause.
• Тримаю правило: AI дає гіпотезу, класифікацію підтверджую я — повторним прогоном, ручним відтворенням, curl до бекенду.

Флакі та патерни

• Розумію, де AI сильний у флаку: кластеризація патерну по сотні прогонів, який око не охоплює.
• Знаю типові кластери: «лише вночі» → таймзона, «воркер N» → спільні дані, «лише в CI» → headless-таймінги, «після одного тесту» → протікання стану.
• Можу пояснити межу: AI групує симптоми, а причину за кластером доводжу я.

Рефакторинг і оновлення тестів

• Розумію, чому механічний рефакторинг відносно безпечний для AI: результат детермінований і перевірюваний diff-ом та прогоном.
• Пам'ятаю ризик: AI може непомітно послабити асерцію — тому перевіряю, що тест досі червоніє на зламаній фічі.
• Можу пояснити умову оновлення тестів: давати AI diff зміни (PR, OpenAPI, DOM «до/після»), а не змушувати вгадувати.
• Тримаю пастку: AI підганяє впалий тест під новий стан навіть якщо той стан — регресія; рішення про інтент за людиною.

Self-healing локатори

• Формулюю конфлікт: мета тесту — впасти на несподівану зміну, а self-healing тихо це загоює.
• Знаю чотири ризики: маскування регресій, загоєння на не той елемент, недетермінізм, тихий дрейф локаторів.
• Тримаю здорову позицію: self-healing прийнятний як підказка людині, не як тихе автопродовження зеленим.

AI-рев'ю в PR

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