Я побудувала AI-пайплайн тестування задач: що з цього вийшло

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, наш зацікавлений читач 🙂 Це знову я, Аня, Head of QA в невеликому потужному продукті. Якщо ти читав мою попередню статтю про есенціалізм у керуванні QA-процесами, то вже знаєш про моє захоплення автоматизацією рутинних дементорів. З того часу я значно просунулася далі і хочу цим поділитися. А якщо ні — то на правах самореклами рекомендую почитати.

Сьогодні я поділюся думками не просто про промпт-інжиніринг, ні. Я розповім про особистий кейс побудови АІ-архітектури з гучною назвою Agentic System Design with human-in-the-loop. Якщо по-людськи — AI-помічник, що виконує завдання під моїм наглядом.

Огляд будемо робити на прикладі роботи з Claude Desktop. Розглядати будемо саме приклади тестування задачі.

Біль, який породив рішення

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

Швидкість розробки росте, а QA-команда не масштабується пропорційно. Спринти коротшають, фічі летять з шаленою швидкістю, ідеї генеруються миттєво, а команда більше не стає. Бізнес хоче релізити частіше, а якість при цьому не має падати. Знайомо?

Розробка непомітно перекладає частину своїх обов’язків на QA. Замість змістовно описаних тікетів прилітає щось типу «Ти ж тестувальник, розберися, що тут треба перевірити» або «ну так спитай у ChatGPT». По болючому, так?

Конкуренція на продуктовому ринку тисне на всіх. Кожен бізнес намагається випередити конкурентів (що цілком логічно), і хто як не АІ в цьому допоможе? «І взагалі, чому в еру ШІ фічі не виконуються за годину?»

Якби елементарно не звучало, але виходячи з потреб і породжуються рішення. Ось і я мала кілька своїх основних цілей, викликаних потребами:

• Посилити ресурси тестувальника до стану Шиви.
• Задовольнити потреби бізнеса з мінімальними вкладеними ресурсами.
• Вивести наші процеси на конкурентоспроможний рівень.
• Вивести продуктивність команди до незалежного від кількості випитої кави стану 🙂

Трошки про архітектурні рішення

Пропоную спочатку зробити розбір конструкції з самої ідеї QA Pipeline на AI. Погоджуюсь, що звучить якось пафосно, але якщо розібратися, то стане значно простіше.

Пайплайн — це послідовність кроків, де результат кожного попереднього кроку стає входом для наступного.

Уяви собі конвеєр на заводі Coca-Cola. Знаєш, як там відбувається процес? Спочатку з пластикової заготовки, такої собі «піпетки», видувають пляшку, потім охолоджують її, потім перевіряють якість цієї пляшки, далі наповнюють її рідиною, герметизують, одягають в етикетку, фасують тощо. Тобто, кожен конвеєр робить свою одну операцію і послідовним ланцюгом передає свій результат далі.

На кожному з цих етапів, звісно ж, стоїть контроль якості. От наприклад, стрічка конвеєра просто «випльовує» браковані пластикові пляшки, якщо вони «не пройшли валідацію» після формування з піпетки. Мені колись така прилетіла прямо у лоба 😅

Що в цьому головне? Що весь процес побудований з окремих дрібних степів, які мають ланцюгову залежність і «баг не дійде до прода».

Так само побудований і мій QA-пайплайн. На вхід потрапляє Jira-тікет, на виході — повний комплект тестової документації з результатом перевірок. Між входом і виходом у мене вийшло 8 степів і після кожного є «контролер якості» — тестувальник, який перевіряє результат і каже «ок, далі» або «летиш зі стрічки» на переробку.

У мене було багато спроб. Спочатку я думала, що одним скілом покрию потребу. Але як-то кажуть, не так склалося, як гадалося. Результати мене не задовольняли. Або втрачалася частка даних, або щось надумувалося, або якось те але не те виходило. Та і час виконання теж не задовольняв. Тож, методом пляшок у лоба, виправляючи свої помилки я розбивала і розбивала ланцюг на менші ланки. Таким чином вийшло 8 етапів.

Інсайт: Чим вужчий scope, тим якісніший результат скіла.

