AI-пріоритизація тестів: 12% коду тримає 80% багів

Після того як я бачив 30+ інженерних організацій, що "покращують test coverage", мій висновок такий: цифра-заголовок coverage — неправильна метрика гнатися. Реальне питання — який зріз вашої кодбази продукує баги. І майже в кожній команді є малий, ідентифіковний зріз, де відповідь концентрується.

Чому test coverage як одне число вводить в оману?

Бо воно усереднює якість по коду з нерівним ризиком. Repo на 75% line coverage може мати 95% покриття на безпечному utility-коді і 30% на гнильному billing-state-machine модулі, що шипить 60% продакшн-інцидентів. Цифра-заголовок каже "ок", bug rate каже "ні".

Definition: Risk-weighted coverage — покриття, виміряне проти ймовірності, що тестований код спричинить customer-видимий інцидент якщо зламається. Не те саме що line coverage.

Патерн через інженерні організації 30-500 співробітників консистентний: інциденти кластеризуються в модулях з високою частотою commits, високим recent churn і високою cross-service surface area. Coverage-цифри нічого з цього не бачать. Плоский coverage-target каже команді додавати тести туди, де найлегше — що рідко там, де живе ризик.

Як AI знаходить 12%, що мають значення?

Через кластеризацію трьох джерел даних, які ніхто не тримає в голові одночасно. Перше — git history: які файли змінюються найчастіше, хто змінює, наскільки великі зміни, як часто revert-яться. Друге — error logs та incident records: які модулі з'являються в postmortems, які routes кричать найголосніше, які сервіси ведуть customer-видимі інциденти. Третє — структура кодбази: які функції мають найвищу cyclomatic complexity, які на критичному path, які зовсім без тестів.

Definition: Bug-density cluster — набір файлів чи модулів зі статистично підвищеним рівнем post-merge дефектів, ідентифікований перетином git-churn, історії інцидентів і сигналів складності.

Робота AI — кластеризація і ранжування, не судження. Output — ранжований список модулів із прикріпленими сигналами: "Модуль X має найвищий cluster score бо (а) він у топ-5% git churn, (б) з'являвся в 4 з останніх 8 інцидентів, (в) середня складність функції 2.5x медіани repo, (г) coverage на змінених рядках за останні 90 днів 18%."

Цей ранжований список — відповідь на "де додавати тести першим". Сеньйори можуть override-ити ранжування контекстом, якого AI не має — але стартують з реального prior, не з гадання.

Як зазвичай виглядають ці 12%

Три категорії повторюються через SMB-інженерні організації:

State machines і workflow logic. Білінг, subscription lifecycle, onboarding-стадії, payment retries. Висока кількість гілок, висока історія інцидентів, легко пропустити edge case.

Integration boundaries. Webhook-хендлери, payment provider adapters, third-party API wrappers. Баги концентруються там, де зовнішня поведінка непередбачувана і код має компенсувати.

Нещодавно переписаний чи нещодавно набутий код. Усе, що churn-нулось за останні 90 днів, усе, що успадковано від acquisition чи контрактника. Recency і незнайомість обоє самостійно прогнозують дефекти.

Що ви помітите: цей список — не те, що coverage-percentage-driven команди тестують першим. Вони тестують легкі utility-функції, бо їх дешево покрити. Ризикові модулі пропускаються, бо складні.

Copy/paste шаблон пріоритизації

## Пріоритизація тестів — [КВАРТАЛ]

### Джерела даних, що годують AI-кластеризацію
- Git history (90 днів): commit count, file churn, revert count
- Incident records (останні 4 квартали): файли, причетні до SEV1/SEV2
- Error logs (30 днів): топ error rates по модулях
- Складність коду: cyclomatic per function, repo-median baseline
- Поточне test coverage по файлах

### Топ-10 модулів для інвестування (цей квартал)
| # | Модуль   | Cluster score | Сигнали                          | Coverage зараз | Ціль |
|---|----------|---------------|----------------------------------|----------------|------|
| 1 | [path]   | [N]           | churn=high, inc=4, complex=high  | [N%]           | [N%] |
| 2 | ...      |               |                                  |                |      |

### Senior-overrides
- [Модуль додано: чому людина знає що це важливо, а AI не бачить]
- [Модуль прибрано: чому людина знає що не важливо, хоч AI флагнув]

### Plan → Fact → Gap (рев'ю наступного кварталу)
- Plan: інвестувати тести в топ-10 вище
- Fact: на кінці кварталу, де баги реально концентрувалися?
- Gap: які модулі здивували; що кластеризація пропустила?

### Owner
- [Name] — accountable за test-investment рубрику цей квартал

Секція senior-override — це safety valve. AI виводить кластер; найдосвідченіші інженери команди додають чи прибирають на основі знань, що кластеризація не бачить. Секція Plan → Fact → Gap унизу — це те, що робить рубрику кращою квартал за кварталом.

Tool tip (AIAdvisoryBoard.me): Пріоритизація тестів — один зріз більшого Plan → Fact → Gap патерну, що йде через кожну функцію компанії. План був uniform coverage; факт — концентровані баги; розрив — відсутня рубрика пріоритизації. Той самий патерн з'являється в sales pipeline, ops bottlenecks, finance variance — кожна функція має свою версію 80/20 захованої в даних. Наша OS для щоденного управління піднімає ці розриви автоматично. https://aiadvisoryboard.me/?lang=en.

