Manual QA

Метрики якості

що міряти, як рахувати, чого уникати

Як ти обираєш метрики якості для проєкту?

Не з переліку «популярних метрик», а від цілі. Зручна рамка — GQM (Goal → Question → Metric):

Ціль: «зменшити кількість дефектів, які доходять до проду».
Питання: скільки дефектів ми пропускаємо? На якому етапі мали б їх ловити? Які модулі найпроблемніші?
Метрики: defect leakage, розподіл продакшн-багів за модулями і за етапом, де їх можна було знайти.

Правила: кожна метрика має власника і дію, яку вона запускає; метрик мало (3–5 ключових); дивимося на тренд, а не на одне значення.

На співбесіді: Я починаю з цілі, а не з метрики, за підходом Goal-Question-Metric. Наприклад, ціль — менше багів у проді, питання — скільки ми пропускаємо і де мали їх ловити, а метрики — defect leakage і розподіл продакшн-багів за модулями. Тримаю три-п'ять ключових метрик, кожна з яких веде до конкретної дії, і дивлюся на тренди, а не на окремі цифри.

Що таке defect leakage, DRE і defect density і як їх рахувати?

Метрика	Формула	Що показує
Defect leakage	баги з проду ÷ (баги до релізу + баги з проду) × 100%	Яку частку дефектів ми пропускаємо
DRE (Defect Removal Efficiency)	баги до релізу ÷ (баги до релізу + баги з проду) × 100%	Ефективність відлову: 100% − leakage
Defect density	кількість дефектів ÷ розмір (модуль, KLOC, story points)	Які частини найпроблемніші

Приклад: за реліз знайшли 45 багів до проду і 5 після. Leakage = 5 ÷ 50 = 10%, DRE = 90%.

Нюанс, який варто сказати: рахувати лише значущі дефекти (наприклад, Major і вище) і за фіксоване вікно після релізу, інакше дрібниці спотворюють картину.

На співбесіді: Defect leakage — це частка дефектів, які ми пропустили в прод, від усіх знайдених. DRE — навпаки, частка знайдених до релізу. Наприклад, сорок п'ять багів до релізу і п'ять після — це десять відсотків leakage і дев'яносто DRE. Defect density показує, які модулі найпроблемніші. Я рахую лише значущі дефекти і за фіксоване вікно після релізу, щоб дрібниці не спотворювали картину.

Чим покриття вимог відрізняється від покриття коду? Чи потрібне 100%?

Покриття вимог — яка частка вимог чи критеріїв приймання має тести, і скільки з них пройшли. Рахується через матрицю простежуваності або зв'язки в Jira/Zephyr.

Покриття коду — яка частка рядків чи гілок виконується тестами. Міряють інструменти, переважно для unit-тестів.

100% — не мета. Високе покриття коду не гарантує якісних перевірок (тест може виконати рядок і нічого не перевірити), а 100% вимог може означати поверхневі кейси. Важливіше покриття ризиків: критичні сценарії покриті глибоко, другорядні — достатньо.

На співбесіді: Покриття вимог показує, яка частка вимог має тести, покриття коду — яка частка коду виконується тестами. Сто відсотків для мене не мета: тест може виконати рядок і нічого не перевірити. Я орієнтуюся на покриття ризиків — критичні сценарії мають бути покриті глибоко, а другорядні достатньо.

Які метрики процесу ти відстежуєш?

Час виправлення дефектів за severity — чи вкладаємося в домовлені терміни.
Reopen rate — частка багів, що переоткриваються: сигнал про якість фіксів або ретесту.
Rejected rate — частка багів, відхилених як «не баг» або дубль: сигнал про якість репортів чи вимог.
Прогрес виконання тестів — виконано, пройдено, заблоковано на поточний момент релізу.
Час у статусі «Ready for QA» — чи не стає тестування вузьким місцем.

Кожна з них — привід для розмови на ретро, а не оцінка людей.

На співбесіді: Я дивлюся на час виправлення дефектів за критичністю, reopen rate — скільки багів переоткривається, rejected rate — скільки відхиляється як не баг чи дубль, прогрес виконання тестів і скільки задач чекають на QA. Високий rejected rate, наприклад, підказує, що проблема у вимогах або в моїх репортах — і це тема для ретро.

