Програма курсу Agentic QA

Огляд курсу

• Цільова аудиторія: Junior і Middle AI / Dev / Test / Ops інженери
• Загальна кількість занять: 21
• Орієнтовна тривалість: 11–14 тижнів

Блок 1. Фундамент

(Заняття 1–2 — базовий рівень, без технічних передумов)

Заняття 1. AI-системи як об’єкт тестування: чому все інакше

Розуміння того, чим тестування LLM відрізняється від традиційного детермінованого ПЗ. Огляд типів систем, які трапляються в проєктах: чат-боти, RAG-системи, агенти і пайплайни. Дослідження режимів відмов через практичну таксономію, а не теорію ML. Як класична піраміда тестування трансформується для AI-застосунків, де eval-тестування стає новим шаром між інтеграційним і E2E.

Практика на занятті: студенти отримують демо-чат-бот і 10 різних промптів; завдання — класифікувати відмови за таксономією і задокументувати їх у форматі «структурований баг-репорт для LLM-системи».

ДЗ: знайти 5 справжніх відмов у будь-якому публічному AI-продукті й задокументувати їх з категоризацією: тип відмови → вхід → фактичний результат → очікуваний результат → severity.

Результат: студенти розуміють специфіку тестування AI-систем, уміють документувати відмови у структурованому форматі й бачать, як піраміда тестування змінюється в AI-контексті.

Заняття 2. Архітектура агентних систем очима QA

Фокус на точках відмови, а не на побудові агентів. Компоненти: LLM-ядро, системний промпт, інструменти, пам’ять, оркестрація, контекстне вікно. Що відбувається під час tool call і де лежать шари ризику. Як перетворити архітектурну діаграму на тест-стратегію.

Практика на занятті: студенти отримують схему реальної агентної системи (RAG-агент із двома tool call) і будують risk map: визначають типи ризиків і мінімум одну тест-ідею на кожен компонент.

ДЗ: намалювати архітектурну діаграму AI-системи зі свого проєкту або вигадану. Дати мінімум 2 тест-ідеї на компонент. Здати: діаграма + таблиця ризиків.

Результат: студенти декомпозують агентні системи на компоненти й будують risk map як основу тест-стратегії.

Блок 2. Тестування LLM

(Заняття 3–9 — середній рівень, потрібен базовий Python або TypeScript)

Заняття 3. Промпт та контекст інжиніринг для QA

Навіщо QA-інженеру розуміти prompt engineering — не щоб писати промпти, а щоб їх тестувати. Анатомія системного промпту: інструкції, персона, обмеження, приклади, формат виводу. Типи промптів: zero-shot, few-shot, chain-of-thought, ReAct, self-consistency — кожен ламається по-своєму. Техніки: role prompting, покрокова декомпозиція, специфікація формату виводу, negative prompting. Контекстне вікно як ресурс і як його розмір впливає на поведінку агента. Context injection і вплив зовнішніх даних на відповіді моделі.

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

ДЗ: провести аудит реального або вигаданого системного промпту: знайти 3+ проблемні місця (неоднозначності, конфлікти, прогалини в інструкціях). Переписати з використанням мінімум двох технік. Здати: оригінал + анотований аудит + покращена версія з поясненнями.

Результат: студенти розуміють типи й техніки промптів, бачать їхній вплив на поведінку моделі й уміють проводити структурований QA-аудит системного промпту.

Заняття 4. Метрики в тестуванні ШІ

Чому pass/fail не працює для LLM-систем. Огляд ключових метрик: faithfulness, answer relevancy, context recall, hallucination rate, groundedness. Різниця між кількісними і якісними метриками і коли яку застосовувати. Підбір метрик під тип системи: чат-боти, RAG, агенти, пайплайни. Baseline-метрики і що таке «хороший» результат. Як метрики змінюються зі зміною моделі, промпту чи даних.

Практика на занятті: студенти інтерпретують результати eval-ранів з кількома метриками, визначають слабкі місця системи і формулюють конкретні гіпотези щодо поведінки метрик.

ДЗ: обрати AI-систему і скласти таблицю: релевантні метрики → обґрунтування → порогові значення прийнятного результату. Здати: таблиця метрик + обґрунтування.