Manager scan (приклад 2-хвилинного digest)

• План: 80% line coverage target через repo, рівномірно
• Факт: з 14 продакшн-інцидентів минулого кварталу 11 торкнулися 6 модулів — ті 6 мали медіану 41% coverage
• Розрив: coverage-target — неправильна рубрика; потрібна risk-weighted пріоритизація
• Топ-10 cluster-scored модулів ідентифіковано цей квартал — записано з owner
• Сеньйори переглянули і override-нули 2 записи (1 додано, 1 прибрано) — зафіксовано в шаблоні
• Інвестиція тестів наступного кварталу спрямована на топ-10, не рівномірно
• "Repeat-incident в тому ж модулі" — трекати квартал за кварталом як outcome-метрику
• Цифра-заголовок coverage ігнорована на leadership-рівні, тримається на інженерному
• Квартальне ревʼю рубрики — що AI-кластеризація пропустила, що додати до inputs
• Цикл incident-до-test follow-up: кожне SEV1/SEV2 retro додає модуль до inputs наступного кварталу

Micro-case (що змінюється за 7-14 днів)

120-інженерна payments-платформа була на ~14 SEV2-або-вище інцидентах за квартал і мала 78% coverage на дашборді. Leadership читало 78% як "ок", інженерія знала, що баги концентруються в billing state machine і webhook-адаптері, ніхто не мав рубрики переспрямувати інвестиції. Запустили AI-кластеризацію по 4 кварталах інцидентів, 90 днях git history, продакшн-error логах — і отримали ранжований топ-10, що включав billing-state, webhook-adapter і чотири модулі, що ніхто не флагав: cron-job orchestrator, legacy receipt generator, user-merge utility і обскурний subscription-pause path. Сеньйори додали ще два з контексту (third-party інтеграцію що скоро renew-ається, deprecated path запланований на видалення але ще не видалений) і прибрали один (флагнутий модуль що видалявся наступним спринтом так чи інакше). Інвестиція тестів пішла на ті 11 модулів. SEV2-або-вище наступного кварталу впав з ~14 до ~5 — і цифра-заголовок coverage стала нижчою, бо вони видалили тести на безпечному utility-коді щоб звільнити бюджет.

Note on this case: Цей приклад ілюстративний — на основі типових патернів у компаніях 30-500 співробітників, не один названий клієнт. Конкретні числа — округлені наближення поширених діапазонів, не гарантії.

Tool tip (AIAdvisoryBoard.me): Глибший хід тут не "юзати AI щоб обрати тести" — а "побудувати Plan → Fact → Gap цикл де баги минулого кварталу годують test-бюджет наступного". Цей цикл — та сама форма, що ми ганяємо для sales, ops і фінансів: план, виміряти факт, назвати розрив, переспрямувати інвестицію. 7-денна діагностика показує, де ці розриви вже існують у ваших даних. https://aiadvisoryboard.me/?lang=en.

FAQ

Чи це не просто rediscover того, що сеньйори вже знають? Частково. Сеньйори знають "billing state machine ризикова" — але не знають відносного ранжування через 200 модулів і пропускають модулі з тихим churn, про який ніхто не говорить. Цінність AI — у ловінні другої категорії.

Що якщо наша кодбаза достатньо мала, щоб mental-model її? Тоді це не треба. Для 5-інженерних repos сеньйорська інтуїція виграє. Цінність кластеризації вмикається на 8-12 інженерах і 100+ модулях.

Чи це не генеруватиме шум з популярних файлів типу utils.ts? Добрий clustering-пайплайн вагує за складність і історію інцидентів, не сирий commit count. utils.ts має високий churn але низьку складність і рідко з'являється в postmortems — автоматично випадає з ранжованого списку.

Як обробляти кейс "ми знаємо, що перепишемо цей модуль"? Senior-override прибирає. Не інвестувати тест-бюджет у код, запланований до видалення. Зафіксуйте причину в шаблоні, щоб ревʼю наступного кварталу могло перевірити, що переписування дійсно відбулося.

Чи це має штовхати і видалення низькоцінних тестів? Так. Більшість команд мають 20-40% тестів на коді, що не ламається і не на критичному path. Вирізання їх звільняє інженерний час без підвищення ризику. AI може ранжувати low-value тести з тією ж кластеризацією.

Висновок

Test coverage як одне число нічого корисного не каже про те, де ховаються баги. AI-кластеризація git history, error logs і складності — каже. Plan → Fact → Gap — це цикл, що перетворює ранжування на квартальну рубрику інвестиції замість one-off аудиту.

Зберіть джерела даних цього тижня. Запустіть кластеризацію раз. Отримайте ранжований топ-10 до п'ятниці. Override-те сеньйорським контекстом. Переспрямуйте test-бюджет наступного кварталу.

Якщо хочете систему, що виводить Plan → Fact → Gap автоматично — щодня, через інженерію і решту компанії — подивіться 7-денну діагностику на https://aiadvisoryboard.me/?lang=en.