Які метрики використовуєш для автоматизації?

Покриття автоматизацією: частка регресійних кейсів, що автоматизовані, — особливо критичних.
Flaky rate: частка тестів, що то падають, то проходять без змін у коді. Ціль — близько нуля, бо флакі руйнують довіру до всього набору.
Час прогону і його тренд — чи не сповільнюється фідбек на PR.
Pass rate на main — стабільність.
Знайдені автотестами дефекти — чи автоматизація реально ловить регресії.
ROI: скільки годин ручної регресії замінено мінус витрати на підтримку.

На співбесіді: Для автоматизації я відстежую частку автоматизованої регресії, flaky rate, час прогону, pass rate на основній гілці і скільки регресій реально впіймали автотести. Flaky rate для мене найважливіший: якщо команда перестає довіряти червоним тестам, автоматизація втрачає сенс.

Які метрики шкідливі і чому?

Закон Гудгарта: коли метрика стає ціллю, вона перестає бути хорошою метрикою.

Кількість знайдених багів як KPI → дрібні баги розбиваються на кілька, конфлікти з розробниками, ніхто не займається запобіганням дефектам.
Кількість написаних тест-кейсів чи автотестів → багато дрібних і дубльованих кейсів.
«Нуль багів у проді» як особиста ціль QA → страх релізів і зайва бюрократія.
Метрики для порівняння людей → спотворення даних.

Метрики мають показувати стан системи й процесу, а не оцінювати окремих людей.

На співбесіді: Я обережний з метриками на кшталт кількості знайдених багів чи написаних кейсів як KPI. За законом Гудгарта, коли метрика стає ціллю, люди оптимізують цифру, а не якість: баги дробляться, кейси дублюються. Метрики мають показувати стан продукту й процесу, а не оцінювати людей.

Як побудувати дашборд якості для різних стейкхолдерів?

Різним людям потрібні різні відповіді:

Бізнес / PM: чи готовий реліз, відкриті блокери й критичні, ризики, тренд продакшн-інцидентів.
Команда: прогрес тестування спринту, баги за статусами, flaky-тести, час у «Ready for QA».
Менеджмент: тренди за квартал: leakage, час виправлення, стабільність релізів.

Технічно: фільтри JQL у Jira і гаджети на дашборді, звіти Zephyr чи Xray, Allure для автотестів; для складнішого — Grafana чи BI-інструменти.

-- відкриті критичні баги поточного релізу
project = PAY AND issuetype = Bug AND fixVersion = "2.15"
  AND priority in (Highest, High) AND statusCategory != Done

-- баги з проду за останні 30 днів (для leakage)
project = PAY AND issuetype = Bug AND labels = production
  AND created >= -30d ORDER BY priority DESC

На співбесіді: Я будую дашборд під аудиторію. PM потрібна відповідь, чи готовий реліз і які блокери, команді — прогрес спринту й статуси багів, менеджменту — тренди за квартал. Технічно це JQL-фільтри й гаджети в Jira, звіти Zephyr і Allure для автотестів.

Як довести, що якість покращилась? Що таке DORA-метрики?

Потрібні базова лінія (стан до змін), тренд за кілька релізів і зв'язок зі зміною в процесі. Одна цифра нічого не доводить.

DORA-метрики — чотири метрики ефективності доставки, які оцінюють і швидкість, і стабільність:

Deployment frequency — як часто релізимо.
Lead time for changes — від коміту до проду.
Change failure rate — частка релізів, що спричинили інцидент чи відкат. Найближча до QA.
Time to restore — скільки займає відновлення після інциденту.

Сильна відповідь: якість покращилась, якщо change failure rate і leakage падають, а частота релізів не падає — тобто ми не купили стабільність ціною швидкості.

На співбесіді: Я фіксую базову лінію і показую тренд за кілька релізів, пов'язаний з конкретною зміною в процесі. Для цього добре підходять DORA-метрики: частота деплоїв, час від коміту до проду, частка невдалих релізів і час відновлення. Справжнє покращення — коли частка невдалих релізів падає, а частота релізів не падає.