AI-пайплайн тестування задач: технічний «підкапотний» розбір

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

Привіт, наш зацікавлений читач 🙂

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

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

Я проведу повний прогін задачі через пайплайн та покажу кожен крок зі скрінами. Задача тестова — про фруктові кошики, не з реальної борди. Навмисно, щоб не відволікати домен-специфікою і щоб ви бачили саме роботу інструменту, а не наш продукт.

Анатомія скілів

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

На скріні ми бачимо як організований порядок і зміст пайплайну.

⚠️ перепрошую за якість всіх скрінів, не можу з нею нічого поробити, нажаль.

💡Зверни увагу: в кожному скілі є файл самого скіла, допоміжні файли (references, field-maps) і шаблон вихідного файлу. Послідовність чітка, ланцюг видно візуально.

Ось так виглядає файл самого скіла:

Ось так виглядає шаблон аутпут файлу:

Отже, тепер підемо по черзі. Буде трохи сухо, але це ж технічна частина, так має бути :)

1. Jira Task Context

Мета: Зібрати всі дані задачі з Jira в один структурований файл — source of truth для всього подальшого ланцюжка.

Що робить: Підключається до Jira через MCP, читає поля задачі (опис, критерії приймання, нотатки для QA/DEV, коментарі, вкладення), зіставляє всі дані між собою і зберігає в єдиний Markdown-файл <ISSUEKEY>-context.md.

Заборони: Не грумить і не інтерпретує вимоги — тільки збирає дані як є. Не додумує відсутню інформацію. Не використовує нічого крім Atlassian MCP — ні браузер, ні пошук в інтернеті.

2. Requirements Grooming

Мета: Перевірити вимоги очима QA до того, як починається будь-яке тестування — знайти прогалини, протиріччя та неоднозначності.

Що робить: Бере context-файл, нумерує кожну вимогу (REQ-1, REQ-2...), перевіряє кожну через чотири питання тест-дизайну (чи можна перевірити, що потрібно для перевірки, де може зламатися, що не прописано). Виводить проблемні вимоги в чат, узгоджує з користувачем і зберігає фінальний пронумерований список у <ISSUEKEY>-requirements.md.

Заборони: Не переписує вимоги без узгодження з користувачем. Не додає інформацію, якої нема в context-файлі. Не обробляє те, чого не розуміє. Не ходить в Jira.

3. QA Checklist

Мета: Декомпозувати кожну вимогу на атомарні перевірки — що саме потрібно перевірити.

Що робить: Бере requirements-файл і для кожної вимоги будує список перевірок з REQ-ID (REQ-1.1, REQ-1.2...). Кожен пункт — одна атомарна test condition з однозначним pass/fail. Зберігає в <ISSUEKEY>-checklist.md.

Заборони: Не генерує перевірки на поведінку якої нема у вимогах. Не перевіряє деталі реалізації, стандартну поведінку браузера, анімації, таймінги. Не дублює одну перевірку двічі. Не додає перевірки задля перевірок.

4. QA Test Cases

Мета: Описати, як саме перевірити кожен пункт чекліста — конкретні кроки, дані, очікуваний результат.

Що робить: Бере checklist-файл і для кожної поведінкової перевірки генерує тест-кейс (TC-REQ-X.Y) з передумовою, кроками, тестовими даними і очікуваним результатом. Зберігає в <ISSUEKEY>-test-cases.md.

Заборони: Не вигадує очікуваних результатів, яких немає у вимогах. Не генерує тест-кейси на інфраструктуру, перформанс, UX-деталі. Не комбінує кілька незалежних перевірок в одному тест-кейсі. Не додає перевірки задля перевірок.

5. PR Summary

Мета: Побудувати навігацію по PR для скіла код-рев’ю — що і де змінюється у коді.

Що робить: Читає PR через GitHub CLI, для кожного зміненого файлу визначає категорію (компонент, сервіс, модель, конфіг...) і стисло описує, що змінено. Групує файли по сутностях. Зберігає в <ISSUEKEY>-pr-summary.md.

Заборони: Не оцінює якість коду, стиль, архітектуру. Не порівнює зміни з вимогами. Не читає код з main або інших бранчів — тільки з PR бранчі. Не змінює код і не створює PR-коментарів.

6. Code Review

Мета: Перевірити кожен тест-кейс по коду PR і визначити що реалізовано, що ні, а що потребує ручного тестування.

Що робить: Бере test-cases і pr-summary файли, для кожного тест-кейсу знаходить відповідний код у PR через GitHub CLI і виставляє статус: PASS (реалізовано), FAIL (реалізовано неправильно — з доказом і рядком коду), QA (неможливо перевірити по коду, потрібна ручна перевірка), N/A (код цієї вимоги відсутній у PR). Зберігає в <ISSUEKEY>-code-review.md.

Заборони: Не ставить FAIL без конкретного доказу з коду. Не ставить N/A без конкретного доказу. Не оцінює якість коду і архітектуру. Не перевіряє нічого поза тест-кейсами. Не читає код з main або інших бранчів.

7. mpact Analysis (додатковий)

Мета: Зіставити декларацію розробника про вплив змін з реальним дифом PR — знайти регресійні ризики.

Що робить: Читає dev impact файл, перевіряє кожну заявлену залежність по коду PR через GitHub CLI, шукає незадекларовані зміни. Виставляє вердикти: PASS, FAIL, QA.