Чому вийшло стільки скілів?

Спочатку нагадаю, Скіл — це текстова інструкція для AI, яка описує що робити, з чим працювати, в якому порядку і що видати на виході. По суті це посадова інструкція для ШІ.

Тепер перерахую кілька основних пунктів які аргументували мені шо треба звужувати зони відповідальності:

Ізоляція збоїв. Якщо, наприклад, скіл згенерував поганий чекліст, я бачу це одразу, виправляю, і далі по ланцюжку наступному скілу на вхід вже прийде якісна інформація.

Дешевший перезапуск. Перезапустити один скіл значно дешевше в токенах та часі, ніж цілий ланцюг. Наприклад, один скіл з’їдає 40K токенів, а в ланцюгу 5 таких скілів по 40К. То перезапуск всього набору буде коштувати 200К токенів.

Токен — це одиниця тексту, якою оперує AI. Грубо кажучи, одне слово ≈ 1-2 токени. Кожне повідомлення, яке ти відправляєш AI — це токени на вхід.

Контроль на кожному кроці. Перевірка результату одного вузького скіла займає значно менше часу та концентрації, ніж весь ланцюг. Атомарні перевірки дають вищий рівень гарантії якості на виході.

Передача даних через контекст дорожча. Чому «на вихід» краще робити мд файл, а не контекст чату?

MD (Markdown) файл — фіксований артефакт, що не деградує. Його можна редагувати, шерити без втрат, перенести в інший чат без переповнення контексту.

Пару пояснюючих слів про використання контексту чату як «сорс оф тру»:

• Агент бере за «рамки/межі» твій перший промпт і далі базує відповіді на ньому.
• Чим довше ведеться чат, тим більше контексту агент забуває.
• Перехід на новий чат не переносить контекст завдання.
• Агент не розрізняє «важливу» та «прохідну» інформацію в чаті.

Розглянемо тепер сам «Skill Chain»

На схемі зображена кількість скілів та їх послідовність виконання.

Ми бачимо цілий степ-бай-степ ланцюг, бачимо повну залежність степу від степу. Виглядає навантажено, згодна. Але якщо розібратися трошки глибше? То можна побачити, що наприклад, скіл1 та скіл2 можна взяти окремою парою для пре-грумінгу/грумінгу тікета з командою. Або скіл1 — скіл3 можна використати окремо, для легкої задачі, яка не потребує всього етапу проходження. А от скіл7 можна використати окремо від всього ланцюга. Таким чином ми бачимо, що залежність є, але вона не жорстка в деяких сценаріях.

А чого не зробити скіли незалежними? Логічне питання, розумію. Звісно, їх можна зробити самостійними одиницями, все на вибір та умову кожного з нас. Але давай я трошки аргументую чому я вирішила так не робити.

Візьмемо для розбору ситуації скіл3 — генерацію чекліста. Спочатку нам треба щоб агент використав МСП атласіан (сходити по тікет в джиру). Потім зчитавши умови тікета побудував чекліст. На завершення видав нам чекліст у тому вигляді який ми хочемо.

Все логічно. Але виникають, на мій погляд, доцільні питання:

• А як бути певним що агент правильно вивчив тікет?
• А вкладені файли/скріни/макети, були зчитані?
• А за якими правилами будувати наш еталонний чекліст?
• А яким має бути чекліст на виході?
• А якщо в тікеті були «сирі» вимоги, яка буде вихідна якість чекліста?
• А якщо не сподобається цей результат, запустимо коло проходження наново?

Що я бачу у підсумку?

Наш скіл безумовно самостійно відпрацює і віддасть чекліст. Але. Чи буде цей чекліст повністю задовольняти потребу? Адже один скіл треба вкласти навички:

• як потрапити до тікетак;
• як правильно читати тікет;
• як мають оброблятися/валідуватися вимоги з тікета;
• як мають оброблятися проблемні зони;
• як заборонити фантазувати при обробці даних;
• які стандарти написання чекліста будуть використовуватися;
• який ми хочемо аутпут файл.