Результат: студенти вміють обирати відповідні метрики для різних AI-систем і розуміють, що вони вимірюють та їхні обмеження.

Заняття 5. Тестування промптів: від ручних перевірок до автоматизації

Чому ручна перевірка промптів не масштабується. Побудова golden dataset: джерела, розмір, баланс кейсів. Критерії вибору між DeepEval і Promptfoo. Написання assertion для недетермінованих відповідей. Версіонування промптів як інженерна практика — чому зміна промпту це реліз. Регресійне тестування для порівняння версії A проти B на однакових даних.

Практика на занятті: студенти запускають готовий eval-suite з 5 тестами в DeepEval, аналізують, які тести «пливуть», і доопрацьовують assertion, щоб прибрати false positives.

ДЗ: взяти реальний або вигаданий промпт. Скласти golden dataset з 10 прикладів input/expected-output. Створити й запустити eval-suite. Здати: код + результати + короткий аналіз знахідок.

Результат: студенти будують golden dataset і запускають eval-suite через DeepEval або Promptfoo замість ручної перевірки.

Заняття 6. Тестування RAG: hallucination, faithfulness, relevancy

Де виникають проблеми RAG-пайплайну: retrieval, augmentation, generation. Метрики RAGAS: faithfulness, answer relevancy, context recall. Знайомство з патерном LLM-as-judge — коли і як його застосовувати. Як відрізнити галюцинацію від неповного контексту. Розбір реального production-кейсу з галюцинацією.

Практика на занятті: студенти розгортають демо-RAG-систему й запускають RAGAS-оцінку на підготовлених питаннях, аналізуючи низькі faithfulness-скори і випадки вигадування.

ДЗ: побудувати мінімальний RAG eval: будь-яка документація → демо-RAG → 10 питань з відомими відповідями → RAGAS. Здати: метрики + висновок щодо слабких місць + одна конкретна рекомендація з покращення.

Результат: студенти розуміють специфіку тестування RAG і вміють вимірювати якість відповідей через метрики RAGAS.

Заняття 7. Тестування багатокрокових діалогів і context management

Де агенти втрачають контекст і чому. Патерни context failure: суперечності між кроками, забуті важливі дані, деградація на довгому діалозі. Програмна симуляція багатокрокових сценаріїв. Ліміти контекстного вікна як джерело багів.

Практика на занятті: студенти проганяють support-агента через 8-кроковий сценарій, знаходять мінімум 2 місця, де контекст втрачається або з’являються суперечності, і пишуть тест-кейси на знайдені проблеми.

ДЗ: написати повний тест-план для багатокрокового сценарію: 3 happy paths, 3 edge cases з context failures, 2 adversarial-сценарії. Для кожного: вхід → очікуваний результат → критерії pass/fail.

Результат: студенти проєктують тест-сценарії багатокрокових діалогів і знаходять context failures на різних етапах.

Заняття 8. Тестування різних моделей і GitHub Models

Моделі — не константа. Однакові системи поводяться по-різному на GPT-4o, Claude Sonnet, Gemini, Llama. Що змінюється: чутливість до temperature, дотримання інструкцій, консистентність виводу, рівень галюцинацій. GitHub Models для порівняльного тестування: швидкий доступ до кількох провайдерів без окремих API-ключів. Стратегія бенчмаркінгу моделей і її автоматизація. Коли і навіщо змінювати модель у production.

Практика на занятті: студенти запускають однаковий eval-suite на двох різних моделях через GitHub Models, порівнюють результати, виявляють істотні відмінності в поведінці й рекомендують, яка модель підходить під use case.

ДЗ: побудувати звіт порівняння моделей: прогнати golden dataset на 3+ моделях, задокументувати метрики, вартість і latency. Здати: порівняльна таблиця + обґрунтована рекомендація.

Результат: студенти порівнюють поведінку моделей через eval-suite і дають обґрунтовані рекомендації щодо вибору моделі.

Заняття 9. Локальні моделі для тестування: Ollama і Lemonade AI Runtime

