Аналіз тестів AI: де ламається ручна класифікація помилок
Поки прогонів десяток на добу, розбір падінь тримається на пам'яті двох-трьох інженерів.
Щойно збірка запускається на кожну зміну й матрицю оточень, рахунок іде на сотні прогонів, і ручна класифікація помилок перестає сходитися: черга на тріаж падінь зростає швидше, ніж її встигають розгрібати.
Гірше те, що нестабільні тести виглядають у звіті так само, як справжній дефект.
Падіння через таймінг, порядок запуску або стан тестових даних вимагає тих самих дій, що й регрес у коді, тому значна частина часу йде на підтвердження того, що причина не в продукті, а в самому тесті.
Далі вердикти розходяться. Один інженер відносить збій до зміни в сервісі, інший — до оточення, третій закриває як відомий; однакові падіння заводять заново, бо дублі ніхто не відсіює.
Шум у звітах про прогони накопичується й маскує реальні дефекти: на тлі «вічно червоних» тестів новий збій не читається як сигнал і спокійно доїжджає до релізу.
Ціна такої схеми — не лише години на розбір, а й втрачені сигнали: що більше шуму, то нижча довіра до звіту, і команда перестає реагувати на червоне. Розбираємо, як аналіз тестів AI знімає цю роботу з інженерів — від ознак падіння до готового вердикту з причиною.
Що змінюється після впровадження AI-розбору результатів
На вході — той самий набір результатів, на виході — зведення, яке можна читати, а не розшифровувати. Автоматична класифікація відмов розкладає падіння за причинами: регрес у коді, нестабільний тест, зміна оточення, недоступний зовнішній сервіс.
Інженер отримує вердикт із прив'язкою до конкретної перевірки й посиланням на артефакт, а не список червоних рядків.
Частка пояснених падінь — перша метрика, на яку варто дивитися. До впровадження зазвичай пояснюється менше половини відмов, решта йде в ручний розбір; після — більшість падінь приходить із уже названою причиною.
Випадки, які система не змогла пояснити, підсвічуються окремо: їх видно, і вони не тонуть у загальному шумі.
Час розбору прогону скорочується завдяки тому, що групування й відсів повторів відбуваються до людини. Замість читання всього журналу інженер дивиться згруповані причини й підтверджує або відхиляє вердикт.
Повторюваність вердиктів тримається на фіксованому наборі правил: однаковий набір падінь отримує однакову класифікацію незалежно від того, хто розбирає прогін і в яку зміну.
Окремо зникає клас відмов «дублі й шум»: той самий збій, розмножений на сотню перевірок, згортається в один запис. Зведення за прогоном стає коротким, його можна порівняти з попереднім — динаміка за причинами видна без ручного зіставлення.
Перевірити ефект можна на своїй історії падінь: запускаємо розбір накопичених результатів і дивимося, яка частка отримує автоматичне пояснення, а яка залишається людині.
Порівняння підходів до розбору результатів прогонів
Вибір способу класифікації падінь визначає, скільки ручної роботи залишиться після автоматизації та як швидко розбір наздоганяє сам прогін. Нижче — чотири варіанти, між якими зазвичай обирають на старті.
Правила за шаблонами тримаються на стабільних іменах тестів і форматі повідомлень, тому дають пояснюваний результат на кожному падінні, але розсипаються при зміні тексту помилки.
Ручна розмітка точна, проте масштабується лінійно: що більше прогонів, то пізніше команда дізнається про регресію.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Правила за шаблонами логів | Стабільні імена тестів і формат повідомлень, потрібен пояснюваний результат | Ламається при зміні тексту помилок, шаблони й пороги доводиться підтримувати вручну |
| Ручна розмітка силами команди | Мало прогонів, висока ціна помилки | Гальмує цикл налагодження, залежить від навантаження інженерів, знання не залишається в системі |
| Зовнішня модель без донавчання | Потрібен швидкий старт, збої типові | Не знає специфіки проєкту, помиляється на рідкісних класах помилок |
| Модель на історії падінь | Великий потік прогонів, накопичена розмітка, повторювані класи | Потребує даних і періоду навчання, потрібен контроль дрейфу й перевірка на відкладеній вибірці |
На практиці підходи комбінують шарами: правила закривають очевидні випадки, модель на історії — неоднозначні, а все, що нижче порога впевненості, йде в ручну розмітку й поступово поповнює навчальну вибірку.
Пороги класифікації добираємо за метриками: частка автоматично розібраних падінь, точність на відкладеній вибірці, частка випадків, що повернулися до людини.
Як відбувається впровадження: від аудиту звітів до передачі моделі
Впровадження відбувається етапами, і кожен закривається артефактом, який можна перевірити, а не звітом «роботи виконано».
Порядок жорсткий: поки не описані джерела результатів і не узгоджена схема класів помилок, будь-яка розмітка виявиться непридатною і її доведеться переробляти.
-
Інвентаризація джерел результатів. Зводимо звіти про прогони в одне місце: файли XML/JSON з автотестів, вивантаження із системи збірки, записи в трекері дефектів. Фіксуємо формати, глибину історії та поля, які заповнюються стабільно.
-
Аудит звітів про прогони. Рахуємо за історією частку нестабільних тестів, падінь через оточення й дублів. Отримуємо базову лінію, з якою потім порівнюємо модель, а не «стало краще на око».
-
Узгодження схеми класів помилок. Визначаємо взаємовиключні класи: регрес продукту, нестабільний тест, проблема оточення, помилка тестових даних. Схему будуємо від дії команди — інженер має розуміти, що робити з кожною міткою.
-
Збір і розмітка історичних даних. Вивантажуємо кілька місяців прогонів і розмічаємо їх силами інженерів з якості, окремо рахуючи узгодженість розмітників. Спірні випадки розбираємо регламентом, інакше модель успадкує протиріччя.
-
Налаштування й калібрування порогів. Навчаємо класифікатор на розміченій історії й добираємо поріг впевненості так, щоб рідкісні критичні падіння не губилися в потоці шуму. Видачу результату вбудовуємо у звіт зі збірки.
-
Приймання за метриками якості та передача. Перевіряємо повноту й точність за кожним класом на відкладених прогонах, які модель не бачила, і фіксуємо ці метрики як критерій приймання. Віддаємо конфігурацію, регламент донавчання й порядок відкату на попередню версію.
Конфігурації, схема класів помилок і регламент розбору
Комплект документації — це те, що відрізняє робочу систему від разового експерименту.
Якщо схема класів помилок живе в голові одного інженера, а пороги впевненості правилися вручну в скрипті, при першій же зміні вимог класифікація попливе і порівняти результати до й після стане неможливо. Тому ми фіксуємо всі домовленості в артефактах, які команда веде й редагує без нашої участі.
- Конфігурація класифікатора — винесені назовні ознаки, ваги й пороги впевненості. Зміна поведінки не потребує правки коду й перезбірки: правиться файл, проганяється перевірка на еталонному наборі.
- Схема класів помилок — ієрархія «група → клас → підклас» з описом кожного класу, прикладами й власником. Нова категорія додається без ламання вже накопиченої статистики за минулі періоди.
- Правила розмітки — що вважати одним дефектом, як розмічати збій, що проявився в кількох перевірках одночасно, і як поводитися зі спірними випадками. Без цього два інженери розмічають той самий прогін по-різному.
- Регламент розбору падінь — строки реакції на новий клас, поріг, після якого збій іде на ручний розбір, і умови, за яких падіння блокує випуск.
- Матриця доступів і ролі — хто бачить результати прогонів, хто змінює схему класів, хто затверджує правки в правилах розмітки. Права розділені так, що розширити довідник може інженер, а переписати логіку класифікації — лише відповідальний за якість.
- Еталонний набір і журнал змін — фіксована вибірка прогонів, на якій перевіряється кожна правка, й історія версій схеми: видно, що і коли змінилося і як це вплинуло на розподіл класів.
Окремим пунктом іде документація щодо розгортання й підключення до вашої системи прогонів, щоб розвиток не залежав від авторів рішення.
На виході ви отримуєте не чорний ящик, а керований контур, який ваша команда розвиває сама — ми залишаємося на зв'язку з питань, що потребують доопрацювання моделі.
Кейс: як розбір регресії прискорився в кілька разів
Замовник — продуктова команда, де регресійний прогін — кілька тисяч автотестів на кожну зміну в основній гілці. Частина падінь — реальні дефекти, частина — нестабільні тести й правки в тестових даних.
Розкласти це за виконавцями доводилося вручну: інженер відкривав звіт, читав стек викликів і сортував падіння.
До впровадження зведення за одним прогоном займало в чергового чотири-шість годин інженерного часу, а готове пояснення автоматично отримувала лише чверть падінь. У ручний розбір ішло більше половини випадків — включно з тими, що повторювалися з прогону в прогін.
Що змінили і що вийшло
Ми підключили розбір до звіту Allure: сервіс забирає історію прогонів, зіставляє стек викликів із минулими падіннями й відносить випадок до групи — новий дефект у коді, нестабільний тест, проблема оточення або тестових даних. Класифікація спирається на текст помилки, зачеплений модуль і правки, після яких тест почав падати.
Тепер зведення за прогоном збирається за хвилини, а автоматичне пояснення отримують близько 80% падінь. У ручний тріаж доходять одиниці спірних випадків — де ознаки суперечать одна одній або падіння зустрілося вперше.
Пріоритизація спирається на групу й частоту: нестабільні тести йдуть в окрему чергу, а ймовірні дефекти піднімаються нагору.
Чим розмітка правилами відрізняється від навчання на історії падінь?
Розмітка правилами — це експертиза, винесена в конфігурацію: інженер описує ознаки падіння (код повернення, фрагмент стеку, таймаут кроку) і система відносить випадок до класу за явною умовою.
Навчання на історії працює інакше — модель шукає статистичні збіги у вже розібраних падіннях і видає клас з оцінкою впевненості. Це не «краще чи гірше», а різні точки докладання зусиль.
Підтримка правил передбачувана: новий клас помилок — один блок у файлі розмітки, перевірка зміни й прогін на еталонній вибірці. Правило версіонується поряд із кодом, тому видно, хто і чому змінив вердикт.
Класифікатор при появі незнайомого збою потребує перерозмітки корпусу й перенавчання з підтвердженням, що старі класи не «поїхали» — цикл оновлення помітно довший.
Прозорість вердикту — друга розбіжність. Правило пояснює себе: у звіті видно умову, що спрацювала, і тест-інженер оспорює конкретний рядок, а не «думку системи». Модель відповідає оцінкою впевненості без причини — спірне падіння перетворюється на окреме розслідування.
Звідси й стійкість до нових типів помилок: правило вмикається того самого дня, коли з'явився незнайомий збій, а модель відносить його до найближчого знайомого класу й тим самим маскує.
Тому базові класи закриваємо правилами, а навчений шар підключаємо точково — наприклад, на scikit-learn для розмитих ознак, де розмітка правилами дає хибні спрацювання.
Часті технічні питання щодо впровадження розбору
Інженерні команди перед стартом перевіряють не точність моделі в презентації, а її поведінку на власному потоці падінь. Зібрали питання, які задають найчастіше.
Відправна точка — те, що вже накопичено: логи прогонів, звіти, розмітка в трекері. За ними видно, які класи помилок реально зустрічаються і що автоматизувати першим.
Скільки історичних даних потрібно?
Потрібна розмітка, а не обсяг логів: кожен клас має бути підтверджений десятками прикладів. Рідкісні класи залишаємо в ручній черзі.
Як бути з хибними спрацюваннями класифікатора?
Усе, що нижче порога впевненості, позначається як «не класифіковано». Поріг калібруємо на відкладеній вибірці, спірне йде інженеру.
Що буде при новому типі помилок?
Новий клас падає в «невідоме», а не натягується на знайому категорію. Далі ручна мітка й донавчання на накопичених прикладах.
Чи потрібно супроводжувати модель після запуску?
Так: зміна оточення й набору перевірок зсуває розподіл. Робимо переоцінку за метриками й зберігаємо версії моделі для відкату.
Як це вбудується в конвеєр звітів?
Розбір стає кроком після прогону й бере дані зі звичних форматів звітів. Потрібен доступ до артефактів збірки й проєкту задач.
Обговоримо ваше завдання розбору результатів прогонів
Щоб оцінка обсягу робіт спиралася на факти, а не на здогадки, нам достатньо подивитися на поточні прогони: як вони запускаються, що потрапляє у звіти і що розбирається руками.
Зазвичай уже за першою вибіркою видно, де втрачається час — на перегляді журналів чи на ручній розмітці однакових збоїв.
Що підготувати до обговорення:
- Вивантаження звітів про прогони — архів за характерний період у тому вигляді, у якому звіти віддає ваша система: текстові журнали, машинно-читані файли, вкладення із системи збірки.
- Перелік джерел — стенди й сервіси, за якими йдуть перевірки, і де зберігається прив'язка тесту до результату.
- Періодичність прогонів — скільки запусків на добу, чи є нічні повні прогони й точкові після зміни коду.
- Вимоги до доступів до даних — що лежить у закритому контурі, що не можна виносити за периметр, хто власник систем.
- Еталонна розмітка — приклади падінь із уже проставленим класом помилки: на них налаштовується й перевіряється класифікація.
- Хто приймає результат — ролі, яким потрібен розбір, і що має бути в підсумковому звіті: зведення за класами збоїв, динаміка, прив'язка до тесту.
Опишіть завдання й надішліть те, що вже є, — повернемося з оцінкою обсягу робіт і планом впровадження розбору: етапи, склад робіт, точки приймання.