Це вже виглядає трошки навантажено для одного скіла, а також ставить питання — чи будуть втрати сенсу при роботі такого скіла. А при перевірці фінального результату (в нашому випадку це єдиний файл), нам треба почати перевірку з самого початку — чи всі дані з тікета потрапили в обробку. Відповідно потім пройти всі кроки, щоб впевнитися, що фінальний чекліст взагалі відповідає самому тікету. Кількість рухів для перевірки та перегенерації вражає, хіба ні?

Пропоную далі розглянути кожен скіл «під капотом». Я думаю, так стане значно простіше аргументувати цей набір послідовність та залежність 🙂

Скіл 1: Збираємо контекст задачі

Скіл крокує в Jira, збирає все, що є в тікеті — опис, коментарі, вкладення, acceptance criteria (будь-які поля, які вкажемо). Обробляє та зіставляє ці дані між собою, бо нам же треба, щоб текст з тікета потрапив до нас без втрат.

На виході у нас є єдиний файл-контекст, де все зібрано, дедупліковано та розкладено по секціях. Це source of truth для всіх наступних скілів.

Навіщо цей окремий скіл? Щоб наступні скіли не бігали в Jira кожного разу і не витрачали на це токени. А також, щоб по всьому ланцюгу передавав один і той самий перелік даних.

Скіл 2: Проводимо ревʼю вимог

Цей скіл з таким собі інтерактивом. Агент бере контекст сформований попереднім скілом і дивиться на нього очима QA на грумінгу. Кожну вимогу проганяє по чотирьох питаннях:

1. Чи можу я це перевірити?
2. Що мені для цього потрібно?
3. Де тут може зламатися?
4. Що не прописано?

Формує перелік питань/прогалин/протиріч які передає людині для покриття. Після узгодження з людиною — формує фінальний один пронумерований список вимог. У скіла прописані правила обробки вимог за техніками тест дизайну та стандарти покриття вимог.

⚠️ Нумерація для скіла прописана жорстка, тому що кожен наступний скіл перевикористовує цю нумерацію для подальшої роботи.

Скіл 3: Генерація чекліста

Цей скіл вичитує файл від попереднього скіла та декомпозує кожну пронумеровану вимоги на атомарні перевірки за стандартами ISTQB CTFL v4.0.

На виході ми отримуємо один файл з деталізованим чеклістом. Цей чекліст працює і для мануального тестування на останньому кроці, і як вхід для наступного скіла — тест-кейсів.

Скіл 4: Генерація тест-кейсів

Цей скіл виконує великий обсяг роботи, тому у нього максимально вузький список завдань. Тут виконується написання тест кейсів по чеклісту від попереднього скіла. У цього скіла є прописані правила написання тест кейсів за стандартом ISO/IEC/IEEE 29119-3:2021.

На виході ми маємо один файл з повним переліком тест кейсів для покриття задачі.

Скіл 5: PR Summary

На цьому етапі починається робота з кодом. Скіл читає Pull Request через GitHub CLI і формує структуроване саммарі: кількість файлів, які файли змінено, які компоненти затронуті, що додано, що видалено, що модифіковано. Цей скіл працює за жорсткими правилами роботи з кодом.

На виході ми маємо навігаційну карту ПР для наступного скіла.

Навіщо цей окремий скіл? Економія кроків часу та токенів при самому код-ревʼю. Наступний скіл буде знати де шукати реалізацію кожного тест-кейсу і не буде ходити по всьому дифу наосліп.

Скіл 6: Проведення імплементейшен код-ревʼю

Другий об’ємний і найскладніший у виконанні скіл в моєму пайплайні. Цей скіл бере тест-кейси, бере PR summary і перевіряє кожен тест-кейс по коду PR. Для кожного ставить відповідні статуси: PASS, FAIL, QA (мануально дивитися) та N/A (немає в коді/не імплементовано). Формує файл з результатом перевірок. Цей скіл так само працює з жорсткими умовами роботи з кодом.

На виході отримуємо файл з чеклістом перевірок та пояснення для FAIL та N/A пунктів.

Скіл 7: Impact Analysis як регресійне ревʼю

Цей скіл проводить таку собі регресійну перевірку супутнього функціоналу та тих місць, які зачіпав наш ПР. Тобто перевірка того чи не зламалось те що раніше працювало.