Чому вартість LLM-as-a-Judge стає проблемною на масштабі CI/CD: «$0.003 за judge-виклик × 500 тестів × 10 PR/день = реальний бюджет». Локальні моделі розв’язують це: нульова вартість за виклик, повна приватність, відсутність rate-лімітів і мережевих залежностей. Огляд Ollama: підтримувані моделі (Llama 3, Mistral, Phi-3, Gemma 2, Qwen). Lemonade AI Runtime як альтернатива з акцентом на Windows і NPU-прискорення. Вибір локальної моделі: розмір RAM, якість суджень і швидкість — компроміси. Де локальних моделей достатньо для judge, а де потрібен cloud.

Стратегія вибору judge:

• Локальна розробка → Ollama + Phi-3 Mini (3.8B) — працює на ноутбуці, відповідь 2–5 сек
• CI на GitHub Actions → Ollama + Llama 3.1 8B у Docker — безкоштовно, без секретів
• Pre-release gate → Claude Haiku або GPT-4o Mini — вища якість суджень
• Регресійні тести (500+) → локальна модель — cloud-витрати неприйнятні

Практика на занятті: інструктор наживо демонструє розгортання Ollama і налаштування Lemonade runtime, під’єднує до DeepEval через custom model wrapper, запускає eval-suite спершу з cloud-моделлю як judge, потім із локальною, порівнює результати й вартість.

ДЗ: розгорнути Ollama локально й інтегрувати як judge в eval-suite. Прогнати тести в трьох конфігураціях: cloud-модель, велика модель Ollama (7B+), мала модель Ollama (3B або менше). Здати: таблиця accuracy/latency/cost + висновок щодо оптимальної конфігурації на кожному етапі пайплайну.

Результат: студенти розгортають локальні моделі через Ollama або Lemonade, інтегрують їх як judge у DeepEval і свідомо обирають між локальним і cloud-judge.

Блок 3. Agentic Testing

(Заняття 10–14 — середній рівень, потрібен досвід роботи з API і базова автоматизація)

Заняття 10. LLM as a Judge: імплементація і підводні камені

LLM-as-a-Judge сьогодні — стандарт в оцінюванні AI. Архітектура: вибір промпту, вибір моделі, формат відповіді. Коли judge надійний, а коли вводить в оману: positional bias, verbosity bias, self-preference. Калібрування judge: валідація людиною, inter-rater agreement, тюнінг промпту. Імплементація через DeepEval і RAGAS. Коли LLM-judge замінює людину, а коли доповнює. Вартість і latency для CI.

Практика на занятті: студенти пишуть власні judge-промпти для відповідей демо-агента, порівнюють з ground truth, знаходять помилки judge і доопрацьовують промпти, щоб зменшити хибні оцінки.

ДЗ: імплементувати LLM-as-a-Judge для власної системи: написати judge-промпт, прогнати на 10 прикладах, вручну провалідувати всі 10, порахувати точність judge. Здати: промпт + результати + аналіз відмов judge.

Результат: студенти імплементують і налаштовують патерн LLM-as-a-Judge і розуміють його обмеження.

Заняття 11. Security testing: Prompt Injection і Red Teaming

OWASP LLM Top 10 як практичний чекліст. Пряма prompt injection: перезапис інструкцій. Непряма injection: атаки через зовнішній контент (документи, сторінки, результати інструментів). Методи jailbreaking і захист. Ексфільтрація даних через агентів. Як системний промпт і context engineering формують поверхню атаки. Методологія red team-сесії: структура, документування, пріоритизація.

Практика на занятті: студенти отримують демо-агента з навмисними вразливостями. Мета: за 30 хвилин знайти мінімум 2 вразливості різних типів з OWASP LLM Top 10 і задокументувати їх у форматі security report.

ДЗ: провести самостійну red team-сесію на публічному AI-продукті або демо. Задокументувати 3+ вразливості: вразливість → вектор атаки → severity → рекомендація з мітигації.

Результат: студенти проводять базові red team-сесії за OWASP LLM Top 10 і документують знахідки у форматі security report.

Заняття 12. Tool call testing і MCP

Основи tool call testing: правильний інструмент, правильні параметри, правильний порядок. Playwright MCP як об’єкт тестування і як інструмент тестування. Програмний перехоплення і перевірка tool call. Типові баги: зайві виклики, пропущені виклики, неправильні параметри.

