Звітність: артефакти, тріаж, тренди

Що таке артефакт фейлу і навіщо він потрібен?

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

Які основні типи артефактів збирають при падінні тесту?

Чотири, від найдешевшого до найважчого. Скріншот — знімок сторінки в момент невдалого assert; миттєво відповідає на «що було на екрані»: правильна сторінка, модалка поверх кнопки, порожній список. Відео — запис усього сценарію; показує послідовність кроків, тому рятує, коли причина за кілька дій до самого assert. Трейс (trace) — найпотужніший: часова шкала тесту зі знімком DOM на кожній дії, мережею, консоллю й аргументами викликів, яку постфактум можна «перемотати». Логи — консоль браузера, серверний лог, мережа у форматі HAR; консольна помилка JS чи серверний стектрейс нерідко пояснюють падіння напряму. Скріншот дешевий і часто достатній, трейс і відео дорогі за диском і часом.

Чому не варто збирати трейс і відео на кожному тесті?

Бо важкі артефакти коштують дорого, і на масштабі ця ціна б'є по всій сюїті. Трейс пише знімки DOM і мережу на кожній дії, відео тримає запис усього прогону — на тисячах тестів це роздуває і час виконання, і сумарний розмір артефактів у рази. Тому їх вмикають вибірково: скріншот можна only-on-failure, а трейс — on-first-retry. Логіка ретраю тут елегантна: перший прогін іде легким, без важкого трейсу; якщо тест упав і пішов на повтор — трейс уже пишеться саме для того запуску, який відтворив проблему. Виходить дешево для стабільних тестів і щедро для проблемних — і ви маєте повний доказ рівно там, де він потрібен.

Що таке репортер і які його бувають різновиди?

Репортер (reporter) — компонент ранера, що перетворює сирі результати прогону в читабельний для людини або машини формат. Консольні репортери (list, line, dot) друкують прогрес прямо в термінал — це зручно для локальної роботи й для логів CI. Файлові генерують окремий артефакт-звіт: html дає самодостатню сторінку з деревом тестів і вкладеними скріншотами, відео та трейсами, а junit — XML у стандартному форматі, який розуміє майже будь-яка CI-система чи дашборд. На практиці їх комбінують: людям віддають HTML, машині — XML для парсингу. Тобто в одному конфізі спокійно живуть кілька репортерів одночасно.

Що показує trace viewer такого, чого не дасть скріншот?

Скріншот фіксує один кадр — стан екрана в мить падіння; trace viewer дає всю історію тесту, яку можна прокрутити крок за кроком. Трейс тримає знімок DOM на кожній дії, мережеві запити, консоль і аргументи кожного виклику, тож постфактум видно не лише «що зламалося», а й «на якому саме кроці й чому». Це перетворює безпорадне «тест упав» на конкретне «на цьому кроці кнопка ще була disabled, а тест уже клікнув». Для тріажу це часто вирішальний доказ: трейс показує, що елемент був на місці, але тест не дочекався його активного стану — і категорію видно одразу. Саме тому трейс — центральний інструмент розбору флаку.

Чим Allure відрізняється від вбудованого HTML-звіту?

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

Навіщо зв'язувати автотести з TMS?

Звіт живе недовго — до наступного прогону, — а результати часто треба прив'язати до конкретних тест-кейсів у системі керування тестами (TMS): Testomatio, TestRail, Xray. Це дає три речі: менеджмент бачить живий стан покриття («які задокументовані сценарії зелені прямо зараз»), автотест і ручний кейс стають однією сутністю замість двох паралельних списків, а історія результатів кейса не губиться між ранами. Механіка проста: кожен тест маркують ідентифікатором кейса, а спеціальний репортер після прогону шле статуси через API. Так автоматизація перестає бути «річчю в собі» й вливається в загальну картину покриття, стаючи каналом, яким автотести доповідають свій статус у матрицю трасування.

Червоний тест — це завжди баг застосунку?

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

Як на практиці відрізнити баг тесту від бага продукту?

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

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

Інфраструктурний фейл — це коли не винні ні продукт, ні тест: середовище лежить, база недоступна, мережа відвалилась, впав CI-ранер, скінчилися ресурси або протух токен. Упізнають його за характером помилки — таймаути з'єднання, коди 5xx, DNS-збої, «немає БД» — і за масовістю: якщо одразу після релізу червоніє півсюїти з 502/503/504, це радше стенд у процесі деплою, ніж раптова регресія в багатьох місцях. Дія тут — перезапустити чи полагодити оточення, не чіпаючи ні код продукту, ні тести. Відділяти цю категорію критично: інакше команда або заводить фальшиві баги на розробників, або ховає повторювані інфра-збої під ретраями. А повторюваний інфра-фейл — теж дефект, лише процесу чи стенду, і його треба рахувати, а не замітати.

Інтерв'юер питає: «Тест упав у CI. Твої дії?» Що відповісти?

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