Розробники після виконання своєї частини роботи з тікетом формують мд файл, в якому міститься опис всіх тих змін, які вони робили. Це дуже корисна річ навіть для простого мануального тестування.

Отже, цей скіл читає цей мд файл і зіставляє з дифом PR. Перевіряє, чи залежний код коректно працює зі змінами.

Останній ланцюг в цього колі — мануальні перевірки.

Тестувальник отримує чекліст для перевірок, чекліст пройденого код-ревʼю та регресійний репорт. Залишається лише перевірити результат роботи агента, перевірити ті пункти, які не пройшли код-ревʼю, ну і додаткові «цікаві» перевірки, що передбачив агент. Також можна зробити кілька перевірок по критичних функціональних флоу задачі, для впевненості в якості.

Думаю, що тепер зв’язок і ціль всіх скілів зрозумілі? Видно один патерн, що всі скіли працюють за схемою: отримати вихідний-вхідний файл -> виконати своє завдання -> передати вихідний-вхідний файл. Зрозуміло, що в кожного скіла є свої додаткові правила еталонної обробки свого завдання і у кожного скіла є свій шаблон аутпут файлу. Розуміємо, що послідовний зв’язок жорсткий і при цьому скіли можна використовувати частково незалежно.

Також, варто уточнити, що я не використовую «аджентік» чи «коворк-тім» підхід, тому що я хочу бачити відповіді одразу, а не по проходу всього конвеєра. На цій ноті пропоную від сухого технічного переходити далі.

Які граблі траплялися на шляху

Напевно, зі статті вже видно, що шлях до робочого пайплайну був вимощений нервами та факапами. Тож поділюся основними з них.

Перші — «Фантазії»

Основною часткою проблем є вигадування. Наприклад, чекліст має покрити 10 вимог і в чеклісті їх дійсно 10, але 2 з них це взагалі невідомо де взяті дані. Перше що ми думаємо в такий момент — «не бреши!»

Спойлер: прописувати вимогу не бреши та не видумуй — не працює 🙂

Як виявилося, проблема в тому що AI вигадує тоді, коли немає за що «зачепитися». Коли не вистачає даних, або немає конкретики, або немає чітких критеріїв, але є наказ зробити.

Що реально допомогло:

По-перше, прив’язка кожного пункту до конкретної цитати з вимоги. Якщо пункт без прив’язки — одразу видно, що він надуманий.
По-друге, приклади-калібратори всередині скілів — AI бачить зразок правильного output і підлаштовується.
По-третє, зменшення scope — менше вимог за один раз = менше «інерційних» вигадок.
По-четверте, чіткі правила — якщо немає чіткої вимоги — не покривай її, сповіщай про «сиру» вимогу. Тобто роби проблему видимою.

Інсайт: Краще працює стратегія «зробити помилки видимими», а не «заборонити помилки».

Другі — «Перекручування»

Ще більш підступніший шкідник. Наприклад, агент бере вимогу «змінити ліміт з 5 на 10» і переформульовує в «збільшити ліміт». Здається нормально, правда? Поки не починаєш тестувати і не розумієш, що граничні значення втрачені, сорс оф тру відсутнє.

Це таке собі «semantic drift» — непомітна втрата точності при переформулюванні. AI не робить це навмисно, він просто «узагальнює» для стислості, бо його задача «обробити» і він не розуміє, що для тебе є важливим, якщо ти цього не вкажеш.

Що допомогло:

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

Інсайт: Прописаних жорстких заборон вийшло більше аніж дозволів 😅

Треті — «Навантаженість»

Запхала п’ять задач в один промпт і на виході жодне завдання не виконано належним чином. Це та сама проблема, про яку я писала в попередній статті: простіше писати багато дрібних сценаріїв замість кількох об’ємних. Привіт, есенціалізме!

Що врятувало:

Розбила один перевантажений скіл на два окремих. Кожен робить одну річ — і робить її добре.

Інсайт: Провела аналогію, що як «одна дія = один тест кейс», так само і тут — «одне завдання = один скіл».

Четверті — «Сміття на вході»