Практика на занятті: студенти запускають готового агента з Playwright MCP, спостерігають tool call у trace, знаходять один неправильний виклик у підготовленому сценарії й пишуть assertion, щоб ловити його автоматично.

ДЗ: написати автоматизовані тести поведінки tool call — мінімум 5 тест-кейсів: правильний виклик, виклик з неправильними параметрами, пропущений виклик, зайвий виклик, неправильний порядок. Здати: код + результати запуску.

Результат: студенти розуміють специфіку tool call testing і пишуть автоматизовані перевірки поведінки агента під час роботи з інструментами.

Заняття 13. Observability і cost testing

Навіщо QA трасування агента. LangSmith і Phoenix/Arize: що вони показують і як їх читати. Що шукати у trace: аномалії latency, token loops, неочікувані tool call, деградація якості. Cost testing: виявлення дорогих сценаріїв. Метрики production-моніторингу.

Практика на занятті: студенти під’єднують LangSmith до демо-агента й запускають сценарій із навмисним token loop. Завдання: знайти аномалію у trace, визначити хибний крок, порахувати вартість провального сценарію проти нормального.

ДЗ: налаштувати observability для демо-агента. Прогнати 5 сценаріїв, порівнявши latency, токени, вартість, кількість tool call. Знайти найдорожчий сценарій. Здати: скриншоти trace + порівняльна таблиця + рекомендація з оптимізації.

Результат: студенти налаштовують трасування агентних систем і знаходять аномалії поведінки й вартості через observability-інструменти.

Заняття 14. AI-assisted Test Case Generation і Code Review

Використання AI для генерації тест-кейсів — і валідація їхньої якості. Патерни: генерація з вимог, генерація з коду, генерація edge cases з golden dataset. GitHub Copilot і Claude як асистенти тест-дизайну. AI-assisted code review для тестового коду: промптити модель шукати слабкі assertion і неповні тести. Ризики надмірної довіри до AI-згенерованих тестів: false coverage, неявні припущення. Валідація якості згенерованих тестів.

Практика на занятті: студенти просять AI згенерувати тест-кейси для функціональності агента. Завдання: критично оцінити результат — знайти тести, що виглядають правильними, але нічого не перевіряють, і переписати їх.

ДЗ: згенерувати тест-кейси для обраного компонента, використовуючи інтегрованого в пайплайн AI-агента, провести ручний review. Здати: GitHub-репозиторій з оригінальними тестами + коментарі review. Виконання як частина локального agentic workflow.

Результат: студенти використовують AI як інструмент генерації тестів і критично оцінюють якість результату. Налаштовують agentic workflows у середовищі CI/CD.

Блок 4. Автоматизація і фреймворки

(Заняття 15–16 — просунутий рівень, потрібен досвід написання автотестів)

Заняття 15. Побудова фреймворку для автоматизованого тестування ШІ

Чим AI-тест-фреймворки відрізняються від стандартних фреймворків автоматизації. Ключові компоненти: dataset management, eval runner, assertion engine, result storage, reporting. Проєктування фреймворків, що підтримують unit-рівень eval і E2E-тестування агентів. Патерни: LLM response fixtures, golden dataset factories, model wrappers. Версіонування тестів разом із версіонуванням промптів. Портативність фреймворку між провайдерами (OpenAI, Anthropic, локальні моделі).

Практика на занятті: студенти отримують скелет базового фреймворку й доповнюють відсутні компоненти: dataset loader, assertion wrapper, генерація HTML-звіту.

ДЗ: спроєктувати й імплементувати мінімальний AI-тест-фреймворк для обраної системи. Мінімальні вимоги: завантаження датасету, виконання eval, збереження результатів, базовий reporting. Здати: репозиторій + README + приклад запуску.

Результат: студенти будують структуровані AI-тест-фреймворки замість ізольованих скриптів, розуміючи критичні компоненти.

Заняття 16. Eval pipeline у CI/CD: Quality Gates з DeepEval і LLM-as-a-Judge

