Чому AI тест-сценарії залежать від ручної розмітки
Вимоги до поведінки системи живуть у користувацьких історіях і описі контракту API, а перевірки — в окремому репозиторії з автотестами.
Зв'язок між ними тримається на пам'яті автора: історію переписали на рев'ю, поле перейменували, додали обов'язковий параметр — перевірка залишилася незмінною і продовжує «зеленіти» на застарілому очікуванні. Розбіжність вимог і коду накопичується тихо, до першого розбору інциденту.
Далі вмикається арифметика. Регрес відстає від релізу: поки команда ганяє ручні прогони по критичних гілках, в основну встигає увійти ще дві зміни.
Один змінений контракт — інший формат помилки або новий статус за відсутності прав — валить десятки перевірок разом, і замість розбору причин починається масова правка або вимкнення. Підтримка автотестів у такій схемі забирає більше інженерних годин, ніж економить.
Окрема зона втрат — негативні гілки. Порожні та граничні значення, перевищення прав, конфліктуючі стани, необроблені типи в тілі запиту майже завжди залишаються поза покриттям: їх пишуть руками останніми, а ламаються вони першими.
AI тест-сценарії знімають цю залежність: перевірки виводяться з тексту історій і опису контракту, тому зміна вимог одразу змінює набір перевірок, а не залишає після себе застарілі. Розбираємо, як це влаштовано і що потрібно від команди на вході.
Що змінюється після впровадження: покриття та швидкість прогонів
Ефект від AI тест-сценаріїв вимірюється не числом згенерованих файлів, а часткою вимог, закритих перевірками, часом повного прогону і тим, які відмови перестають доходити до релізу. Ці метрики фіксуємо до старту — інакше обговорювати результат буде нічим.
- Покриття вимог. Кожна історія з критеріями приймання розгортається в набір перевірок: під автоматичним контролем опиняється 80–90% заявленої поведінки замість вибіркових 40–50% при ручному проході.
- Час повного прогону. Критичний набір вкладається в хвилини і запускається на кожну зміну, повний — в десятки хвилин за рахунок розділення на незалежні частини; очікування нічного вікна зникає.
- Усунений клас відмов. Розбіжності між контрактом сервісу та очікуваннями суміжних модулів ловляться до викату: джерело правди тримає OpenAPI, а не опис «для людей», який розходиться з кодом.
- Повторне використання перевірок. Кроки виносяться в загальну бібліотеку — новий сценарій збирається з готових блоків, частка перевикористаних кроків зростає від релізу до релізу.
- Вартість супроводу. Правка вимог оновлює пов'язані перевірки, нестабільні сценарії позначаються автоматично, розбір хибних падінь скорочується в рази.
Головний зсув — передбачуваність: випуск перестає залежати від того, чи встиг хтось пройти список руками. Кожен пункт звіряємо з вимірами до і після, тому розмова про результат йде на цифрах, а не на враженнях.
Три підходи до AI тест-сценаріїв та їх обмеження
Три підходи відрізняються не інструментом, а джерелом істини для перевірки. У шаблонних перевірок це заздалегідь описаний каркас, у генерації за вимогами — текст користувацької історії та опис API, у гібридного — реальний виклик, зафіксований на стенді.
Звідси різні класи відмов: шаблон ламається при зміні формату даних, генератор — при неповному описі, гібрид — при нестабільних тестових даних.
Вибір роблять за двома осями: наскільки стійкі вимоги і скільки шляхів потрібно покривати. Нижче — що виходить на кожному варіанті на практиці.
| Варіант | Коли підходить | Де ламається |
|---|---|---|
| Шаблонні перевірки | Стабільний контракт, повторювані сценарії, потрібен передбачуваний прогін | Нове поле або змінений формат — каркас правлять руками; нестандартні гілки залишаються непокритими |
| Генерація за вимогами | Історії описані докладно, потрібна швидка чернетка на десятки сценаріїв | Недосказана логіка валідації — модель вигадує перевірку, якої немає в системі, і дає хибні падіння |
| Гібридний підхід | Живий стенд, довгі ланцюжки викликів, висока ціна регресу | Потребує ізоляції оточення та стабільних даних, інакше записаний крок відтворюється не завжди |
Обмеження генерації передбачувані і знімаються інженерно, а не формулюванням запиту до моделі. Ми будуємо гібридну схему: сценарії генеруються за вимогами, потім проганяються на стенді, а розбіжності розбираються і перетворюються в шаблонні перевірки. Так покриття зростає від ітерації до ітерації, а набір тестів залишається відтворюваним.
Етапи впровадження: від аудиту вимог до передачі
Генерація AI-тест-сценаріїв не починається із запиту до моделі: якщо відразу подати їй опис API, вийде набір кроків, який гарно читається, але перевіряє не те. Тому робота йде етапами, і кожен закінчується артефактом, який можна перевірити до потрапляння в конвеєр.
- Аудит вимог. Розбираємо користувацькі історії, специфікації та колекцію запитів. Відзначаємо формулювання, з яких перевіряємий сценарій не вийде, — їх повертаємо авторам до старту, інакше модель добудує відсутнє і ми отримаємо хибне покриття.
- Схема генерації. Фіксуємо, що подається на вхід (історія, контракт, тестові дані) і що має бути на виході: кроки, очікувані відповіді, граничні значення, формат готових AI-тест-сценаріїв.
- Налаштування правил. Обов'язкові передумови, ізоляція даних між прогонами, пріоритети перевірок, заборона на порівняння зі змінними значеннями та на залежність від поточного часу.
- Перевірка на пілоті. Беремо кілька реальних доопрацювань і дивимося: скільки сценаріїв проходить без правки, де модель помилилася, яких даних не вистачило. Правимо схему, а не окремі сценарії.
- Вбудовування в процес. Генерація запускається за зміною вимог або контракту, результат йде в репозиторій автотестів; розбіжність вимог і коду видно при розборі змін, а не після релізу.
- Передача команді. Віддаємо схему, набір правил і розбір типових помилок, навчаємо на реальних задачах. Далі команда сама додає правила і розбирає спірні сценарії.
Що залишається у вас: набори перевірок і правила
Автогенерація не закінчується демонстрацією на тестовому стенді — інакше результат залишається у нас, а не у вас.
Ми передаємо набір артефактів, який живе у вашому репозиторії і працює без нашої участі: його можна правити, розширювати і підключати до будь-якого конвеєра перевірок.
- Набори перевірок — сценарії, згруповані за вимогами: позитивні шляхи, негативні гілки, граничні значення, перевірки контрактів API і кодів помилок.
- Правила розмітки вимог — угоди, за якими описані користувацькі історії та схеми API: обов'язкові поля, критерії приймання, формат прикладів. Саме вони визначають, наскільки стабільно генератор видає перевірки.
- Тестові дані — підготовлені набори та генератори даних, включаючи маскування персональних відомостей і передбачувані стани бази перед прогоном.
- Карта покриття — таблиця відповідності «вимога → перевірка»: видно, які шляхи закриті, а які залишилися без контролю, і цей стан вимірюється, а не обговорюється.
- Регламент оновлення — що робити при зміні контракту або критеріїв приймання: хто ініціює перегенерацію, як перевіряється розбіжність з ручними правками, як набір синхронізується з вимогами.
- Документація — інструкції щодо запуску, розбору падінь і додавання нових сценаріїв, щоб команда працювала з наборами без звернення до нас.
- Правила іменування та словник домену — єдині терміни та структура папок: через півроку за назвою перевірки зрозуміло, що вона валідує і до якої вимоги відноситься.
Усе це передається разом з вихідними кодами і розбором на вашій стороні — далі набори розвиває ваша команда.
Кейс: як скоротили ручні прогони на живому продукті
Продукт — особистий кабінет з білінгом, ролями доступу та десятком зовнішніх інтеграцій. Регрес тримався на ручних прогонах: 320 сценаріїв проходили за 6–8 годин перед релізом, а критичні шляхи — оплата, відновлення доступу, зміна тарифу — були покриті приблизно на 40%.
До критичних шляхів доходили останніми, коли час вже вигорів. За спринт на прод йшло 11–14 дефектів, і половина — там, де логіку змінили, а перевірку не встигли переписати: ручний сценарій застарівав швидше, ніж його підтримували.
Ми перебудували вхід у тестування. Джерелами стали користувацькі історії в трекері та специфікація API: з них генератор збирав чернетки кроків, перевірок і тестових даних, а інженер правил їх і позначав тегом «критичний шлях».
Сценарії вивантажувалися в готовий код на Playwright — вони живуть у тому ж репозиторії, що і продукт, і запускаються в конвеєрі збірки при злитті кожної гілки. Окремого «прогонного» дня більше немає.
Що показали метрики
Частка покритих критичних шляхів зросла з 40% до 88%, повний регрес скоротився з 6–8 годин до 45 хвилин. Дефекти, що дійшли до користувачів, впали з 11–14 до 2–3 за спринт.
Перший місяць ручні та згенеровані перевірки йшли паралельно — це підтвердило, що покриття зросло не за рахунок хибних спрацьовувань. Розбіжність сценарію з реальною поведінкою тепер правиться в одному місці, і весь ланцюжок перевірок повертається в зелене того ж дня.
Чим генерація за вимогами відрізняється від запису дій
Обидві техніки вирішують одну задачу — отримати набір перевірок, який проганяється на кожному релізі.
Різниця в джерелі істини: запис дій фіксує те, що система зробила в момент натискання кнопки, а генерація за вимогами — те, що вона зобов'язана робити за користувацькою історією та контрактом API.
Стійкість до змін інтерфейсу — перша розбіжність. Записаний сценарій тримається на локаторах конкретної верстки: переставили блок, змінили розмітку — набір розсипається, і половина падінь до логіки не відноситься.
Згенерований сценарій спирається на кроки, названі у вимогах, і на опис контракту в OpenAPI: правка в одному кроці підхоплюється іншими кейсами.
Читабельність наборів відрізняється найсильніше. Записаний тест — довгий ланцюжок кліків і очікувань, при розборі падіння сенс доводиться відновлювати за кроками. Згенерований набір читається як вимога: видно, яку гілку перевіряємо і за якої умови вона має впасти.
Головна відмінність — у тому, які дефекти ловляться. Запис підтверджує, що елемент на місці і перехід відбувся, тобто перевіряє верстку та навігацію.
Генерація з вимог та опису API закриває регрес логіки: коди відповідей, структуру тіла, граничні та негативні гілки, які вручну майже не відтворюють.
Вартість підтримки розподіляється по-різному. Запис дешевше на старті й дорожчає з кожним релізом: чим активніше змінюється інтерфейс, тим більше тестів переписують.
Генерація вимагає описаних вимог на вході, зате переживає редизайн і розширюється новим сценарієм, а не новим скриптом. На практиці техніки поєднують: запис — швидка чернетка на нестабільній ділянці, вимоги — довгоживучий регрес.
Часті технічні сумніви перед стартом
Сумніви на цьому етапі закономірні: генерація не замінює розуміння системи, вона прискорює рутину. Рішення спирається на два джерела — текстові вимоги та контракти API, тому якість результату напряму залежить від того, наскільки однозначно описано поведінку. Нижче — відповіді на те, що найчастіше запитують до старту робіт.
Наскільки точна генерація — скільки сценаріїв доведеться переписувати руками?
Ми не вважаємо згенерований сценарій готовим до запуску без рев'ю. Модель спирається на явні умови: вхідні дані, очікуваний код відповіді, структуру тіла, поведінку при помилці. Інженер перевіряє твердження та граничні значення, після чого сценарій йде в набір.
Частка правок залежить від дисципліни вимог, а не від моделі, тому ми відразу показуємо, де формулювання допускає подвійне читання.
Що робити, якщо вимоги неповні або суперечливі?
Неповнота — нормальний вхід, а не блокер. Генератор позначає місця, де не вистачає даних: немає очікуваної відповіді, не описано формат помилки, не задано поведінку при порожньому полі.
З цих позначок збирається список питань до аналітика — він і стає основним результатом першого проходу. Так прогалини у вимогах виявляються до розробки, а не на прийманні.
Чи не задублюємо ми автотести, які вже є?
Перед генерацією ми інвентаризуємо існуючий набір: звіряємо за ендпоінтом, типом перевірки та вхідними даними, а не за назвою файлу. Збіжні шляхи відсікаються, доповнюються тільки непокриті гілки — помилки, права доступу, граничні значення. У результаті набір зростає за рахунок прогалин у покритті, а не за рахунок повторів.
Які доступи до оточень потрібні і що з ізоляцією?
Достатньо тестового контуру та облікового запису з обмеженими правами. Генерація не ходить у продуктивне середовище і не пише дані — вона читає опис контрактів і запускає перевірки в ізольованому стенді з підготовленими фікстурами. Токени та адреси зберігаються у змінних оточення, а не в коді сценаріїв.
Обговоримо задачу: що потрібно, щоб почати
Оцінка AI-генерації тест-сценаріїв залежить не від обсягу коду, а від повноти вхідних даних: вимог, схеми сервісів і вже існуючих перевірок. Чим точніший вихідний набір, тим менше припущень у кошторисі і тим швидше порядок робіт перетворюється в працюючий контур.
Різниця між розпливчастим брифом і повним пакетом даних — це зазвичай кілька ітерацій уточнень і зсунута точка приймання результату.
Що прискорює оцінку проєкту:
- приклади користувацьких історій і критеріїв приймання — за ними видно, наскільки формалізовані вимоги і чи потрібен проміжний шар їх розбору;
- схема сервісів і контракти їх взаємодії — визначає, де генерація прив'язується до реальних викликів, а де залишається на рівні текстових описів;
- поточний набір перевірок: ручні чек-листи, автотести, їх покриття та частка нестабільних прогонів;
- обмеження оточень — які стенди доступні, чи є тестові дані і як часто вони оновлюються;
- правила доступу та вимоги до зберігання артефактів, якщо код і дані не покидають ваш контур;
- регламент випуску: як часто змінюються вимоги і хто підтверджує зміни;
- відповідальний за приймання — він же узгоджує критерії готовності.
Далі порядок робіт такий: розбір вимог, пілот на одному модулі, порівняння згенерованих сценаріїв з еталонним набором, потім розширення на інші сервіси. Опишіть задачу — повернемося з оцінкою та планом, де зафіксовані етапи, точки приймання та обсяг.
