Метрики тестування і звітність

Зміст

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

На співбесідах тема спливає у двох формах: пряме «які метрики тестування ви використовували і навіщо» і підступніше «як зрозуміти, що тестування можна завершувати». Друге — теж про метрики: про критерії виходу з тест-плану і про те, чим виміряти їх досягнення. У силабусі ISTQB CTFL 4.0 цій темі присвячено розділ 5.3 «Test Monitoring, Test Control and Test Completion».

Навіщо метрики — і коли метрика стає ціллю

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

Де ми відносно плану? Виконано 180 з 240 запланованих кейсів, темп — 30 на день: закінчимо за два дні, у графік влазимо.
Яка якість продукту зараз? 4 відкриті критичні дефекти, усі в модулі оплати; крива нових багів другий день не спадає.
Чи можна завершувати? Критерії виходу кажуть «100% критичних кейсів пройдено, немає відкритих blocker/critical» — звіряємо факт із порогом і отримуємо відповідь «так/ні», а не «начебто можна».

Тобто метрика — інструмент рішення. Якщо число нікому не допомагає нічого вирішити, його збір — ритуал, а не робота.

І тут головна пастка теми, яку люблять перевіряти на співбесідах. Закон Ґудгарта (Goodhart's law), у популярному формулюванні: коли міра стає ціллю, вона перестає бути хорошою мірою. Щойно з метрики роблять KPI, люди починають оптимізувати число, а не те, що воно мало вимірювати:

KPI «кількість заведених багів» → потік тривіальних дублікатів і косметики, бо десять дрібниць «дорожчі» за один складний баг у логіці.
KPI «кількість тест-кейсів на день» → кейси дробляться на атомарні кроки заради лічильника.
Ціль «pass rate не нижче 98%» → нестабільні тести не лікують, а видаляють або скипають — звіт зеленіє, продукт ні.

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

Покриття вимог: репортинговий кут

Покриття вимог (requirements coverage) — відсоток вимог, для яких існують тести. Методика, яка за цим стоїть — матриця трасування (requirements traceability matrix, RTM), пошук непокритих вимог і тестів-сиріт, — детально розібрана в розділі «Тест-дизайн» у главі про покриття вимог і трасування. Тут нас цікавить кут звітності: які цифри з трасування виносити в звіт і як їх не перебрехати.

У звіті покриття — це не одне число, а три різні:

Покрито тестами — для скількох вимог узагалі є перевірки. 36 з 40 вимог → 90%. Решта 4 — або свідомо поза скоупом, або дірка в дизайні.
Виконано — скільки покритих вимог уже перевірено в цьому циклі.
Пройшло — скільки перевірених вимог справді працює.

Плутати їх — класична маніпуляція (іноді ненавмисна): «покриття 90%» звучить заспокійливо, навіть якщо виконано половину, а пройшла третина. Сильний звіт показує всі три зрізи: «покрито 90%, виконано 75%, пройшло 68%, у 3 вимогах відкриті критичні дефекти».

І пастка глибини: покриття рахує наявність тесту, а не його достатність. Одна вимога — один happy-path кейс — і на папері 100%, хоча негативні сценарії й межі ніхто не чіпав. Стовідсоткове покриття вимог не означає якісний продукт ще й тому, що самі вимоги можуть бути неповними — це absence-of-defects fallacy із семи принципів тестування.

Метрики дефектів

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

Метрика	Як рахується	Про що сигналить
Щільність дефектів (defect density)	Кількість дефектів на одиницю розміру: модуль, фічу, тисячу рядків коду	Де в продукті скупчення ризику
Escape rate / DDP	DDP — частка дефектів, знайдених до релізу, від усіх відомих; escape rate — дзеркальна частка тих, що втекли в продакшн	Наскільки ефективно тестування ловить баги
Час життя дефекту (defect age)	Час від виявлення до закриття, з розбивкою за статусами	Де вузьке місце процесу роботи з багами

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

Escape rate — частка дефектів, які «втекли» в продакшн повз тестування. Дзеркальна метрика — відсоток виявлення дефектів (defect detection percentage, DDP): скільки з усіх відомих багів команда знайшла до релізу. Знайшли 90 до релізу, користувачі принесли ще 10 після → DDP 90%, escape rate 10%. Це чи не найчесніша метрика якості самого тестування, але з обмеженням: рахується постфактум, коли пізно щось міняти в цьому релізі. Її цінність — у тренді між релізами: DDP падає → тестування деградує або продукт ускладнюється швидше, ніж росте покриття.

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

Pass rate, fail rate і динаміка

Pass rate — частка пройдених тестів серед виконаних. Найпопулярніша метрика і найлегша для неправильного читання.

Перше: стежте за знаменником. Тести бувають не лише passed і failed — ще blocked і skipped (статуси виконання розібрані в главі про тестові середовища й виконання). «95% pass» від виконаних і «95% pass» від усіх запланованих — дуже різні звіти: у другому випадку 30 заблокованих кейсів просто випали з картинки разом із функціональністю, яку вони мали перевірити.

Друге: pass rate — число без ваги. 95% зелених нічого не каже, поки не відомо, що саме в червоних 5%: п'ять екзотичних крайових кейсів — одна ситуація, п'ять кроків чекауту — зовсім інша. Тому поруч із відсотком у звіті завжди має бути розшифровка фейлів за пріоритетом.

Третє: у автопрогонах pass rate спотворюють флакі-тести — ті, що падають і проходять без змін у коді (детальний розбір — у розділі «Автоматизація»). Прогін, який «полагодився» після ретраю, у наївній статистиці виглядає як passed, і реальна стабільність сьюти залишається невидимою. Тому Playwright у JSON-звіті чесно рахує flaky окремою категорією:

import { readFileSync } from 'node:fs';

// stats із JSON-репортера Playwright: expected / unexpected / flaky / skipped
const { stats } = JSON.parse(readFileSync('results.json', 'utf-8'));

const executed = stats.expected + stats.unexpected + stats.flaky;
const passRate = ((stats.expected / executed) * 100).toFixed(1);

console.log(`Pass rate: ${passRate}%, flaky: ${stats.flaky}, skipped: ${stats.skipped}`);

Якщо звіт показує лише «зелений/червоний» без flaky — метрика вже трохи бреше.

Четверте й головне: сила pass rate — у динаміці. Один знімок «зараз 87%» майже безглуздий; крива за два тижні — ні. Класична картина здорової стабілізації перед релізом: крива виконаних тестів росте, крива нових дефектів спадає, крива закритих наздоганяє криву заведених. Якщо за три дні до релізу нові баги прибувають швидше, ніж закриваються старі, — реліз у зоні ризику, хоч би яким був поточний відсоток зелених.

Test summary report

Підсумковий звіт про тестування (test summary report, у термінах ISTQB — test completion report) — документ, який закриває цикл тестування: реліз, спринт, етап. Його антипод — звіт-дамп: простиня чисел, з якої читач не може ухвалити жодного рішення. Хороший звіт будується від зворотного — від рішення, яке ухвалює читач: «релізимо чи ні, і що ризикуємо, якщо так».

Робочий скелет (шаблони описані в стандарті ISO/IEC/IEEE 29119-3, але на практиці це зазвичай сторінка у вікі):

Скоуп: що тестували і — обов'язково — що не тестували й чому. Пропущений скоуп, який спливе після релізу, б'є по довірі сильніше за будь-який баг.
Звірка з критеріями виходу з тест-плану: досягнуто / не досягнуто, по пунктах.
Ключові метрики: покриття вимог (три зрізи), pass rate із розшифровкою фейлів, динаміка дефектів.
Відкриті дефекти й залишкові ризики: що відомо-зламане їде в реліз, з якою ймовірністю й ціною. Це місток до ризик-орієнтованого тестування — мова, якою розмовляють із менеджментом.
Відхилення від плану: що пішло не так і чого це навчило (стенд лежав два дні, вимоги приїхали пізно).
Висновок: рекомендація QA — go / no-go / go з умовами.

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

Моніторинг і контроль

Метрики та звіти — не самоціль, а сенсори в контурі керування. ISTQB розводить два поняття: моніторинг тестування (test monitoring) — безперервний збір і порівняння фактичного прогресу з планом, і контроль тестування (test control) — коригувальні дії, коли факт розійшовся з планом. Моніторинг без контролю — це спідометр в авто без керма.

Типові контрольні дії, які варто вміти назвати на співбесіді:

Перепріоритезувати тести за ризиком: часу мало — ріжемо хвіст, а не критичний шлях.
Перекинути ресурси: щільність дефектів показала гарячий модуль — туди йде додаткова пара очей.
Ескалювати: стенд лежить третій день — це вже не проблема QA, а ризик релізу, і вирішується він не в тестовій команді.
Переглянути скоуп або дату: чесне «не встигаємо перевірити X до п'ятниці» з варіантами — а не мовчазне невстигання.
Змінити критерії входу/виходу — свідомо і письмово, а не «ну, 95% теж норм». Самі критерії — частина STLC і фіксуються ще на плануванні.

Цикл замикається: план задає пороги → виконання генерує дані → моніторинг порівнює → контроль коригує → підсумковий звіт фіксує результат і годує планування наступного циклу.

Типові помилки

Виглядає як якість — «у нас 100% pass rate», а насправді це може бути сьюта зі слабкими перевірками, вирізаними червоними тестами й скипнутими нестабільними. Pass rate вимірює відповідність тестам, а не якість продукту.
Виглядає як продуктивність — «Оля завела 40 багів, а Іван 12», а насправді порівняння людей за кількістю багів вимірює, хто тестував сирий модуль, і за законом Ґудгарта швидко перетворює баг-трекер на смітник дублікатів.
Виглядає як «усе перевірено» — «покриття вимог 100%», а насправді це «на кожну вимогу існує хоча б один тест»: глибина покриття, негативні сценарії і якість самих вимог за дужками.
Виглядає як інформативний звіт — таблиця з 15 метрик, а насправді читач не може ухвалити з неї жодного рішення. Звіт без висновку й рекомендації — це дамп, а не звітність.
Виглядає як стабільність — знімок «сьогодні 92%», а насправді без тренду це число німе: 92% на шляху вгору і 92% після триденного падіння з 99% — протилежні сигнали.

Підсумок

Метрика — інструмент рішення: якщо число не допомагає нікому нічого вирішити, його не варто збирати.
Закон Ґудгарта: метрика, що стала ціллю чи KPI людини, перестає вимірювати те, для чого створювалась. Метрики — про продукт і процес, не про людей.
Кожна метрика бреше наодинці: покриття — без глибини, pass rate — без ваги фейлів і знаменника, щільність — без інтенсивності тестування. Читати їх треба набором і в динаміці.
Test summary report будується від рішення читача (go/no-go), а не від наявних цифр: скоуп, звірка з критеріями виходу, залишкові ризики, рекомендація.
Моніторинг збирає дані, контроль діє: без коригувальних дій метрики — декорація.

Що питають на співбесіді

«Які метрики тестування ви використовували?» — інтерв'юер чекає не перелік назв, а зв'язку «метрика → рішення»: покриття вимог, щоб знайти дірки в тест-дизайні; динаміка дефектів, щоб оцінити готовність релізу. Перелік без «навіщо» — слабка відповідь.
«Як зрозуміти, що тестування можна закінчувати?» — перевіряють, чи знаєте ви про критерії виходу і чим їх вимірюють; бонус — чесне «тестування не закінчується, а зупиняється» з відсилкою до вичерпного тестування, яке неможливе.
«100% тестів пройшло — продукт якісний?» — класична перевірка критичного мислення: сильний кандидат розкладе, чому pass rate не дорівнює якості (слабкі тести, непокриті вимоги, absence-of-defects fallacy).
«Чи можна оцінювати тестувальників за кількістю заведених багів?» — питання на закон Ґудгарта; очікують «ні» з поясненням, як саме метрика зіпсує поведінку.
«Що напишете у звіті, якщо реліз завтра, а критичний баг не пофікшено?» — дивляться на зрілість: факти, ризик мовою бізнесу, варіанти й рекомендація — замість паніки або мовчазного «зелений звіт».
«Чим test progress report відрізняється від test summary report?» — периферійне, але просте: регулярний пульс для команди проти підсумкового документа для рішення про реліз.

Джерела

ISTQB CTFL 4.0 Syllabus — розділ 5.3 «Test Monitoring, Test Control and Test Completion»: метрики, звіти про прогрес і завершення.
ISTQB Glossary — канонічні означення: metric, defect density, defect detection percentage (DDP), test progress report, test completion report.
ISO/IEC/IEEE 29119-3:2021 — Software testing — Part 3: Test documentation: шаблони тестової документації, включно зі звітами про прогрес і завершення.
Playwright: Reporters — офіційна документація репортерів, зокрема JSON-звіт зі статистикою expected/unexpected/flaky/skipped.

Навіщо тестуванню метрики, якщо можна просто розповідати про стан на дейлі?

Тестування зовні непрозоре: розробка показує фічі, які можна поклацати, а результат тестування — «нічого не вибухнуло», тож без вимірювань менеджер бачить лише те, що QA чимось зайнятий. Метрика (metric) — числова характеристика продукту чи процесу, і потрібна вона, щоб відповідати на три питання: де ми відносно плану, яка якість продукту зараз і чи можна завершувати тестування. Ключова думка, яку чекає інтерв'юер: метрика — інструмент рішення. «Виконано 180 з 240 кейсів, темп 30 на день» — це відповідь на питання «встигаємо чи ні», а не число заради числа. Якщо зібране число нікому не допомагає нічого вирішити, його збір — ритуал, а не робота.

Які метрики тестування ви використовували і навіщо?

Слабка відповідь — перелік назв; сильна — зв'язка «метрика → рішення». Покриття вимог показує дірки в тест-дизайні: для яких вимог узагалі немає перевірок. Щільність дефектів — карту ризику: у який модуль спрямувати регресію і глибший тест-дизайн. Pass rate у динаміці разом із кривими заведених і закритих дефектів — готовність релізу. DDP (defect detection percentage) між релізами — якість самого тестування: чи не деградує воно. Час життя дефекту з розбивкою за статусами — вузьке місце процесу: у розробці, тріажі чи верифікації. Кожну метрику варто називати разом із рішенням, яке вона обслуговує, — інакше це той самий «перелік без навіщо».

Як зрозуміти, що тестування можна завершувати?

Через критерії виходу (exit criteria), зафіксовані ще в тест-плані: наприклад, «100% критичних кейсів пройдено, немає відкритих blocker/critical». Механізм простий — звіряємо факт із порогом і отримуємо відповідь «так/ні» замість «начебто можна». Саме метрики дають чим виміряти це досягнення: покриття, pass rate, кількість і статуси відкритих дефектів. Бонус, який відрізняє сильного кандидата: чесне «тестування не закінчується, а зупиняється» — вичерпне тестування неможливе, тому питання не «чи все перевірили», а «чи досягли узгодженого порогу впевненості». І якщо критерії доводиться пом'якшити, це роблять свідомо й письмово, а не «ну, 95% теж норм».

Що таке покриття вимог і чому «покриття 90%» саме по собі мало що каже?

Покриття вимог (requirements coverage) — відсоток вимог, для яких існують тести; за ним стоїть матриця трасування (requirements traceability matrix, RTM). Пастка в тому, що у звіті це не одне число, а три різні: «покрито тестами» (для скількох вимог є перевірки), «виконано» (скільки покритих уже перевірено в цьому циклі) і «пройшло» (скільки перевірених справді працює). «Покриття 90%» звучить заспокійливо, навіть якщо виконано половину, а пройшла третина, — плутати зрізи означає, іноді ненавмисне, маніпулювати. Сильний звіт показує всі три: «покрито 90%, виконано 75%, пройшло 68%, у 3 вимогах відкриті критичні дефекти».

Покриття вимог 100% — продукт перевірено повністю?

Ні. Покриття рахує наявність тесту, а не його достатність: одна вимога — один happy-path кейс — і на папері 100%, хоча негативні сценарії й межі ніхто не чіпав. Друга причина — самі вимоги можуть бути неповними: тести чесно покривають усе написане, але не те, чого в документі немає. Це absence-of-defects fallacy із семи принципів тестування: відповідність вимогам не тотожна якісному продукту. Практичний наслідок: цифру покриття у звіті варто супроводжувати оцінкою глибини — чи є негативні сценарії й межові перевірки для критичних вимог.

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

Щільність дефектів (defect density) — кількість дефектів на одиницю розміру: модуль, фічу, тисячу рядків коду. Це карта мінного поля: якщо за квартал модуль оплати зібрав 25 дефектів, а профіль користувача — 3, це прямий аргумент, куди спрямувати регресію й глибший тест-дизайн. За метрикою стоїть принцип скупчення дефектів: баги розподілені нерівномірно, і щільність показує, де саме густо. Пастка, яку варто назвати самому: щільність рахує знайдені дефекти, тож модуль може виглядати чистим просто тому, що його погано тестували. Тому читати її треба разом з інтенсивністю тестування, а не окремо.

Що таке escape rate і DDP, і в чому обмеження цих метрик?

Це дзеркальна пара про ефективність самого тестування. DDP (defect detection percentage) — частка дефектів, знайдених до релізу, від усіх відомих; escape rate — частка тих, що «втекли» в продакшн повз тестування. Знайшли 90 багів до релізу, користувачі принесли ще 10 після — DDP 90%, escape rate 10%. Це чи не найчесніша метрика якості тестування, але з принциповим обмеженням: рахується постфактум, коли в цьому релізі вже пізно щось міняти. Тому її цінність — у тренді між релізами: DDP падає — тестування деградує або продукт ускладнюється швидше, ніж росте покриття.

Що показує час життя дефекту і чому середнє число тут мало каже?

Час життя дефекту (defect age) — час від виявлення до закриття, і цікавий він не середнім, а розбивкою за фазами життєвого циклу: скільки баг висить до тріажу, скільки в роботі, скільки чекає верифікації. Середнє «5 днів» не каже нічого; розбивка «фікс — день, верифікація — тиждень» каже точно: вузьке місце не в розробці, а в QA. Жодна інша метрика цього не покаже — ані pass rate, ані щільність. Практичний наслідок: це метрика процесу, з якої випливають конкретні контрольні дії — перекинути людей на верифікацію або переглянути процес тріажу.

«У нас 95% pass rate» — які уточнювальні питання ви поставите?

Перше — про знаменник: 95% від виконаних чи від усіх запланованих? Тести бувають не лише passed і failed, а ще blocked і skipped, і 30 заблокованих кейсів у другому варіанті просто випали з картинки разом із функціональністю, яку мали перевірити. Друге — про вагу червоних 5%: п'ять екзотичних крайових кейсів — одна ситуація, п'ять кроків чекауту — зовсім інша, тому потрібна розшифровка фейлів за пріоритетом. Третє — про флакі: скільки «зелених» полагодилося ретраєм. Четверте — про динаміку: 95% на шляху вгору і 95% після падіння з 99% — протилежні сигнали. Pass rate без цих чотирьох відповідей — число, з якого не можна ухвалити рішення.

Чому флакі-тести спотворюють pass rate і як це чесно показувати у звіті?

Флакі-тест падає і проходить без змін у коді, а прогін, який «полагодився» після ретраю, у наївній статистиці виглядає як passed — реальна стабільність сьюти стає невидимою. Механізм спотворення простий: ретраї маскують нестабільність під успіх, і звіт зеленіє, хоча довіра до сьюти має падати. Тому Playwright у JSON-звіті рахує flaky окремою категорією поруч з expected, unexpected і skipped — і чесний звіт робить так само: pass rate рахується від виконаних, а flaky показується окремим числом. Якщо звіт показує лише «зелений/червоний» без flaky — метрика вже трохи бреше.

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

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

Чи можна оцінювати тестувальників за кількістю заведених багів?

Ні, і це питання на закон Ґудгарта (Goodhart's law): коли міра стає ціллю, вона перестає бути хорошою мірою. Щойно з кількості багів роблять KPI, люди оптимізують число, а не якість: баг-трекер наповнюється тривіальними дублікатами й косметикою, бо десять дрібниць «дорожчі» за один складний баг у логіці. До того ж порівняння «Оля завела 40, Іван 12» насправді вимірює, хто тестував сирий модуль, а не хто краще працює. Звідси правило гігієни: метрики оцінюють продукт і процес, а не людей. Той самий ефект дають KPI «кейсів на день» (кейси дробляться заради лічильника) і ціль «pass rate не нижче 98%» (нестабільні тести не лікують, а видаляють чи скипають).

З чого складається test summary report і що відрізняє корисний звіт від дампа?

Підсумковий звіт (test summary report, в ISTQB — test completion report) закриває цикл тестування і будується від рішення, яке ухвалює читач: релізимо чи ні, і що ризикуємо. Робочий скелет: скоуп — що тестували і обов'язково що не тестували й чому; звірка з критеріями виходу по пунктах; ключові метрики — покриття у трьох зрізах, pass rate із розшифровкою фейлів, динаміка дефектів; відкриті дефекти й залишкові ризики — що відомо-зламане їде в реліз, з якою ймовірністю й ціною; відхилення від плану; і висновок — рекомендація go / no-go / go з умовами. Антипод — звіт-дамп: простиня з 15 метрик, з якої читач не може ухвалити жодного рішення. Окрема пастка — пропущений у звіті скоуп, який спливе після релізу: по довірі це б'є сильніше за будь-який баг.

Чим test progress report відрізняється від test summary report?

Звіт про прогрес (test progress report) — регулярний і короткий пульс для команди: що зробили, що заплановано, що блокує. Test summary report — підсумковий документ у кінці циклу (реліз, спринт, етап), на основі якого ухвалюють рішення про реліз. Різниця не лише в частоті, а й у читачах і деталізації: команді потрібні номери багів і стенди, стейкхолдеру — ризики й дата. Типова помилка — надіслати менеджменту той самий текст, що й команді: звіт, який читачу треба перекладати, не працює.

Реліз завтра, а критичний баг не пофікшено. Що напишете у звіті?

Тут перевіряють зрілість: очікують факти й ризик мовою бізнесу замість паніки або мовчазного «зеленого звіту». Структура відповіді: що саме зламано і як відтворюється; кого й як часто це зачіпає — ймовірність і ціна, тобто мова ризик-орієнтованого тестування, якою розмовляють із менеджментом; які є варіанти — перенести реліз, релізити з відомим багом і хотфіксом, вимкнути функціональність; і рекомендація QA з чітким статусом go / no-go / go з умовами. Рішення про реліз ухвалює не QA, але QA зобов'язаний дати для нього чесні дані. Замовчати баг або тихо позеленити звіт — найгірший із варіантів, бо руйнує сенс звітності як такої.

Чим test monitoring відрізняється від test control?

ISTQB розводить ці поняття в розділі 5.3: моніторинг тестування (test monitoring) — безперервний збір метрик і порівняння фактичного прогресу з планом; контроль тестування (test control) — коригувальні дії, коли факт розійшовся з планом. Моніторинг без контролю — спідометр в авто без керма: дані є, впливу немає. Типові контрольні дії, які варто вміти назвати: перепріоритезувати тести за ризиком (часу мало — ріжемо хвіст, а не критичний шлях); перекинути ресурси в гарячий модуль, який показала щільність дефектів; ескалювати — стенд лежить третій день, це вже ризик релізу, а не проблема QA; чесно переглянути скоуп або дату з варіантами; змінити критерії входу/виходу — свідомо і письмово. Цикл замикається: план задає пороги, моніторинг порівнює, контроль коригує, підсумковий звіт фіксує результат і годує наступне планування.

Три кейси про те, як одні й ті самі цифри дають протилежні рішення: розбір «покриття 90%» на три чесні зрізи, препарування pass rate перед go/no-go (зі скриптом поверх JSON-звіту Playwright) і test summary report на сторінку для релізу з відомим критичним багом.

Кейс 1. «Покриття 90%» на релізному мітингу: одна цифра, три різні звіти

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

Зріз	Число	Що насправді означає
Покрито тестами	36 з 40 (90%)	Для 36 вимог існує хоча б один тест; 4 — або свідомо поза скоупом, або дірка в тест-дизайні
Виконано	30 з 40 (75%)	6 покритих вимог у цьому циклі ще ніхто не перевіряв
Пройшло	27 з 40 (68%)	З перевірених 3 вимоги мають відкриті дефекти

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

«90%» на слайді — це перший рядок, а рішення про реліз живе в третьому. «Покрито» каже лише, що тести написані. Релізити можна те, що перевірено й працює, — а це 68%, і різниця між 90 і 68 — не деталь, а третина картини.
Чотири непокриті вимоги — два різні сценарії. «Свідомо поза скоупом, зафіксовано у тест-плані» — нормально. «Ніхто не помітив» — дірка в тест-дизайні, яку звіт якраз і мав зловити.
Навіть 100% у першому рядку нічого не гарантує. Покриття рахує наявність тесту, а не достатність: одна вимога — один happy-path кейс — і на папері все покрито, хоча негативні сценарії й межі ніхто не чіпав.
Чесне формулювання для звіту — усі три зрізи одним рядком: «покрито 90%, виконано 75%, пройшло 68%, у 3 вимогах відкриті критичні дефекти». Це та сама реальність, але з неї вже можна ухвалювати рішення.

Кейс 2. Pass rate 95%: препаруємо перед go/no-go

Автопрогін регресії перед релізом: 240 тестів заплановано, 200 виконано, зі звіту — «95% pass». Розкладаємо, звідки взявся відсоток, простим скриптом поверх JSON-звіту Playwright:

import { readFileSync } from 'node:fs';

// stats JSON-репортера Playwright: expected / unexpected / flaky / skipped
const { stats } = JSON.parse(readFileSync('results.json', 'utf-8'));

const executed = stats.expected + stats.unexpected + stats.flaky;

// наївний погляд: flaky «полагодились» ретраєм, отже нібито passed
const naive = (((stats.expected + stats.flaky) / executed) * 100).toFixed(1);

// чесний погляд: flaky — окрема категорія нестабільності, не успіх
const honest = ((stats.expected / executed) * 100).toFixed(1);

console.log(`Наївний pass rate: ${naive}%`);
console.log(`Чесний pass rate: ${honest}% (flaky: ${stats.flaky}, skipped: ${stats.skipped})`);

Припустімо, скрипт видав: наївний 95.0%, чесний 91.5%, flaky 7, skipped 40. Що дивитися і чому:

Знаменник. 95% порахованих від виконаних — не те саме, що від запланованих: 40 skipped і заблокованих кейсів випали з картинки разом із функціональністю, яку мали перевірити. Від 240 запланованих ті самі зелені дають уже близько 79% — і це чесніша цифра для рішення про реліз.
Сім flaky — не сім passed. Прогін, що «полагодився» після ретраю, у наївній статистиці виглядає зеленим, а реальна стабільність сьюти невидима. Якщо звіт показує лише «зелений/червоний» без окремої категорії flaky — метрика вже трохи бреше.
Вага червоних. Pass rate — число без ваги: п'ять фейлів в екзотичних крайових кейсах і п'ять фейлів у кроках чекауту дають однаковий відсоток і протилежні рішення. Поруч із відсотком має стояти розшифровка фейлів за пріоритетом.
Знімок проти тренду. «Сьогодні 91.5%» німе без кривої: 91.5% на шляху вгору і 91.5% після триденного падіння з 99% — протилежні сигнали. Якщо нові дефекти третій день прибувають швидше, ніж закриваються, реліз у зоні ризику, хоч би яким був відсоток.

Кейс 3. Test summary report на сторінку: реліз із відомим критичним багом

Реліз завтра, критичний баг у промокодах не пофікшено. Спокуса — позеленити звіт або написати простиню з 15 метрик. Робочий варіант — сторінка, побудована від рішення читача:

Test Summary Report — реліз 2.14

Скоуп: чекаут, промокоди, історія замовлень.
НЕ тестували: міграцію старих акаунтів — стенд без прод-дампа
(ризик винесено в окремий пункт нижче).

Критерії виходу (з тест-плану):
  [x] 100% критичних кейсів виконано
  [ ] 0 відкритих blocker/critical — НЕ досягнуто: BUG-1482 (critical)

Метрики:
  Покриття вимог: покрито 92% / виконано 88% / пройшло 84%
  Pass rate: 91.5% від виконаних; flaky 7; усі фейли, крім BUG-1482, — minor
  Динаміка: нові дефекти спадають 3 дні поспіль, закриті наздогнали заведені

Залишкові ризики:
  BUG-1482 — подвійне списання промокода при повторному кліку «Застосувати».
  Зачіпає ~2% замовлень із промокодом; обхід: одноразові промокоди.
  Непротестована міграція старих акаунтів — ризик невідомий, потрібен прод-дамп.

Відхилення від плану: стенд лежав 2 дні → зрізано хвіст
низькопріоритетної регресії (перепріоритезація за ризиком).

Рекомендація QA: go з умовами — хотфікс BUG-1482 у перші 48 годин,
моніторинг замовлень із промокодами після викатки.

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

Звіт починається з рішення, а не з цифр. Читач має відповісти собі «релізимо чи ні, і що ризикуємо» — усе інше підпорядковане цьому. Таблиця метрик без висновку — дамп, а не звітність.
«НЕ тестували» — обов'язковий рядок. Пропущений скоуп, який спливе після релізу, б'є по довірі сильніше за будь-який баг. Чесне «міграцію не чіпали, ось чому» дешевше за сюрприз у продакшні.
Критерії виходу — по пунктах, з чесним «не досягнуто». Це і є вимірна відповідь на «чи можна завершувати»: не «начебто можна», а звірка факту з порогом. Недосягнутий пункт не ховається — він перетворюється на ризик і умову в рекомендації.
Ризик — мовою бізнесу. «~2% замовлень із промокодом, є обхід» дає менеджменту ймовірність і ціну; «баг у PromoService при повторному POST» — ні. Номери багів і стектрейси — для командного progress report, не для стейкхолдера.
Рекомендація QA — не рішення про реліз. Рішення ухвалює бізнес, але «go з умовами» з конкретними умовами — це позиція, за якою видно роботу; мовчазний зелений звіт — ні.

Метрики як інструмент

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

Покриття вимог у звіті

Знаю три різні зрізи покриття: покрито тестами / виконано / пройшло — і чому плутати їх означає маніпулювати звітом.
Можу пояснити, чому 100% покриття вимог не означає якісний продукт: покриття рахує наявність тесту, а не достатність, плюс самі вимоги бувають неповними (absence-of-defects fallacy).

Метрики дефектів

Знаю різницю між щільністю дефектів, escape rate/DDP і часом життя дефекту — і яке рішення обслуговує кожна.
Пам'ятаю пастку щільності: вона рахує знайдені дефекти, тож «чистий» модуль може бути просто погано протестованим.
Можу порахувати DDP і escape rate на прикладі (90 багів до релізу + 10 після = DDP 90%, escape rate 10%) і знаю обмеження: рахується постфактум, тому цінність — у тренді між релізами.
Розумію, що defect age читається розбивкою за фазами (тріаж / фікс / верифікація) і показує вузьке місце процесу.

Pass rate

Стежу за знаменником: pass rate від виконаних і від усіх запланованих — різні звіти, бо blocked і skipped випадають з картинки.
Знаю, чому pass rate — число без ваги: поруч завжди має бути розшифровка фейлів за пріоритетом.
Можу пояснити, як флакі-тести спотворюють статистику через ретраї і чому Playwright рахує flaky окремою категорією (expected / unexpected / flaky / skipped).
Пам'ятаю картину здорової стабілізації перед релізом: виконані тести ростуть, нові дефекти спадають, закриті наздоганяють заведені.

Звітність

Можу назвати скелет test summary report: скоуп (включно з тим, що НЕ тестували), звірка з критеріями виходу, ключові метрики, відкриті дефекти й залишкові ризики, відхилення від плану, рекомендація go / no-go / go з умовами.
Знаю різницю test progress report vs test summary report: регулярний пульс для команди проти підсумкового документа для рішення про реліз; різним читачам — різна деталізація (команді номери багів і стенди, стейкхолдеру ризики й дата).
Можу описати, що писати у звіті, коли реліз завтра, а критичний баг відкритий: факти, ризик мовою бізнесу, варіанти, рекомендація.

Моніторинг і контроль

Знаю різницю test monitoring vs test control: збір і порівняння з планом проти коригувальних дій; моніторинг без контролю — спідометр без керма.
Можу назвати типові контрольні дії: перепріоритезувати за ризиком, перекинути ресурси, ескалювати, переглянути скоуп або дату, змінити критерії — свідомо і письмово.
Розумію, як цикл замикається: план задає пороги → моніторинг порівнює → контроль коригує → summary report годує наступне планування.