Чому eval має місце в release-пайплайнах — стандартних unit-test gate недостатньо для AI-систем. Архітектура quality gate: що перевіряти, з якою частотою, що блокує деплой. GitHub Actions + DeepEval: покрокове налаштування з нуля. LLM-as-a-Judge як автоматичний gate без участі людини. Benchmark-пороги: встановлення baseline-метрик і коли їх переглядати. Симуляція регресії від зміни промпту для перевірки ефективності gate. Причини flaky eval і розв’язки: seed, retry logic, threshold bands. Звітування результатів eval у pull request: annotations, summary comments, Slack-сповіщення.

Практика на занятті: студенти клонують готовий репозиторій з базовою конфігурацією GitHub Actions. Завдання: додати два gate — один на метриці DeepEval, один на LLM-judge. Симулювати зміну промпту, що ламає обидва gate.

ДЗ: довести eval-suite до CI/CD-пайплайну з мінімум двома quality gate — один rule-based (метрика DeepEval), один model-based (LLM judge). Здати: репозиторій + скриншот зеленого ранy + скриншот заблокованого ранy (симульована регресія) + пояснення логіки порогів.

Результат: студенти вбудовують eval-based і judge-based quality gate в CI/CD-пайплайни з автоматичним блокуванням деплою при деградації якості.

Блок 5. Системний рівень і Agentic Workflows

(Заняття 17–19 — просунутий рівень, потрібен досвід з CI/CD і DevOps-basics)

Заняття 17. Agentic CI/CD: AI-агенти як частина пайплайну розробки

Agentic workflows відрізняються від eval gate: агенти діють, а не лише перевіряють. Патерни використання: автоматичний code review через GitHub Copilot або Claude Code в PR, автоматична генерація чи оновлення тестів при зміні коду, автоматичне оновлення документації при зміні промпту чи специфікації. Імплементація через GitHub Actions + MCP: надання агентам доступу до репозиторію з контролем можливостей. Claude Code і GitHub Copilot як агенти пайплайну: де кожен сильніший. Валідація якості роботи агента: validation gate після дій агента. Ризики agentic CI/CD: нескінченні цикли, технічний борг від низькоякісної генерації, надмірні дозволи.

Практика на занятті: студенти налаштовують GitHub Actions workflow, де агент (Claude Code або Copilot) автоматично робить code review тестових файлів при відкритті PR і лишає коментарі. Завдання: оцінити якість review на підготовленому PR із навмисними проблемами й оцінити, що агент виявив.

ДЗ: імплементувати agentic workflow на вибір: автоматичний code review тестів у PR або авто-генерація тестів при зміні специфікації. Здати: репозиторій + демо-запуск + аналіз якості результату агента + перелік пропусків/помилок.

Результат: студенти розуміють, де agentic CI/CD дає ROI, а де створює ризики, і імплементують базові версії з валідацією якості.

Заняття 18. Documentation і Test Generation як частина agentic workflow

Як agentic workflows тримають документацію й тести актуальними. Патерн: AI-агент читає PR diff → генерує чи оновлює тест-кейси → пропонує зміни документації. Імплементація GitHub Actions + MCP. Валідація якості авто-згенерованої документації. Де агенти допомагають, а де створюють борг. Реальні приклади впровадження у продуктових командах.

Практика на занятті: студенти налаштовують простий GitHub Actions workflow: при зміні файлів промптів агент автоматично генерує оновлені тест-кейси й відкриває PR з ними.

ДЗ: імплементувати agentic workflow на вибір: автоматичне оновлення документації при зміні промпту або авто-генерація тестів при зміні специфікації. Здати: репозиторій + демо-запуск + аналіз якості результату + перелік помилок агента.

Результат: студенти розуміють, де agentic workflows дають QA-ROI, і імплементують базові версії.

Блок 6. Фінальний проєкт

(Заняття 19–21 — синтез усього курсу)

Заняття 19. Підготовка фінального проєкту: консультації і peer review

Студенти презентують поточний статус проєкту. Peer review: обмін репозиторіями й структурований зворотний зв’язок за чеклістом. Інструктор розбирає типові помилки й відповідає на питання.

Заняття 20–21. Захист фінального проєкту