Що таке alert fatigue і чому вона небезпечна для команди?

Втома від алертів (alert fatigue) — це стан, коли канал сповіщень пищить так часто й на такі дрібниці, що команда просто перестає його читати. Найкраще формулювання механізму — з книги Google SRE, від першої особи: «I can only react with a sense of urgency a few times a day before I become fatigued». Термінологічна деталь: сам вислів у тій книзі стоїть лише у виносці, а в тілі розділу вжито alert spam — сповіщення, які «are rarely read or acted on». Виникає вона, коли алертять на кожен ран підряд: на відомий флак, на нічні інфра-збої, на стабільно червоний карантинний тест. Проблема в тому, що серед цього шуму тоне справжня регресія — те єдине падіння, заради якого сповіщення й існують. Тобто надмірні алерти не підвищують пильність, а вимикають її: канал сам вчить себе ігнорувати. Лікується це не гучністю, а відбором: сповіщення має нести сигнал, а не факт, і будити людей лише тоді, коли справді щось нове й важливе зламалося на захищеній гілці.

На що варто алертити, а на що ні?

Правило перше — алертити на зміну стану, а не на факт: важливо не «є червоні тести», а «на захищеній гілці з'явилися нові падіння, яких учора не було». Стабільно червоний карантинний тест не має будити нікого, і тест, що позеленів з другого ретраю, — теж не привід для сповіщення, інакше канал вчиться ігнорувати себе. Друге — маршрутизувати сповіщення до власника: падіння в чекауті йде команді чекауту, а не всім підряд; персональна адресація підвищує шанс, що фейл полагодять, а не залишать «комусь». Третє — агрегувати: одне повідомлення «12 fail, 3 нові, ось звіт» замість дванадцяти окремих, і обов'язково з лінком на HTML/Allure, щоб від сигналу можна було одразу провалитися в деталі. Різні розклади мають різну гучність: PR-фейл бачить лише автор PR, нічний ран шле зведення в канал, реліз-gate — найголосніший.

Чому «звіт як продукт» означає, що один формат на всіх не працює?

Бо той самий прогін дивляться кілька ролей, і кожній потрібне своє. Авторові тесту потрібна точна причина падіння — трейс, скріншот, стек; агреговані відсотки йому марні. Тімліду навпаки — тренд pass rate, флак і час прогону, а деталі кожного фейлу зайві. Реліз-менеджеру взагалі треба одна відповідь: gate зелений чи ні. Продакту важливий стан покриття критичних сценаріїв, а не технічні артефакти. Тому звітність — це кілька зрізів одних і тих самих даних: детальний HTML з артефактами для інженерів, коротка нотифікація для команди, тренд у дашборді для ліда, статус у TMS для менеджменту. Свідомо спроєктований під читача звіт дає рішення за хвилину; «звіт як вийде» змушує кожного шукати своє вручну.

Що таке flaky rate та escape rate і навіщо дивитися на них у часі?

Це метрики, які перетворюють звіт зі знімка на інструмент керування якістю. Flaky rate — частка тестів, що зеленіють лише з ретраю; коли вона росте, сюїта гниє, і зелений фінальний колір це маскує, бо тест міг пройти з третьої спроби. Escape rate — баги, що проскочили тести й знайшлися вже в проді; це найчесніша метрика реальної цінності сюїти, бо показує, скільки дефектів вона насправді ловить. Назва — наша робоча, не галузевий стандарт: у наших джерелах, включно з повними силабусами ISTQB, її немає (там є інша метрика — Defect Detection Percentage), тож на співбесіді описуйте суть, а не сподівайтеся на впізнавання терміна. Дивитися на них у часі важливо, бо один прогін відповідає лише на «зелено чи ні», а тренд — на «нам стає краще чи гірше». Разом із pass rate і часом прогону ці дві метрики показують здоров'я автоматизації: різке падіння pass rate — сигнал регресії, повзучий duration — привід думати про паралелізацію, а зростання flaky rate чи escape rate — що сюїті потрібен ремонт, а не нові тести.

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

Кейс 1. Playwright: артефакти й репортери під бюджет

Мета — щоб кожен фейл лишав доказ причини, але сюїта не тонула в гігабайтах трейсів. Скріншот дешевий, тож його можна на кожне падіння; трейс і відео важкі, тож лише на ретраї. Репортери розводимо за читачем: людям — HTML, машині CI — JUnit XML, у термінал — короткий список.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    screenshot: 'only-on-failure',   // дешево — можна на кожне падіння
    video: 'retain-on-failure',      // важко — тримаємо лише коли впав
    trace: 'on-first-retry',         // найважче — вмикаємо аж на повторі
  },
  reporter: [
    ['list'],                                // прогрес у термінал CI
    ['html', { open: 'never' }],             // для інженерів — дерево + артефакти
    ['junit', { outputFile: 'results.xml' }],// для CI/дашборда — XML
  ],
});

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