Заборони: Не працює без dev impact файлу. Не вигадує залежностей, яких немає в коді. Не оцінює бізнес-логіку.

💡 Зверни увагу на патерн. Заборон у кожного скіла більше, ніж дозволів. І це не випадковість — це ключ до якості. Бо AI за замовчуванням хоче бути «корисним» і додавати від себе. А нам треба рівно те, що є — не більше і не менше.

Від тікета до завершеного тесту

Тепер переходимо до цікавого — до запуску пайплайну. Зараз ми з тобою пройдемо кроки тестування задачі. Розберемо кожен степ. Спробую максимально коротко і зрозуміло втілити цю ідею :)

Крок 1: Збираємо контекст

Отже, у нас є задача в Jira. Є опис (навмисно такий собі, імітуємо реалії :) ) — є дані, які ми будемо обробляти далі нашою комбінацією скілів.

Максимально просто, в кількох словах, описую завдання в нашому чаті з агентом. Використоваю в Claude табу Code. Бачимо, що мені одразу видається підказка, яку модель та ефорт треба увімкнути для цього кроку. Далі бачимо, як обробилось наше завдання і згенеровано відповідний файл. У правій половині скріна ти вже бачиш відкритим цей самий згенерований файл.

Залишилося лише перевірити, що опис контексту дорівнює опису з тікета. Перевірили — все на місці.

Крок 2: Грумінг вимог

Шок, перший етап пройшли успішно, крокуємо далі. Запускаємо обробку вимог.

💡Зверни увагу: цей скіл почав обробку не з Jira-тікета, а з контексту, який нам щойно видав попередній скіл. Кожен скіл працює зі своїм вхідним файлом — ніхто не біжить нікуди, окрім вихідного файлу попереднього скіла. Вихідний файл = вхідний.

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

💡 Інсайт: Цей крок критичний для якості. Бо саме тут ми вирішуємо, яка якість у нас буде далі. Пам’ятаєш з попередньої статті? «Garbage in — garbage out». Ось цей скіл і є фільтр від garbage.

Ми відповіли на питання нашому агенту, а він побіг далі, пошурхав шось, і повернув нам файл з пропрацьованими вимогами.

Зараз, звісно ж, наша відповідальна частина — перевірити, що вимоги описані коректно. Пробігли очима, все чітко. Рухаємось далі.

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

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

Так само легко, як і попередні два кроки, запускаємо обробку наступним скілом — генеруємо чекліст.

💡Зверни увагу: можна відстежувати, яку кількість часу і токенів займає проходження кроку. Це можна використати для калькуляції вартості задачі (навіть якщо у вас пакетна підписка в десктопі, яка рахується сесіями).

Щож, наш скіл успішно відпрацював і знову наш вихід. Вмикаємо свого внутрішнього експерта і критично оцінюємо — чи валідний у нас вийшов артефакт, чи піде він на переробку.

Оцінили — результат влаштовує? Переходимо далі.

Крок 4: Тест-кейси

Запускаємо покриття тест-кейсами. Спостерігаємо, як наш скіл успішно сформував нам сьют. Найулюбленіший мій етап — вмикаємо свого внутрішнього душнілу і йдемо на рев’ю кейсів.

Нас влаштовують наші тест-кейси? Тоді ми йдемо далі.

💡Зверни увагу на трейсабіліті. Кожен тест-кейс має ID, який посилається на пункт чекліста, який посилається на вимогу. TC-REQ-2.1 → REQ-2.1 → REQ-2. Це можливість в будь-який момент простежити ланцюг від тест-кейса до оригінальної вимоги з тікета.

Крок 5: PR Summary

Тепер ми перейшли до третьої частини — роботи з кодом. Беремо в нашому тікеті лінку на PR (пул-ріквест), передаємо нашому скілу і легким рухом руці клікаємо запуск обробки PR-самері.

У згенерованому аутпуті ми бачимо таку собі навігаційну карту по нашому PR. Можна подивитися кількість файлів, які змінені, які ні, і так далі. Цей крок необхідний для розвантаження наступного скіла.

Крок 6: Код-рев’ю

Наразі ми запускаємо останній крок нашого ланцюга. Самий відповідальний і об’ємний крок. Проходимо код імплементейшен рев’ю. Наш скіл бере написані вище тест-кейси, бере PR-лінку і йде на тяжку працю — проходить тестування коду.

На скріні ми з тобою бачимо результат проходження код-рев’ю. У нас є позначені результати пройдених тест-кейсів і відповідно покритих вимог. Бачимо, що нам повезло — всі кейси успішно покриті кодом. А це означає, що агент залишив нам дрібницю — перевірити те, що ми вважаємо за потрібне.

А що з Impact Analysis?

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

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

Давай підіб’ємо наші підсумки?

Вийшов не «Top Gear» канешн, але наш «підкапотний» розбір пройшов успішно, вважаю. Ми детально розібрали всі кроки пайплайну (окрім impact analysis) на тестовій задачі з кількома вимогами. На кожному кроці пройшли контроль якості людиною. На виході маємо повний комплект тестових артефактів з наскрізною трейсабіліті від вимоги до рядка коду.

Я впевнена, що тепер стало зрозуміло як воно працює в реальному житті.

І звсіно традиційно, мотиваційна цукерка для настрою 😊