Кожен студент: 10 хвилин демо живого пайплайну + 5 хвилин Q&A. Фокус питань: «Чому саме цей поріг у quality gate», «Де ламається твій judge», «Що б ти змінив, маючи ще тиждень», «Яке рішення ухвалив асистент і чи згоден ти з ним».

Фінальний проєкт: AI-Powered Application — повний цикл

Студенти самостійно розробляють AI-додаток, покривають його тестами, налаштовують повний CI/CD-пайплайн і документують стратегію якості. Мета: продемонструвати самостійну побудову production-процесу навколо AI-системи — від першого коміту до автоматичного релізу, а не лише володіння інструментами.

Що розробити

1. AI-додаток (з допомогою код-асистента)

Студенти будують мінімальний, але реальний AI-додаток — чат-бот, RAG-агент, агент з інструментами або пайплайн — використовуючи GitHub Copilot, Claude Code чи аналог. Вимоги: кілька компонентів і нетривіальна логіка. Обсяг: 300–800 рядків основної логіки. Задокументувати рішення студента проти рішень асистента і помилки асистента.

2. Тест-стратегія

Структурований документ: опис системи й ризиків, вибір рівнів тестування (unit / integration / eval / E2E / security), обґрунтування пріоритетів, підхід на кожному рівні, вибір інструментів і обґрунтування, критерії go/no-go для релізу. Обсяг: 2–4 сторінки.

3. Risk-Based Test Coverage Matrix

Перелік компонентів, оцінка ризику на компонент (impact × likelihood), мапінг покриття тест-кейсами, прогалини — де покриття відсутнє і чому це прийнятно або проблемно. Формат: анотована таблиця.

4. Тести — усі рівні

5. Системний тест-фреймворк з LLM-as-a-Judge

Окремий модуль репозиторію: dataset loader, eval runner, judge integration, result storage, HTML/Markdown reporting. Фреймворк дозволяє повний eval системи однією командою зі звітами метрик і judge-score. Спроєктований для повторного застосування до інших систем (зміна лише датасету й конфігу).

6. CI/CD-пайплайн на GitHub Actions

Повний пайплайн на PR і push у main:

• Eval-suite з quality gate (DeepEval + judge) — блокує merge при відмові
• AI code review-агент (Claude Code або Copilot) — коментарі в PR
• Security-перевірки
• Автоматичний реліз на push у main: build → test → deploy (GitHub Pages, Railway, Fly.io тощо) → smoke test після деплою

7. Документація

README з інструкціями запуску. Опис архітектури. Документація використання AI-асистента в розробці й тестуванні — чесно: що допомогло, що заважало, що довелося переробляти вручну.

Цільова аудиторія

Сегмент 1: QA Engineer Middle+ (основний сегмент)

Профіль: 2–5 років досвіду в тестуванні, вже використовує AI-інструменти для генерації тестів, але не розуміє, як тестувати самі AI-системи. Працює в продуктовій компанії або відчуває тиск переходу на AI-стек. JTBD: «Наш продукт перейшов на LLM. Я не розумію, як тестувати це по-нормальному — і боюся стати нерелевантним. Хочу конкретні інструменти й підходи, щоб упевнено говорити про якість AI-системи з командою вже наступного тижня».

Сегмент 2: Automation QA / SDET Middle+ (технічний сегмент)

Профіль: пише автотести, Python або JS на рівні написання скриптів, розуміє CI/CD. Хоче автоматизувати тестування AI-систем як традиційне ПЗ. JTBD: «Я добре автоматизую традиційне QA. Тепер команди будують агентів і просять „якось це протестувати”. Хочу конкретний технічний стек — фреймворки, інструменти, підходи — щоб робити це правильно».

Сегмент 3: Tech Lead / QA Lead (стратегічний сегмент)

Профіль: відповідає за загальну якість продукту. Команда вже будує або планує LLM-фічі. Розуміє загальну картину, але не має структурованого AI QA-фреймворку. JTBD: «Ми запускаємо AI-фічі, але я не розумію забезпечення якості. Боюся production-інцидентів і не знаю, що питати, щоб перевірити тестування. Хочу структуру й упевненість».