Це проблема якості вхідних даних, на жаль. Чим менше опису в Jira тікеті, тим більше волі на «мейд ін сам склєпав» для агента. Якщо немає чітких асептансів, то від скіла до скіла буде переходити вода. «Garbage in — garbage out», як-то кажуть.

Якщо до задачі не прилінковано PR або бранч — не буде ефекту від код-ревʼю. Якщо не вказані імпакти — регресія майже не можлива. Якщо тікет не декомпозований і містить 20+ вимог в одному описі — контекстне вікно моделі переповнюється, і починається та сама деградація уваги.

Інсайт: Більше конкретики — більше точних можливостей.

П’яті — «Ціна питання»

На початку, як відповідальний тривожник, я всюди пхала розумні моделі, тому що вони дуже добре виконують завдання. Але пізніше, кошторис показав мені переплату ~36% за кожному прогоні. Тож довелося самій трошки посидіти-подумати, як це виправляти.

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

Інсайт: Підхід «ми не з такої сім’ї, ми з богатої» не завжди винагороджується 😅

Давай поговоримо про гроші

Ось ми і дійшли до цікавого. Ця таблиця показує реальний кошторис одного повного прогону пайплайну на типовій задачі великого розміру:

Температуру я всюди вказую — 0, тому що мені потрібне виконання в рамках і менша кількість відсторонених польотів творчості.

Цифри наведені в API-еквіваленті (ціни Anthropic за токени станом на 2026). Якщо ви працюєте через підписку Claude.ai — вартість входить у фіксовану місячну оплату.

Головні cost drivers — це ціна розумної моделі та скіли що працюють з великою кількістю коду. Звісно ж, ціна коливається від тікета до тікета. Більше файлів в PR = ціник вище. Менше вимог в тікеті = менше грошиків. Я можу впевнено сказати, що у мене середнє по палаті значення — це 20 хвилин та 1.5$ на задачу.

Які показники я побачила

Вирівняна швидкість розробки і тестування

Рутинна підготовка до тестування, тестові артефакти та проходження тікета виконуються за хвилини, а не за години.

Тестувальник х2

Один тестувальник з пайплайном покриває більше задач, ніж раніше, і з вищою консистентністю. Спринт скоуп може збільшитися до х2 (в залежності від тікетів та дотестовувань).

Аnti-burnout

Стан людини «не вижатий» тому що робота «в парі» — це спрощений рівень навантаження. Так, години роботи у людини не змінилися, так, працювати все одно треба. Але, оскільки працюєш «не один», то навантаження і втома значно легші.

Онбординг

За рахунок хісторі, пам’яті та артефактам, вхід ньюкамера значно швидший, потребує менше людської участі і може майже не потребувати документації в Конфлюенсі, якої дуже часто немає.

Стандарт проходження задач

Кожна задача проходить однаковий шлях від вимоги до імпакт аналізу. Кожна задача простіше естимується, за рахунок схожого часу на проходження. Естимацію тепер простіше прогнозувати, а відповідно і скоуп відділу теж. За бажанням «прозорості», менеджмент може бачити конкретний traceable артефакт по кожній задачі.

Економічність

Навіть якщо повний прогін пайплайну на задачу буде ≈ $5. На 100 задач в місяць це ≈ $500. При тому ≈ 60-70% рутини, які робить пайплайн — це все скорочення часу і сил. Зрозуміло, що економія все одно висока, і в годинах, і в грошах.

Кілька слів замість висновку

Мене якось спитали: «А ти не боїшся що хтось скопіює твій підхід?».

Ні. І ось чому. Цінність не в промптах — їх можна скопіювати за п’ять хвилин. Цінність у тому шляху, який проходить кожен з нас, для того, щоб дійти до робочого стану. Кожна грабля, кожна ітерація, кожне «а давай спробуємо інакше» — це досвід, який не скопіюєш.

От я і хочу поділитися з тобою своїм кейсом, бо можливо, він тобі стане в нагоді. Скіли — це хороший інструмент, який економить час та ресурс людини за невеликі гроші. Процес — це знання. А знання стають ціннішими, коли ними діляться.

Вже традиційно, мотиваційна цукерка для натхнення 😊