• on-first-retry — це компроміс ціни й доказу. Перший прогін іде легким, без трейсу; якщо тест упав і пішов на повтор — трейс пишеться саме для того запуску, що відтворив проблему. Стабільним тестам це нічого не коштує, проблемним дає повний доказ.
• only-on-failure для скріншота, а не on. Знімок на кожному кроці зеленого тесту — це диск на вітер; цінність скріншота саме в мить невдалого assert.
• Кілька репортерів одночасно — норма. html нечитабельний для машини, junit нечитабельний для людини; тому дашборд парсить XML, а інженер відкриває HTML з вкладеним трейсом. Один формат обидві задачі не закриває.
• retries без артефактів на ретраї — напівзахід. Повтори маскують флак, а trace: 'on-first-retry' натомість його документує: видно, чому саме перша спроба впала.

Кейс 2. Тріаж червоного нічного прогону

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

Розбір колонки за колонкою:

• Спершу відсіюємо інфру за масовістю й часом. Дюжина фейлів з однаковою мережевою помилкою, що почалися в одну хвилину, — це майже завжди стенд, а не 12 регресій одночасно. Ретрай часто зеленить половину табло, і на реальний тріаж лишається менше.
• Миготіння — маркер флаку, тобто бага тесту. Якщо без зміни коду тест то падає, то ні, шукати баг у продукті марно; трейс покаже гонку — дію раніше, ніж елемент став готовим.
• «Руками теж ламається» — єдиний квиток у баг-репорт. Поки ручний флоу відтворює проблему, це кандидат на продукт; поки працює — підозра на тест. Артефакт тут арбітр: він відрізняє «кнопки не було» від «тест не дочекався».
• Правило дешевше за помилку. Один фальшивий баг на розробника коштує довіри до всієї сюїти; одна прогавлена регресія під приводом «знову флак» їде в прод. Тому тріаж — рутина після кожного червоного рана, а не героїзм.

Кейс 3. Нотифікація: сигнал замість шуму

Той самий прогін можна доставити двома способами. Перший вчить команду ігнорувати канал, другий — приводить потрібну людину прямо до причини.

ШУМ — по повідомленню на кожен фейл, у загальний канал:
  [FAIL] checkout smoke #1
  [FAIL] checkout smoke #2
  [FAIL] login flaky (retry)
  [FAIL] nightly infra timeout
  ... ще 23 рядки ...

СИГНАЛ — одне зведення, лише про нове, з адресацією і лінком:
  main зламався: 3 НОВІ падіння (24 відомих флак/інфра приховано)
  → checkout: cart empties after redirect  @team-checkout
  Звіт: https://ci.example.com/report/8421   Трейси всередині.

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

• Алерт на зміну стану, а не на факт. Важливо не «є червоні тести», а «на main з'явилися три падіння, яких учора не було». Стабільно червоний карантинний тест і ретрай, що позеленів, у сигнал не потрапляють — інакше канал сам себе привчає до сліпоти.
• Маршрутизація до власника. @team-checkout замість «усім» різко підвищує шанс, що фейл полагодять, а не залишать «комусь». Персональна адресація — це і відповідальність, і швидкість.
• Агрегація плюс лінк. Одне повідомлення замість 27 і посилання на HTML/Allure, щоб від сигналу можна було одразу провалитися в трейс. Мета сповіщення — привести до причини, а не просто налякати числом.
• Гучність за розкладом. PR-фейл достатньо показати автору в самому PR; нічний ран шле зведення в командний канал; блокуючий реліз-gate — найголосніший сигнал. Однакова гучність на все — це і є шум.

Звіт як продукт

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

Артефакти фейлу

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

Репортери й звіти

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

TMS та трасування

• Можу пояснити, навіщо зв'язувати автотести з TMS: живий стан покриття, одна сутність замість двох списків, історія результатів кейса.
• Знаю механіку інтеграції: тест маркують ID кейса, репортер після прогону шле статуси через API.

Тріаж падінь

• Тримаю в голові головне правило: червоний тест не дорівнює багу продукту.
• Знаю три категорії тріажу (баг продукту / баг тесту / інфраструктура) і що в кожної свій власник та своя дія.
• Можу відрізнити баг тесту від бага продукту: стабільність відтворення, ручний флоу, артефакт як арбітр.
• Знаю ознаки інфра-фейлу (таймаути, 5xx, DNS, немає БД, масовість після релізу) і що чинити треба стенд, а не код.

Нотифікації без шуму

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

Тренди

• Можу назвати ключові метрики в часі: pass rate, flaky rate, duration, escape rate — що сигналить кожна і чому escape rate найчесніша.
• Розумію, чому зелений прогін не завжди «все добре»: тести могли позеленіти з ретраю, маскуючи флак — дивись на flaky rate.