Технічний контекст з коду: карта систем та інтеграцій

1. Про заняття

Цей розділ — про початок шостого заняття: що в ньому нового порівняно з С1–С5, що буде за дві години і в якому порядку, що знадобиться, щоб повторити все самостійно. Розбір завдання С5 був лише на занятті — у слайдах і в конспекті його немає.

#Як влаштована система — з коду, без програмування

Слайд 228

С6 — шосте з дев'яти занять курсу «AI-агенти в роботі QA та BA». Воно відбулося в середу, 28.10.2026, і тривало дві години. Це останнє спільне заняття: далі йдуть заняття окремих груп — QA і BA.

У С1–С5 правдою були документи: вимога, датоване рішення, специфікація. У реальних системах документації часто немає або вона застаріла, а система працює. Тоді правда — у коді. Сьогодні агент читає код замість вас і перекладає його мовою аналітика й тестувальника: що робить система, як її частини обмінюються даними, які правила в ній зашиті. Він же відновлює вимоги, будує карту інтеграцій і діаграми — діаграми теж текстом, у Mermaid. Ви код не пишете: ставите питання, вимагаєте джерело і перевіряєте відповіді. Наприкінці заняття — видача фінального проєкту.

Строки й дати:

• Завдання С6 — для QA до вівторка, 03.11.2026, для BA до вівторка, 10.11.2026; обидва строки — о 23:59.
• Розбір С6 — на першому занятті вашої групи: QA1 — у середу, 04.11, BA1 — у середу, 11.11. Тому й строки різні.
• Фінальний проєкт видано на цьому занятті, подання — до понеділка, 14.12.2026, 23:59. Подробиці — у розділі 6.

Що нового в С6:

• Новий проєкт — gitlab.com/koldovsky/ai-qa-ba-c6. Форки С1–С5 не підходять, потрібен новий форк.
• Вхід — код, а не документи. Демо-система «Пакунок» — два невеликі сервіси на Node.js: сервіс посилок і сервіс сповіщень. Документації до них немає навмисно, як у багатьох старих системах. Сервіс вигаданий, будь-який збіг із реальними сервісами випадковий.
• Система одна для всіх. Варіант той самий, що в С1–С5, але тепер він задає фокус-питання — конкретне питання про поведінку системи, яке ви простежуєте кроками через обидва сервіси (обов'язковий розділ L1), — і модуль для L2 BA.
• Агента запускаєте в корені копії — у теці ai-qa-ba-c6/, де лежать system/ і submissions/, а не у своїй теці submissions/ваш-username/, як у С5: агенту потрібна тека system/. Тому межі — що читати і куди писати — пишете в кожному промпті.
• Рівні за роллю. L1 — для всіх. L2 і L3 — окремі для BA і для QA.
• MCP не потрібен. Node.js потрібен лише тим, хто захоче запустити систему: BA систему лише читають, QA в С6 — за бажанням, на занятті QA2 запуск знадобиться.
• Тема фінального проєкту — частина L1 цього завдання.
• Бали — як у С3–С5: до 10 за кожен рівень, за частинами.

Заняття вчить чотирьох речей:

1. Пояснювати систему з коду мовою аналітика. Код — це AS-IS: що система робить зараз. Біля кожного твердження — файл і функція, а кілька тверджень ви перевіряєте самі.
2. Будувати карту інтеграцій. Де стики між сервісами, що через них іде, що буває при помилці. Діаграми — текстом, у Mermaid; потік даних — на прикладі одного поля.
3. Відновлювати вимоги без документації. AS-IS — з коду, TO-BE — рішення власника; магічне число — питання, а не правило. Для QA — сценарії на стиках і контракт стику як вхід для API-тестів.
4. Почати фінальний проєкт: обрати роль і тему.

#План: від розбору С5 до фінального проєкту

Слайд 229

Після розбору С5 — три тематичні блоки, у кожному — демо. Потім — завдання С6, видача фінального проєкту і підсумок: що далі.

Три демо йдуть ланцюжком на тій самій демо-системі «Пакунок»:

• Демо 1 — загальне пояснення інтеграції: як насправді працює зв'язок між сервісом посилок і сервісом сповіщень. І вибіркова перевірка тверджень агента в коді.
• Демо 2 — карта інтеграцій з коду, діаграми Mermaid і data mapping одного поля — імені отримувача.
• Демо 3 — два прогони. BA відновлює вимоги модуля переадресації (redirect.js): AS-IS → TO-BE. QA готує контракт запиту за даними отримувача GET /internal/parcels/{id}/recipient — вхід для API-тестів.

Демо 1 і демо 2 — це метод L1 на тій самій системі: у завданні ви робите те саме, але повністю і з фокус-питанням свого варіанту. Готові об'єкти демо — не ваші: модуль переадресації — демо, а L2 BA — модуль вашого варіанту; контракт запиту за даними отримувача — демо, а L3 QA — webhook POST /v1/events; data mapping лише імені отримувача — демо, а в L3 BA потрібні всі поля обох стиків. Фокус-питання варіантів жодне демо не розбирає.

Результатів прогонів демо в конспекті немає: система та сама, що у вашому завданні, і демо показує метод, а не відповіді.

Що знадобиться, щоб повторити заняття самостійно:

• Репозиторій практики gitlab.com/koldovsky/ai-qa-ba-c6. README — завдання, таблиця варіантів з фокус-питаннями і модулями L2 BA, рівні, бали, здача. system/ — демо-система, її лише читають. system/HOW-TO-RUN.md — як запустити систему, якщо захочете. templates/ — шаблони звіту, пояснення системи, карти інтеграцій, вимог модуля, реєстру сценаріїв, потоків даних і каркас OpenAPI.
• Фінальний проєкт — gitlab.com/koldovsky/ai-qa-ba-final: умови, рубрика, каталоги тем і посилання на шаблони QA і BA.
• Шпаргалка — промпти, команди і перевірки на одній сторінці.
• Агент — Claude Code зі вступного пакета; інший агент чи чат у браузері теж підійде.
• Акаунт на gitlab.com — той самий, що в С1–С5, і Git для клону (без Git — ZIP-архів).
• VS Code чи інший редактор із пошуком по теці — щоб самим перевіряти твердження агента (розділ 2); без нього — пошук у файлі на gitlab.com.
• Переглядач Mermaid — перегляд файлу на gitlab.com, VS Code з розширенням для Mermaid або інший.
• Node.js 20 або новіший — лише для запуску системи.

#Розбір С5 — у звіті перевірки

Слайд 230

Заняття почалося з розбору завдання С5 зі звіту перевірки: що вийшло добре, типові помилки змісту і здачі, найкращі роботи, бали за рівнями. У конспекті розбору немає.

Відгук до вашої роботи — коментар у вашому MR. Не згодні — напишіть коментар там само.

Схема балів у С6 та сама, що в С3–С5: кожен рівень — до 10 балів за частинами, за формальності — до −2 за роботу. Нове — окремі строки для QA і BA і окремі L2 і L3 для кожної ролі. Подробиці — у розділі 5.

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

Свої правила С5 можна використати й у С6 — за бажанням, без балів: вставте їх першим повідомленням сесії або запишіть в особистий файл правил агента, наприклад ~/.claude/CLAUDE.md для Claude Code. Файл правил у корені копії проєкту С6 не створюйте і не комітьте. Якщо у ваших правилах є межа «пиши лише в results/», перевірте її: тут ваша тека — submissions/ваш-username/results/.

2. Від коду до знань

Цей розділ — про те, як отримати знання про систему, коли документації немає, а є лише код. Ви побачите, чому код — це AS-IS, а не намір; у якому порядку агент має читати незнайомий код; як перекладати терміни коду мовою аналітика; з яких розділів складається пояснення системи; де агент помиляється і як перевірити його без програмування.

Наприкінці — демо 1: агент пояснює інтеграцію двох сервісів «Пакунка», а ми вибірково перевіряємо його твердження в коді. У завданні С6 це L1 — пояснення системи з коду і перевірка тверджень.

#Від коду до знань: система мовою аналітика

Слайд 231

У С1–С5 правдою були документи: вимога, датоване рішення, специфікація. У реальних системах документації часто немає або вона застаріла, а система працює і щодня щось робить з даними. Знання про те, що саме, — у коді.

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

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

У цьому розділі шість тем:

1. Де чинна правда, коли документації немає.
2. Як агент читає незнайомий код — і як попросити, щоб це було дешево й точно.
3. Словник «код → мова аналітика».
4. Пояснення — документ, а не переказ коду.
5. Де агент помиляється і як це перевірити.
6. Демо 1.

#Код — це AS-IS, а не намір

Слайд 232

Про будь-яку систему є три джерела знань. Кожне каже своє, і в кожного свої сильні і слабкі сторони.

• Документ — намір. Він пояснює, навіщо щось зроблено, але застаріває і буває неповним, а часто його просто немає. У С3 ви вже бачили, що навіть серед документів чинним є датоване рішення, а не сторінка з найсвіжішою датою.
• Код — AS-IS, тобто що система робить зараз. Це єдине джерело, яке точно виконується. Але в коду дві слабкості. Він не каже «навіщо». І дефект у коді виглядає так само, як правило: умова з числом не підписана «це вимога» чи «це помилка».
• Власник — як має бути. Агент може знайти поведінку, ви — сформулювати її мовою бізнесу. А вирішити, правило це чи дефект, може лише власник продукту. Це те саме питання «Ухвалити рішення: …» з адресатом, що в С3–С5.

Звідси формат для всього завдання С6. Кожне твердження про систему має одну з трьох позначок:

Чесно позначене припущення — не мінус. Помилка — це припущення, подане як факт.

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

#Незнайомий код: від входу — за викликами

Слайд 233

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

1. Дерево тек — які сервіси й модулі є. У «Пакунку» два сервіси, у кожного своя тека.
2. Точки входу — маршрути в server.js. Кожен маршрут — це метод і шлях запиту, наприклад GET /orders/{id} — «покажи замовлення» (приклад вигаданий), тобто те, що систему можна попросити зробити. Звідси починається будь-яка поведінка.
3. Виклики — від маршруту до функцій, які він викликає, і далі. Так видно, що справді виконується, а що просто лежить у файлі.
4. Конфіг — config.json: адреси інших сервісів, перемикачі, числа. Вони змінюють поведінку без зміни коду.
5. Дані — seed/, початкові дані: як виглядає типовий запис. Знадобляться для прикладів і тестових даних.

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

На слайді — дві картки «як просити».

Так дорого:

Прочитай увесь system/ і поясни, як усе працює.

Агент читає все підряд — і те, що ніхто не викликає. Кожен прочитаний файл ви оплачуєте на кожному наступному кроці.

Так:

Почни з server.js обох сервісів, далі — за викликами. Використовуй тільки system/.

Агент читає те, що справді виконується. Межа «тільки system/» — щоб він не взяв чужі роботи за джерело.

«Прочитай усе» — дорого і не точніше. Прочитаний файл лишається в контексті й оплачується на кожному наступному кроці — це ви бачили в С1 і С5. До того ж агент читає й код, який ніхто не викликає, і може описати його як робочу функцію. «Почни з server.js, далі за викликами» — той самий порядок, що в п'яти кроках вище, лише записаний у промпт.

Межа читання обов'язкова. У завданні агента запускаєте в корені своєї копії, а після злиття MR нові форки — і копії, оновлені з оригіналу, — містять чужі роботи в submissions/. Скопійований результат не зараховується, тож агент не має їх навіть відкривати. На демо межа — «тільки system/»; у завданні вона ширша на одну теку, вашу: «Використовуй лише system/ і submissions/ваш-username/». Без своєї теки в межі агент не прочитає шаблон, скопійований туди, і не матиме куди записати результат. Повний рядок межі — у розділі 5.

Масштаб на слайді: у system/services 17 файлів, близько 1000 рядків. Це невелика система. Робоча буває в десятки разів більшою, і там вузький запит — єдиний спосіб. У Claude Code команда /context показує, скільки вже в контексті. У токен-звіті L1 потрібні цифри або оцінка: скільки файлів коду прочитав агент і скільки уточнень знадобилося.

Лише чат у браузері: додайте код у розмову файлами-вкладеннями або текстом, кожен файл — під заголовком зі шляхом. Почніть з server.js обох сервісів і додавайте інші, коли агент про них питає, — так дешевше. Подробиці — у розділі 5.

#Словник: код → мова аналітика

Слайд 234

Агент думає термінами коду. Ваша мета — домогтися, щоб пояснення було мовою аналітика, а за кожним терміном стояло питання, яке ставить BA чи QA.

Кілька уточнень до рядків:

• Webhook — це «він повідомляє», а не «його питають»: сервіс сам надсилає іншому подію, коли щось сталося.
• Backoff — паузи між повторними спробами, які щоразу довшають. Головне питання — що відбувається після останньої спроби.
• Feature flag — код є, але працює лише тоді, коли перемикач увімкнено. Тому питання не «чи є функція», а «чи вона зараз працює».
• Dead code — функція є у файлі, але її ніхто не викликає. Вона нічого не робить, хоч би що в ній було написано.

Права колонка — це вже половина вашої роботи. Питання з неї стають рядками розділу «Неочевидне» в поясненні L1 і відкритими питаннями з адресатом у L2.

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

#Пояснення з коду — документ, а не переказ

Слайд 235

Пояснення системи — не переказ коду файл за файлом, а документ для людини, яка код не читатиме: власника продукту, нового аналітика, тестувальника. Розділи на слайді — ті самі, що в L1 і в шаблоні templates/explanation.md проєкту С6, лише без фокус-питання:

1. Сервіси — що робить кожен, 2–3 речення.
2. Сутності й статуси — мовою бізнесу, а не назвами змінних.
3. Точки входу — навіщо кожна і хто її викликає.
4. Основний сценарій — кроками через обидва сервіси: хто кого викликає, які дані передає.
5. Правила з коду — кожне з джерелом. У завданні — щонайменше 5.
6. «Неочевидне» — те, чого не видно з назв: магічні числа (числа в коді без пояснення, звідки вони взялися), коментарі, що суперечать коду, код, який ніхто не викликає, вимкнені перемикачі функцій.
7. Перевірка — щонайменше три твердження ви звіряєте з кодом самостійно.

У шаблоні між «Неочевидним» і «Перевіркою» є ще розділ 7 «Фокус-питання варіанту NN» — відповідь на питання вашого варіанту, тож «Перевірка» там — розділ 8. Про фокус-питання — у розділі 5.

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

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

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

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

#Де агент помиляється — і як перевірити

Слайд 236

Агент читає код швидше за нас, але помиляється передбачувано. Чотири типові помилки:

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

Як перевірити одне твердження без програмування — за хвилину-дві:

1. Біля твердження є файл і функція? Немає — твердження вже під питанням.
2. Відкрийте файл і знайдіть місце. VS Code: Ctrl+P → назва файлу, Ctrl+F → назва функції чи число (на macOS — Cmd замість Ctrl).
3. Хто викликає функцію? VS Code: Ctrl+Shift+F (на macOS — Cmd+Shift+F) — пошук за назвою функції в теці system/: розкрийте параметри пошуку кнопкою «…» і в полі «files to include» впишіть system/, інакше пошук зачепить і чужі роботи в submissions/. Знайшлося лише оголошення — місце, де функцію описано, — і жодного виклику: функцію ніхто не викликає, і вона не працює, хоч би що було в ній написано.
4. Попросіть агента: «Покажи рядки коду, з яких це видно». Цитату теж звірте з файлом — агент може помилитися й тут.

Окремо — про коментарі: коментар над кодом — не доказ. Порівнюйте, що каже коментар і що робить код під ним.

Без VS Code: відкрийте файл у своїй копії на gitlab.com і шукайте в ньому Ctrl+F (на macOS — Cmd+F). Для «хто це викликає?» попросіть агента знайти в system/ усі місця, де згадується потрібна назва, — файл і рядок, — і один зі збігів відкрийте самі.

Результат перевірки — таблиця в L1: твердження → що в коді → підтвердилось / ні → що виправили. Твердження, яке не підтвердилось і яке ви виправили, — найцінніший рядок цієї таблиці, а не провал.

#Демо 1: як насправді працює ця інтеграція

Слайд 237

Мета демо — показати метод L1: як попросити пояснення з коду і на що дивитися в результаті. Демо 1 — це перша частина L1, пояснення системи, але без фокус-питання варіанту: метод, а не готова відповідь.

Підготовка. Тека демо — клон публічного проєкту ai-qa-ba-c6. Агента запущено в корені клону, як у вас у завданні; результати — у теці submissions/<username>/results/. Агент — Claude Code, модель Sonnet; auto memory вимкнено в /memory, зайві плагіни й MCP вимкнено. Агенту дозволено лише читати system/ і писати у свою теку результатів; на запити прочитати чужі теки чи змінити код — відмова.

Промпт демо 1 — усе з попередніх підрозділів разом:

Ти — аналітик і тестувальник, які вперше бачать цю систему. Документації немає, є лише код у system/. Використовуй тільки system/; інших тек (submissions/ інших людей, examples/) не читай.
Питання: як насправді працює інтеграція між сервісом посилок (system/services/parcels) і сервісом сповіщень (system/services/notifications)? Що відбувається від зміни статусу посилки до повідомлення отримувачу?
Поясни мовою аналітика, без коду і без жаргону:
1) що робить кожен сервіс — 2–3 речення;
2) крок за кроком від зміни статусу до повідомлення: хто кого викликає і які дані передає;
3) що буває, коли щось іде не так: сервіс недоступний, та сама подія вдруге, немає даних отримувача;
4) «Неочевидне»: правила, яких не видно з назв, магічні числа, коментарі, що суперечать коду, код, який ніхто не викликає.
Біля кожного твердження — джерело: файл і функція. Що не підтверджено кодом — познач «припущення».
Збережи в submissions/koldovsky/results/demo1-how-it-works.md. Код не змінюй.

Повторюєте демо у своїй копії — замініть submissions/koldovsky/ на submissions/ваш-username/ (ваш username на gitlab.com), інакше агент запише файл у чужу теку.

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

Кроки демо:

1. Запуск і порядок читання. Поки агент працює, дивимося, що він відкриває першим: server.js (точки входу) → виклики → config.json. Це той самий порядок, який варто просити явно, щоб не платити за читання всього.
2. Результат. Відкриваємо demo1-how-it-works.md і ставимо до нього чотири питання з таблиці нижче — не до всього файлу, а до кількох тверджень.
3. Поки не віримо. Чи правильно — з'ясовуємо перевіркою в коді, у наступному підрозділі.

На що дивимося в результаті — картки праворуч на слайді:

Якщо агент просить прочитати чужі теки в submissions/ чи examples/ — відхиляйте: це межа з промпту, так само в завданні. Пропонує щось змінити в system/ — теж відхиляйте: код не змінюємо.

У завданні метод той самий, але питання ширше: усі розділи пояснення, щонайменше 5 правил і окремим повідомленням — фокус-питання вашого варіанту. Шлях — ваш: submissions/ваш-username/results/l1-explanation.md. Приклад промпту з README завдання:

Ти — аналітик, який уперше бачить цю систему. Документації немає, є лише код у system/.
Використовуй лише system/ і submissions/ваш-username/. Інших тек submissions/ і examples/ не читай. Код не змінюй.
Почни з system/services/*/server.js, далі читай лише те, що вони викликають, і config.json.
Поясни мовою аналітика, без коду: що робить кожен сервіс; сутності й статуси; ендпоінти — призначення і хто викликає;
основний сценарій від зміни статусу посилки до повідомлення отримувачу кроками; щонайменше 5 правил; «Неочевидне».
Біля кожного твердження — файл і функція. Що не підтверджено кодом — познач «припущення».
Збережи в submissions/ваш-username/results/l1-explanation.md.

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

#«Покажи рядок»: перевіряємо агента

Слайд 238

Головний момент демо 1 — вибіркова перевірка. Саме для неї в L1 є таблиця перевірки. Два кроки: один з агентом, другий — без нього.

1. Друге повідомлення — у тій самій сесії. Конкретне питання про число, прохання показати рядки коду і порівняти коментар із кодом. Текст зі слайда:

Скільки разів сервіс посилок намагається доставити подію? Покажи рядки коду, з яких це видно, і поясни, чому коментар над функцією каже інше.

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

2. VS Code, без агента: хто викликає? Ctrl+Shift+F (на macOS — Cmd+Shift+F) по теці system/ за назвою функції, яку агент описав як робочу. Скільки збігів? Якщо знайшлося лише оголошення, а інші файли функцію не підключають (немає імпорту) і не викликають, — її ніхто не викликає. Така перевірка займає півхвилини і не залежить від того, що каже агент.

Що робити з тим, що знайшли, — картки праворуч на слайді:

Якщо агент наполягає на своєму — не сперечайтеся в чаті. Відкрийте рядок самі і запишіть цей випадок у таблицю перевірки: це якраз той рядок, заради якого таблиця існує. Пропонує щось змінити в system/ — відхиляйте: систему не змінюємо ні на демо, ні в завданні.

Файл пояснення з демо 1 — вхід для демо 2: з нього будуємо карту інтеграцій. Найцікавіше в системі живе на стиках між сервісами — про це розділ 3.

3. Інтеграції: стики, карта, потоки даних

У розділі 2 агент пояснив з коду один сценарій — від зміни статусу посилки до повідомлення. Але демо-система «Пакунок» — це два сервіси, і найцікавіше відбувається між ними. Цей розділ — про місця, де одна система передає дані іншій: як їх упізнати в коді і що на них перевіряти, як описати їх у карті інтеграцій, як простежити шлях одного поля і як намалювати все це діаграмою, яку можна звірити з кодом.

Наприкінці — демо 2: карта інтеграцій «Пакунка» з коду і звірка однієї стрілки з кодом.

Де ці теми в завданні С6:

#Дефекти живуть на стиках

Слайд 239

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

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

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

Розділ іде в тому самому порядку, що й слайди:

1. п'ять типів інтеграцій і як їх упізнати в коді;
2. що перевіряти на будь-якому стику — 11 питань;
3. карта інтеграцій — таблиця стиків і діаграма;
4. потік даних і data mapping — шлях одного поля;
5. Mermaid — діаграма, записана текстом;
6. демо 2 — усе це з коду «Пакунка».

#П'ять способів зв'язати системи — і як їх упізнати в коді

Слайд 240

Коли агент каже «тут інтеграція», корисно знати, якого вона типу. Від типу залежить, що шукати в коді і що на такому стику ламається найчастіше.

Терміни, які знадобляться далі:

• синхронний обмін — відправник чекає відповіді, і поки не дочекався, далі не йде; асинхронний — не чекає: поклав повідомлення чи надіслав подію і працює далі;
• webhook — HTTP-запит, яким сервіс сам повідомляє іншому про подію. Це рядок зі словника з розділу 2 (слайд 234): «він повідомляє», а не «його питають»;
• автентифікація — як приймач переконується, хто до нього звертається; підпис — один зі способів: відправник обчислює з даних запиту і секрету, відомого обом сторонам, контрольний рядок і додає його до запиту, а приймач обчислює так само і порівнює. Не збіглося — запит підроблено або змінено дорогою.

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

Файловий обмін і спільна база в коді найменш помітні: немає ні запиту, ні адреси, лише запис і читання. Тому, коли просите агента знайти стики, називайте всі п'ять типів, а не лише «запити між сервісами».

Повний перелік того, що перевіряти, — у наступному підрозділі (слайд 241). А почати варто з простішого: знайти самі стики.

#Що перевіряти на стику — 11 питань до коду

Слайд 241

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

Пункти 1–4 — про самі дані: що передають і в якому вигляді. Пункти 5–8 — про обмін: як кожна сторона реагує на відповідь і помилку, на повтор і на довге очікування. Пункти 9–11 — про те, чого не видно ззовні: збій без сліду, гілку, вимкнену в налаштуваннях, і дані, які живуть лише до перезапуску.

Кілька пунктів, які легко зрозуміти неточно:

• Контракт. Поле, яке одна сторона передає, а інша ніде не читає, — теж знахідка: або воно зайве, або хтось забув його використати.
• Статуси і коди відповідей — два різні питання. Статуси — стани сутності, наприклад «оплачено» чи «відправлено» у вигаданому магазині: чи має кожен статус однієї сторони відповідник на іншій. Коди відповідей — HTTP-коди, якими відповідає приймач: для кожного коду, який він може повернути, знайдіть у коді, що з ним робить відправник, — з файлом і функцією. Правило це чи дефект, вирішує власник.
• Ідемпотентність — у словнику розділу 2 «захист від дублів». Тут дві сторони одного питання: чи впізнає приймач повтор тієї самої події — і чи не прийме він за дубль нову, справжню подію.
• Тихі збої — найнебезпечніші, бо про них ніхто не дізнається: сервіс відповів «усе добре», а повідомлення не пішло.
• Прапорці функцій (feature flags; у словнику розділу 2 — «перемикач функції в налаштуваннях»). Якщо функцію вимкнено в конфігу, її код не працює, хоч би що в ньому було написано. Тому просіть агента читати не лише код, а й конфігураційні файли.

Як питати агента — зелена картка на слайді: один стик, пункт за пунктом; біля кожної відповіді — файл і функція; чого в коді немає — так і писати: «у коді не визначено». Це те саме «не вигадуй» з С2, тепер для коду. Наприклад:

Візьми один стик: <хто → кого, спосіб, ендпоінт>. Пройди його за 11 пунктами по черзі: контракт; автентифікація і підпис; формати даних; часові пояси; статуси і коди відповідей; повтори і затримки; ідемпотентність; таймаути; тихі збої; прапорці функцій; стан у пам'яті.
Для кожного пункту — що робить код на обох сторонах стику, з файлом і функцією. Чого в коді немає — пиши «у коді не визначено».
Використовуй лише system/ і submissions/ваш-username/. Інших тек submissions/ і examples/ не читай. Код не змінюй.

Для ролей — рядок унизу слайда:

• QA: на цих пунктах тримаються типи дефектів на стиках. У README і в розділі 4 їх згруповано в 9 типів: наприклад, «таймаути і тихі збої» — один тип, а «зіставлення статусів» — окремий. У L2 QA потрібно щонайменше 5 типів, кожен — з місцем у коді (файл · функція) і номерами сценаріїв з реєстру. На занятті QA2 сценарії з реєстру стануть API-тестами.
• BA: поведінка на стику, схожа на дефект, — питання власнику, а не висновок. Як його сформулювати — у розділі 4.

Подивіться на фокус-питання свого варіанту в README: воно майже напевно торкається одного з цих пунктів. Відповідь шукаєте самі — у коді.

#Карта інтеграцій — таблиця стиків і діаграма

Слайд 242

Карта інтеграцій складається з двох частин. Таблиця стиків — щоб перевіряти: у кожному рядку джерело, кожну клітинку можна звірити з кодом. Діаграма — щоб побачити систему одним поглядом.

Колонки таблиці — ті самі, що в шаблоні L1 integration-map.md і в промпті демо 2:

Пояснення до колонок:

• Хто → кого — хто ініціює виклик. Не «кому потрібні дані», а хто робить запит.
• Автентифікація чи підпис. «Немає» — теж відповідь: її треба записати, а не залишити клітинку порожньою.
• Що при помилці — з обох боків: що робить той, хто викликав (повторює, припиняє спроби, мовчить), що відповідає той, кого викликали, і чи дізнається про збій людина. Шаблон радить дивитися на це в коді, а не в коментарях.
• Джерело — файл і функція на обох сторонах стику: де виклик і де його обробляють. Якщо друга сторона поза кодом, джерело дає та сторона, яка в коді є; так і в шаблоні: «з обох сторін стику, якщо сторін дві».

Нижче — текст діаграми зі слайда 242: ілюстрація з вигаданої оплати, не з демо-системи. На цій сторінці його показано як текст; щоб побачити малюнок, відкрийте слайд або будь-який переглядач Mermaid — список у підрозділі «Діаграма — це текст: Mermaid»:

flowchart LR
    A["Застосунок"] -->|"REST: сума"| O["Оплата"]
    O -->|"webhook: оплачено"| S["Магазин"]

Два правила діаграми — картки праворуч на слайді:

• Стрілка = виклик. Вона йде від того, хто робить запит. Відповідь повертається тим самим стиком, окрема стрілка для неї не потрібна. У прикладі «Оплата» сама повідомляє «Магазин» про оплату, тому стрілка — від «Оплати». Якби магазин сам питав, чи пройшла оплата, стрілка йшла б від «Магазину», хоча дані ті самі. Найчастіша помилка карти — стрілка туди, куди «течуть дані», а не від того, хто викликає.
• Один стик — один рядок таблиці й одна стрілка. Подія туди і запит назад — два стики, навіть між тими самими сервісами. І на карті не лише сервіси, а й сховища (бази даних, файли) і зовнішні провайдери (SMS, оплата, пошта).

У шаблоні L1 чотири розділи: «Учасники» (сервіс, сховище, зовнішній провайдер, людина — і де видно в коді), «Стики», «Діаграма» і «Що перевірили проти коду». У таблиці стиків шаблону три порожні рядки, але це лише заготовка: записуєте стільки стиків, скільки знайдете.

#Потік даних і data mapping — шлях одного поля

Слайд 243

Карта показує, де стики. Потік даних — що через них іде: від джерела, через сховища й перетворення, до споживача. Data mapping — те саме для одного поля, крок за кроком. П'ять кроків шляху поля — ті самі, що в пункті 4 промпту демо 2:

1. Де з'являється — поле ввела людина, воно є в seed (початкових даних) або прийшло з іншого сервісу.
2. Як зберігається — де і в якому форматі: база, файл, пам'ять.
3. Як передається — через який стик і під якою назвою поля. У джерелі назва одна, на стику може бути інша.
4. Як перетворюється — обрізали, нормалізували, перевели в інші одиниці, замінили код текстом.
5. Де використовується — текст повідомлення, вибір каналу, рішення, звіт.

Приклад — сума до сплати, теж з вигаданої оплати:

Як це читати. Людина бачить у застосунку 85,50 грн. У замовленні суму зберігають у копійках цілим числом, щоб копійки не губилися під час округлення. В API оплати йде amount: 8550. Чек ділить на 100 і показує 85.5. Що може піти не так: хтось забув поділити на 100 — і в SMS «8550 грн»; крапка замість коми і загублений нуль; валюту не передали. У справжньому data mapping біля кожного кроку — джерело: файл і функція.

Для завдання. У L3 BA потік даних усієї системи малюють як DFD — діаграму потоків даних: джерела, сховища, перетворення, споживачі. Шаблон L3 BA — data-flows.md. Сховище в Mermaid позначають циліндром — у шаблоні це D1[("Сховище")]. Перші два розділи шаблону:

• карта потоків даних — три потоки з README: подія про статус (webhook), дані отримувача (запит за даними), повідомлення (провайдер);
• data mapping усіх полів обох стиків між сервісами — події про статус і запиту за даними отримувача: поле в сервісі посилок → поле в події чи відповіді → як його використовує сервіс сповіщень → куди потрапляє (шаблон тексту, вибір каналу). Для кожного поля — тип і формат на кожному кроці, перетворення, що губиться чи ігнорується, ризик, джерело.

У демо 2 розібрали одне поле — ім'я отримувача. У L3 BA потрібні всі поля. Розділи 3 і 4 того самого шаблону — sequence-діаграма і перевірка діаграм — нижче, у підрозділах про Mermaid і про рендер.

#Діаграма — це текст: Mermaid

Слайд 244

Mermaid — це діаграма, записана текстом. На слайді ліворуч текст, праворуч — що з нього малює переглядач. Чому для курсу саме так:

• агент пише Mermaid так само легко, як таблицю;
• текст можна звірити з кодом рядок за рядком: кожна стрілка запиту — виклик, який має бути в коді;
• правку видно в diff, як будь-яку зміну в Markdown, — і в MR теж.

Текст зі слайда — та сама вигадана оплата; намальовану діаграму видно праворуч на слайді 244:

sequenceDiagram
    actor C as Клієнт
    participant A as Застосунок
    participant O as Сервіс оплати
    C->>A: сплатити 85,50 грн
    A->>O: POST /payments, amount 8550
    alt картку відхилено
        O-->>A: відмова
        A-->>C: «Оплата не пройшла»
    else оплачено
        O-->>A: успіх
        A-->>C: чек
    end

Синтаксис, який знадобиться, — у прикладі й на позначках унизу слайда:

• flowchart LR — вузли і стрілки зліва направо; підпис на стрілці пишуть між вертикальними рисками: A -->|дані| B. Для карти інтеграцій і потоків даних.
• sequenceDiagram — учасники зліва направо, повідомлення згори вниз у часі. Суцільна стрілка ->> — запит, пунктирна -->> — відповідь. Правило «стрілка = виклик» з карти інтеграцій тут діє для суцільних стрілок. Пунктирна — не новий стик, а відповідь на той самий виклик, тож окремого виклику для неї в коді не шукайте.
• alt … else … end — гілки «якщо — інакше», як у прикладі.
• opt … end — крок, який може статися або ні.
• loop … end — повтори.

У L3 BA sequence-діаграма — це основний сценарій плюс альтернативи саме цими блоками: щонайменше 5 гілок, знайдених у коді, серед них повтори доставки події (loop) і недоступність даних отримувача. Під діаграмою — таблиця гілок: умова і джерело.

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

• перегляд .md-файлу у вашій копії на gitlab.com;
• VS Code з розширенням для перегляду Mermaid у Markdown (наприклад, Markdown Preview Mermaid Support): відкрийте .md-файл і натисніть Ctrl+Shift+V (macOS — Cmd+Shift+V);
• mermaid.live — публічний сервіс, лише для демо-системи.

Переглядач може повторити учасників sequence-діаграми ще й унизу — на слайді цей повтор вимкнено, щоб діаграма вмістилася.

Діаграма не відкривається — покажіть агенту текст помилки і попросіть виправити лише синтаксис. Часті причини:

• дужки, лапки, «» чи двокрапка в тексті вузла без лапок навколо — пишіть A["текст (з дужками)"];
• спецсимволи в підписі стрілки — беріть підпис у лапки: |"що передається"|;
• крапка з комою в тексті повідомлення sequenceDiagram — Mermaid читає її як кінець рядка.

Щоб агент не змінив зміст діаграми, просіть саме про синтаксис:

Діаграма в <шлях до файлу> не відкривається, помилка: «<текст помилки>». Виправ лише синтаксис Mermaid; зміст і стрілки не змінюй.

#Демо 2: карта інтеграцій з коду

Слайд 245

Мета демо — від пояснення з коду перейти до карти інтеграцій, діаграм і data mapping, і показати, що з цього ми перевіряємо самі.

Підготовка — та сама тека, що в демо 1: клон публічного проєкту С6, агента запущено в корені копії, результати демо — у теці тренера в submissions/. У вашій копії правило те саме, що в кроці 5 README: агент просить дозволу на запис — дозволяйте лише у свою теку в submissions/; будь-яку зміну в system/ відхиляйте.

Промпт — як на слайді. Шляхи в ньому ведуть до теки тренера submissions/koldovsky/, тому для L1 не беріть його дослівно: що змінити — нижче, в абзаці «Ваша карта L1».

На основі коду в system/ (і пояснення submissions/koldovsky/results/demo1-how-it-works.md) побудуй карту інтеграцій системи «Пакунок». Використовуй тільки system/ і цей файл.
1) Таблиця стиків: хто → кого, спосіб (webhook / REST-запит / файл), ендпоінт, які дані, автентифікація чи підпис, що буде при помилці, джерело (файл і функція).
2) Mermaid flowchart: сервіси, сховища даних, провайдер повідомлень; стрілки з підписами (що передається).
3) Mermaid sequenceDiagram основного сценарію «посилка прибула у відділення → отримувач отримав SMS»: учасники Оператор, parcels-service, notifications-service, Провайдер.
4) Data mapping одного елемента — ім'я отримувача: де з'являється, у якому вигляді зберігається, як передається, як перетворюється, де використовується; що може піти не так.
Діаграми — блоками ```mermaid. Збережи в submissions/koldovsky/results/demo2-integration-map.md. Код не змінюй.

На що звернути увагу в промпті:

• «Використовуй тільки system/ і цей файл». Агент читає лише код і пояснення з демо 1: ні чужих робіт, ні інших результатів демо. Вузькі джерела — і дешевше, і менше вигадок.
• Чотири частини — таблиця стиків, flowchart, sequence і одне поле. Колонки таблиці — ті самі, що на слайді 242.
• «Код не змінюй» — межа, яка діє в кожному промпті С6.

На що дивимося в результаті — чотири картки праворуч на слайді:

Якщо в якійсь колонці агент відповів загально, без файлу і функції, — друге повідомлення в тій самій сесії, наприклад:

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

Чого агент не підтвердив файлом і функцією — питання, а не факт.

Ваша карта L1 — та сама робота, але у вашій теці і за шаблоном. Скопіюйте integration-map.md у submissions/ваш-username/results/l1-integration-map.md і попросіть агента заповнити його за кодом. Команда копіювання і готовий промпт для заповнення — у шпаргалці, розділ «Карта інтеграцій». Межі — з кроку 5 README, у кожному промпті або першим повідомленням сесії:

Використовуй лише system/ і submissions/ваш-username/. Інших тек submissions/ і теки examples/ не читай.
Нічого не змінюй у system/. Теку system/.data/ не читай — це дані запуску, а не код.
Результати пиши лише в submissions/ваш-username/results/.

Чим ваша карта відрізняється від демо:

• спираєтеся на своє пояснення results/l1-explanation.md, а не на файл демо 1;
• з чотирьох частин промпту демо для L1 потрібні лише перші дві — таблиця стиків і flowchart. Розділи шаблону «Учасники» і «Що перевірили проти коду» теж заповнюєте. Sequence-діаграма і data mapping — це L3 BA, і там глибше: усі поля обох стиків і альтернативні гілки;
• результати демо — не вхід для агента. README прямо називає це помилкою: карту будуєте з коду самі.

#Рендер — і одна стрілка проти коду

Слайд 246

Результат демо 2 — Markdown-файл з таблицею і блоками mermaid. Його відкривають у переглядачі: VS Code з прев'ю Mermaid, mermaid.live або перегляд файлу на gitlab.com. На слайді — sequence-діаграма основного сценарію демо 2, як її малює переглядач: один канал, без альтернативних гілок. Далі — дві перевірки, які робите ви, а не агент.

Одна стрілка проти коду. На слайді перевіряють стрілку запиту за даними отримувача. На слайдах і в README такий запит називають callback (зворотний виклик) — запит за додатковими даними, який роблять посеред обробки події. Хто з двох сервісів його робить, а хто відповідає, — питання з картки, і відповідь шукаєте в коді. README називає цей ендпоінт: GET /internal/parcels/{id}/recipient. Так само перевіряють будь-яку стрілку:

1. Візьміть стрілку з діаграми і частину шляху її ендпоінта — на слайді пошук за internal.
2. У VS Code — Ctrl+Shift+F: пошук у всій теці system/. Збіги бувають двох видів — ті самі два боки стику, що в підрозділі про типи інтеграцій (слайд 240):
   • виклик — HTTP-клієнт (fetch) звертається за цією адресою. Це сторона, яка питає: стрілка йде від неї;
   • маршрут — сервіс оголошує метод і шлях, на які відповідає. Це сторона, яку питають: стрілка йде до неї.
3. Порівняйте з діаграмою. Стрілку намальовано навпаки — виправте діаграму й таблицю і запишіть це в розділ «Що перевірили проти коду» шаблону.

Чому в будь-якому запиті за даними легко помилитися: відповідь несе дані назад, і стрілку хочеться намалювати від того, хто дані віддає. Але стрілка — це виклик, а не напрямок даних. Саме таку помилку і ловить перевірка «файл і функція».

Без VS Code — як у README: попросіть агента «Знайди в system/ усі місця, де згадується X, — файл і рядок». Потім один зі збігів відкрийте самі у своїй копії на gitlab.com і переконайтеся, що він там є.

Data mapping на конкретних записах. Друга картка — про ім'я отримувача. Опис поля «за назвою» майже завжди виглядає правильно. Перевіряйте mapping не на одному зручному прикладі, а на кількох записах з початкових даних (seed, system/services/parcels/seed/). Для кожного запису подивіться, як поле в ньому записане, що з нього передає стик і що зрештою потрапляє в текст повідомлення. Потім порівняйте результати між собою. Агент такі речі легко пропускає, бо описує поле, а не значення в ньому. Знайшли розбіжність — правило це чи дефект, вирішує власник, а не ми. Як сформулювати питання власнику — розділ 4.

У завданні — третя картка слайда:

У демо — одне поле й один сценарій без альтернатив. У L3 BA — усі поля і щонайменше 5 альтернативних гілок, кожна з джерелом.

Карта показала, де стики і що через них іде. Правила, які система виконує всередині і яких ніхто не записав, — у розділі 4: відновлення вимог. Там же — сценарій на стику і контракт стику як вхід для API-тестів QA2 (слайди 251–252).

4. Вимоги без документації

У розділах 2 і 3 ми питали код, як працює система і де в неї стики. Тепер інше питання: які правила система виконує, якщо їх ніде не записано. Для BA це відновлення вимог: таблиця AS-IS з коду (що система робить зараз), магічні числа, діаграма процесу і пропозиції TO-BE (як має бути). Для QA те саме знання стає міжсистемними сценаріями і контрактом стику. З них на занятті QA2 виростуть API-тести.

Головна думка розділу: код однаково впевнено виконує і правило, і помилку. Розрізнити їх може лише власник. Наприкінці — демо 3 у двох частинах: 3a для BA і 3b для QA. У завданні С6 це рівні L2 BA, L2 QA і L3 QA.

#Вимоги без документації: AS-IS з коду, TO-BE від власника

Слайд 247

Документації немає, тож правила доводиться шукати в коді. Агент знаходить, що система робить зараз, і перекладає це мовою бізнесу. Що з цього правило, а що дефект, вирішує власник. QA перетворює те саме знання на сценарії через стик і на контракт — вхід для API-тестів.

Розділ іде в порядку слайдів:

1. AS-IS і TO-BE, коли джерело — код: таблиця відновлених вимог, «факт» і «припущення»;
2. магічні числа — питання, а не правило;
3. діаграма процесу AS-IS;
4. погляд QA: сценарій на стику і типи дефектів;
5. погляд QA: контракт стику в OpenAPI;
6. демо 3a — вимоги модуля з коду, демо 3b — контракт і сценарії.

Де це в завданні:

#Код — це AS-IS. TO-BE — рішення власника

Слайд 248

AS-IS — як є: що система робить зараз. TO-BE — як має бути. У С1–С5 AS-IS ви брали з документів: вимога, рішення, специфікація. Тут документів немає, і AS-IS — це код. Код — єдине джерело, яке точно виконується. Але він показує, що система робить, а не що хтось задумав.

Від рядка коду до TO-BE — п'ять кроків:

Знайшли в коді перевірку — сформулюйте правило мовою бізнесу: за якої умови що бачить користувач і який код відповіді. Позначте, факт це чи припущення. Чого код не пояснює, те стає питанням власнику. А TO-BE лишається пропозицією, доки власник не вирішив.

Таблиця відновлених вимог — розділ 1 шаблону L2 BA requirements-recovery.md. Колонки:

Питання власнику в шаблоні — окремо: у розділі 2 «Магічні числа і «правило чи дефект?»» з адресатом-роллю і в розділі 6 «Відкриті питання». На слайді й у прикладі нижче питання для наочності показано колонкою поруч із правилом.

На слайді — два рядки-ілюстрації з модуля переадресації, об'єкта демо 3a: один позначено «факт із коду», другий — «припущення» з питанням власнику. Різниця — у джерелі. Факт видно в самій умові в коді — разом із кодом відповіді. Припущення спирається на те, чого код не підтверджує, — наприклад, на коментар чи назву функції. Агент, який вірить коментарям (розділ 2), запише такий рядок як факт. Тому «факт / припущення» — окрема колонка.

Той самий формат на вигаданому прикладі, не з «Пакунка»:

Не кожне правило потребує питання власнику. А кожне припущення — потребує.

«Факт» і «припущення». Факт із коду — ви бачите це в коді. Припущення — висновок, якого код прямо не показує: що каже лише коментар чи назва функції, або чому так зроблено. Чесно позначене припущення в завданні — не мінус. Мінус — твердження, якого в коді немає, навіть якщо біля нього стоїть джерело.

«Умова → результат» пишіть так, щоб за рядком можна було написати тест: конкретне значення, межа — включно чи ні, що станеться. Не «перевіряє дані», а «якщо значення від N включно → відмова, код …». Межу беріть з коду, а не з відчуття.

#Магічне число — питання, а не правило

Слайд 249

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

На слайді п'ять питань до числа розібрано на фрагменті коду з демо 3a. Ось ті самі п'ять питань на вигаданому прикладі з README завдання — if (order.total >= 500) fee = 0:

Найважливіше питання — «де ще в системі». Шукайте і саме число, і те саме поняття, навіть якщо воно записане інакше, — в обох сервісах. У VS Code — Ctrl+Shift+F по всій теці. Або попросіть агента: «Знайди в system/ усі місця, де згадується …, — файл і рядок». Один зі збігів відкрийте самі. Якщо те саме правило живе у двох місцях, порівняйте їх: число, одиниці, знак порівняння.

Хто що робить:

Формат питання — той самий «Ухвалити рішення: …», що в С3–С5. На вигаданому прикладі:

Ухвалити рішення: поріг безкоштовної доставки — 500 грн включно. Лишаємо, змінюємо чи прибираємо?
джерело: orders/delivery.js · calcDeliveryFee
адресат: власник продукту замовлень

Питання ставте так, щоб на нього можна було відповісти коротко: вибрати один з варіантів, «так / ні» чи числом. Адресат — роллю, без імен. У «Пакунку» таких ролей дві: власник продукту посилок і власник продукту сповіщень.

У L2 BA це окрема частина, 2 бали: для кожного числа чи неочевидної умови — що означає, де ще в системі є це значення чи поняття, зокрема в іншому сервісі, і питання власнику з роллю адресата.

Знайти друге місце агентові найлегше, коли ви питаєте про кожне число окремим повідомленням.

#Процес AS-IS: кожна гілка — умова з коду

Слайд 250

Таблиця — це окремі правила. Діаграма процесу показує, як вони складаються разом: у якому порядку перевіряються і чим закінчується кожна гілка. На слайді — фрагмент процесу переадресації в Mermaid; повну діаграму будує агент у демо 3a.

П'ять правил діаграми — картки під нею:

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

Діаграма без підписаних гілок — це не AS-IS, а загальне враження. Ось як виглядає діаграма з підписаними гілками — на вигаданому прикладі доставки з тим самим порогом 500 грн:

flowchart LR
  A(["Оформлення<br/>доставки"]) --> B{"Адресу<br/>вказано?"}
  B -- ні --> E1["400 · адресу<br/>не вказано"]
  B -- так --> C{"Сума від 500 грн<br/>включно?"}
  C -- так --> D["доставка 0 грн"]
  C -- ні --> F["доставка<br/>за тарифом"]

Під діаграмою — коротко: кожне розгалуження → файл і функція. У вигаданому прикладі: «Адресу вказано?» → orders/checkout.js · validateAddress; «Сума від 500 грн включно?» → orders/delivery.js · calcDeliveryFee.

Діаграма — це текст Mermaid. Агент пише, ви перевіряєте одну гілку проти коду: файл, функція, рядок — і правите текстом. Переглянути діаграму можна у файлі на gitlab.com, у VS Code з розширенням для Mermaid або на mermaid.live. mermaid.live — публічний сервіс: діаграми демо-системи туди можна, робочі — лише за політикою компанії. Не відкривається — покажіть агенту текст помилки. Найчастіше заважають дужки, лапки чи «» у тексті вузла без лапок навколо — пишіть A["текст (з дужками)"].

TO-BE — окремо. На діаграмі AS-IS — лише те, що робить код. Те, що ви пропонуєте змінити, — окремим списком: 3–5 пропозицій з обґрунтуванням, кожна позначена як пропозиція і пов'язана з рядком AS-IS чи магічним числом, яке вона «лікує». Пропозиція, що зачіпає обидва сервіси, — питання двом власникам, а не одному.

#Сценарій на стику: дія тут — наслідок там

Слайд 251

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

Чотири частини сценарію:

Callback у курсі — зворотний запит: сервіс сповіщень сам звертається до сервісу посилок за даними отримувача (GET /internal/parcels/{id}/recipient, об'єкт демо 3b). Webhook — навпаки: сервіс посилок сам повідомляє сервіс сповіщень про подію (POST /v1/events, об'єкт L3 QA).

Чому по одному результату на кожній стороні. «Повідомлення не надіслано» — замало. Що в цей момент бачить відправник? А приймач? Дефект на стику часто й видно саме як розбіжність сторін: одна вважає, що все гаразд, друга нічого не зробила. Очікуваний результат має бути конкретним: код відповіді, поле, текст, запис або «повідомлення немає».

На слайді — абстрактний рядок реєстру «сервіс A → сервіс B», не з демо-системи. Ось інший вигаданий приклад у тому самому форматі:

Це тихий збій: помилки ніде немає, але й результату немає. AS-IS записуємо як є і позначаємо «підозра на дефект». Яким має бути TO-BE — питання власнику, а не наш висновок. Мовчки «виправляти» очікуваний результат не можна: тести QA2 перевірятимуть код, а не побажання.

Типи дефектів на стиках — ті самі теми, що в 11 питаннях до стику з розділу 3, лише згруповані в дев'ять типів:

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

У реєстрі L2 QA кожен тип ви прив'язуєте до місця в коді цієї системи — файл і функція — і до номерів сценаріїв. Тип без місця в коді не рахується. Матриця «стик × тип ризику»: рядки — стики з вашої карти інтеграцій L1, колонки — типи ризику, у клітинці — номери сценаріїв або «—». Під нею — які клітинки лишилися непокритими і чому.

#Контракт стику — вхід для API-тестів QA2

Слайд 252

Контракт — домовленість двох сторін про стик: що надсилають і що отримують у відповідь. OpenAPI — поширений формат такого контракту, це YAML-файл. У курсі — версія 3.1, перший рядок openapi: 3.1.0.

Що в контракті — картки праворуч на слайді:

На слайді — фрагмент контракту callback, об'єкта демо 3b. Такий самий каркас — на вигаданому прикладі:

openapi: 3.1.0
info:
  title: Сервіс замовлень · вигаданий приклад
  version: 0.1.0
paths:
  /orders/{id}:
    get:
      description: "хто викликає і навіщо; AS-IS: … ; TO-BE (пропозиція): …"
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: string, example: O-1001 }
      responses:
        '200':
          description: "Дані замовлення; джерело: файл · функція"
          # схема і приклад — так само, як у '404' нижче
        '404':
          description: "Замовлення немає; джерело: файл · функція"
          content:
            application/json:
              schema:
                type: object
                properties:
                  error: { type: string, const: order_not_found }
              example: { error: order_not_found }

Головне правило AS-IS-контракту: він описує, що код робить, а не що мав би робити. Агент схильний «виправляти» контракт: дописати те, чого в коді немає, чи прибрати незручну відповідь. Тоді тести перевірятимуть вигадану систему. Поведінку, схожу на дефект, описуємо як є, а поруч — «TO-BE (пропозиція)».

Те саме про обов'язковість: required для заголовків і полів — так, як перевіряє код, а не як «мало б бути». Чого в коді немає, так і пишемо: «у коді не визначено». Це питання власнику, а не місце для фантазії.

YAML перевіряють валідатором, наприклад Swagger Editor: вставили текст — помилки показано ліворуч. Валідатор у завданні — будь-який; бал дають за перевірку, а не за інструмент.

#Демо 3a: вимоги переадресації з коду

Слайд 253

Мета демо — показати метод L2 BA на модулі, якого в завданні немає, — переадресації посилки. І показати, що найцікавіше живе на стику двох сервісів.

Таку задачу варто запускати в новій сесії агента: контекст попередніх задач йому не потрібен, а читання коду коштує токенів. Тримайте поруч VS Code з текою system/, щоб вибірково звіряти твердження з кодом.

Промпт:

Відновлюємо вимоги там, де документації немає. Модуль — переадресація посилки: system/services/parcels/redirect.js і все, що він викликає. Використовуй тільки system/.
1) AS-IS: правила, які реально виконує код, мовою бізнесу. Таблиця: ID, правило, умова → результат (що бачить користувач, код відповіді), джерело (файл, функція), «факт із коду» чи «припущення».
2) Магічні числа й неочевидні умови — окремо: що означає, де ще в системі є це значення, кого спитати.
3) «Правило чи дефект?» — місця, де поведінка схожа на помилку або суперечить іншому модулю чи сервісу; для кожного — питання власнику.
4) Mermaid flowchart процесу переадресації AS-IS з умовами на розгалуженнях.
5) TO-BE: 3–5 пропозицій змін з обґрунтуванням; позначені як пропозиції, не як чинні вимоги.
Збережи в submissions/koldovsky/results/demo3-redirect-requirements.md. Код не змінюй.

Зверніть увагу на будову промпту. Пункти йдуть у порядку частин L2 BA: AS-IS, магічні числа і «правило чи дефект?» (у промпті це два окремі пункти, 2 і 3), діаграма, TO-BE. П'ятої частини L2 BA — перевірки щонайменше 3 тверджень агента проти коду — у промпті немає: її робите ви самі. «І все, що він викликає» — агент іде від входу за викликами, як у розділі 2. Межа і заборона змінювати код — у самому промпті.

Друге повідомлення — якщо агент не вийшов за межі модуля:

Що отримає отримувач, якщо посилку переадресували, коли вона вже чекала у відділенні, а потім вона прибула в нове відділення? Простеж обидва сервіси, з джерелами.

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

Результат читаємо за п'ятьма перевірками — картки праворуч на слайді:

Діаграму відкрийте в прев'ю VS Code або на mermaid.live і одну гілку звірте з кодом: Ctrl+P → файл, Ctrl+F → рядок умови.

Висновок демо — картка 5. «Вимоги модуля» мають межу: наслідки рішення в одному сервісі видно в іншому. Тому пропозиції TO-BE на стику — це питання до двох власників, посилок і сповіщень, а не до одного. Знахідки демо тут не наводимо: це та сама система, з якою ви працюєте в завданні.

#Демо 3b: контракт callback і сценарії

Слайд 254

Мета демо — показати L3 QA на стику, якого в завданні немає. Це запит сервісу сповіщень до сервісу посилок за даними отримувача, GET /internal/parcels/{id}/recipient. Демо показує контракт AS-IS без вигадок і сценарії через обидва сервіси.

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

Промпт:

Ти — QA і готуєш контракт для API-тестів. Стик — запит сервісу сповіщень до сервісу посилок за даними отримувача: GET /internal/parcels/{id}/recipient. Обробник — system/services/parcels/server.js, клієнт — system/services/notifications/recipient-client.js. Використовуй тільки system/.
1) OpenAPI 3.1 у YAML: шлях, параметри, відповіді з кодами і схемами (усі поля, типи, формати, приклади) — лише те, що є в коді. Чого в коді немає — не вигадуй, а пиши в description «у коді не визначено».
2) Як клієнт поводиться з кожною відповіддю (200, 404, таймаут, помилка мережі): що буде з повідомленням отримувачу і що побачить сервіс посилок.
3) 5 міжсистемних сценаріїв для цього стику: передумови, кроки через обидва сервіси, один очікуваний результат, джерело в коді.
YAML збережи в submissions/koldovsky/results/demo3-recipient-api.yaml, пункти 2–3 — у submissions/koldovsky/results/demo3-recipient-scenarios.md. Код не змінюй.

У промпті названо обидві сторони стику: обробник — код, який приймає запит і відповідає, і клієнт — код, який надсилає запит і щось робить з відповіддю. Контракт пишуть за обробником, а реакцію на кожну відповідь видно в коді клієнта. Пункт 2 — найцінніший для QA: що буде, коли відповідь не та, на яку чекали, — і як це бачить кожна сторона.

Чотири перевірки — картки праворуч на слайді:

Як перевірити. Вставте YAML у Swagger Editor і подивіться, чи є помилки. Пройдіть шлях, параметр і відповіді зі схемами й прикладами. Кожне поле схеми й кожен код відповіді знайдіть у коді обробника (Ctrl+F). Вигадане поле чи код відповіді — саме те, що має зловити перевірка: покажіть агентові, що в коді цього немає, і попросіть позначити «у коді не визначено».

Сценарії з пункту 3 — у форматі з підрозділу «Сценарій на стику» вище: передумови, кроки через обидва сервіси, очікуваний результат, джерело. У реєстрі L2 QA очікуваний результат пишуть для кожної сторони окремо, по одному: колонки «Очікуване — сервіс посилок» і «Очікуване — сервіс сповіщень».

У завданні ваші об'єкти інші, тож переносьте з демо метод, а не відповіді.

5. Завдання С6

Цей розділ — про практичне завдання шостого заняття. Ви повторюєте на своїх питаннях те, що на занятті показали в трьох демо. Демо 1 і демо 2 — це L1. Демо 3a — метод L2 BA, демо 3b — метод L3 QA; його сценарії разом зі слайдом «Сценарій на стику» — основа L2 QA. L3 BA — це демо 2, але повністю. Усе — на інших об'єктах: переадресацію і callback розібрали на демо, вам дістаються інші модулі і webhook. Нижче — основа завдання, L1 для всіх, варіант і фокус-питання, L2 і L3 за роллю, бали, здача і строки.

Усе для завдання — у новому публічному проєкті gitlab.com/koldovsky/ai-qa-ba-c6: README із завданням і таблицею варіантів, демо-система в теці system/, HOW-TO-RUN.md — як її запустити, і шаблони в templates/. Промпти, команди і таблиці перевірки — у шпаргалці.

#Завдання С6: система з коду

Слайд 255

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

Основні правила:

• Варіант — за першою літерою прізвища, той самий номер, що в С1–С5. Система одна для всіх, тому варіант задає фокус-питання до системи в L1 і модуль для L2 BA. Інакше пояснення однієї системи в усіх були б однаковими.
• Новий проєкт — koldovsky/ai-qa-ba-c6. Форки С1–С5 не підходять.
• Агент — будь-який, який читає файли в теці: Claude Code, Codex, GitHub Copilot, Cursor та інші. Лише чат у браузері теж підходить — що змінюється, у підрозділі «Здача».
• Запускати систему не обов'язково. BA код лише читають. QA — за бажанням: потрібен Node.js 20 або новіший, у теці system/ — npm start, сервіс посилок слухає порт 3001, сервіс сповіщень — 3002, npm install не потрібен. На занятті QA2 запуск знадобиться.
• MCP не потрібен.

Строки різні, бо розбір — на першому занятті вашої групи:

На цьому ж занятті видано фінальний проєкт — koldovsky/ai-qa-ba-final. Його тему ви обираєте вже в L1 цього завдання; про сам проєкт — розділ 6.

#L1 для всіх: система з коду — мовою аналітика

Слайд 256

L1 — це демо 1 і демо 2 разом плюс фокус-питання вашого варіанту: два файли в results/ і розділи звіту c6.md.

Пояснення системи — results/l1-explanation.md за шаблоном explanation.md. Структура — як у демо 1:

• що робить кожен сервіс; сутності й статуси; ендпоінти — для чого і хто їх викликає;
• основний сценарій «зміна статусу посилки → повідомлення отримувачу» кроками;
• щонайменше 5 правил, які видно в коді, кожне з джерелом;
• «Неочевидне»: магічні числа, коментарі, що суперечать коду, код, який ніхто не викликає, вимкнені функції;
• розділ «Фокус-питання варіанту NN» — відповідь кроками через обидва сервіси, з джерелами;
• перевірка щонайменше 3 тверджень агента: твердження → що в коді (файл, функція) → підтвердилось чи ні → що виправили.

Правила для всіх рівнів, з README:

• Біля кожного твердження — файл і функція, наприклад system/services/notifications/server.js · назва функції. Рядок — за бажанням. Немає функції — значення в конфігу чи мапа на початку файлу — тоді файл і назва значення.
• Що не підтверджено кодом — «припущення». Чесно позначене припущення — не мінус. Твердження, якого в коді немає, — вигадане правило чи неіснуючий ендпоінт — не зараховується.
• Мова аналітика, без коду. Не if (order.total >= 500) fee = 0, а «замовлення від 500 грн включно доставляють безкоштовно — файл · функція». Приклад вигаданий, не з цієї системи. Короткий фрагмент коду як доказ — можна.

Карта інтеграцій — results/l1-integration-map.md за шаблоном integration-map.md, як у демо 2:

• таблиця стиків: хто → кого, спосіб (webhook, REST-запит, файл), ендпоінт, які дані, автентифікація чи підпис, що буде при помилці, джерело;
• діаграма Mermaid flowchart: сервіси, сховища даних, провайдер повідомлень, стрілки з підписами — що передається.

Перевірте напрямок кожної стрілки: хто кого викликає. Це найчастіша помилка карти.

Тема фінального проєкту — розділ 5 звіту c6.md, окремого файлу не треба:

• роль у фінальному проєкті — QA чи BA;
• тема — номер з каталогу: QA — каталог ідей, 01–14; BA — каталог кейсів, 01–07; або своя у 2–3 реченнях, вигадана чи знеособлена;
• чому саме вона — 1–2 речення.

BA з власним запитом нічого додатково не обирає: зміна вимог для нього — з каталогу типових змін за номером варіанту. Змінити тему пізніше можна. У С6 оцінюється, чи є осмислений вибір.

Токен-звіт — як у С5: що показав агент (у Claude Code — /context і /usage) або оцінка — скільки файлів коду агент прочитав і скільки уточнень знадобилося. І одне речення: як зменшити. Новий акцент — читання коду коштує токенів: на великій системі «прочитай увесь system/» помітно дорожче, ніж «почни з server.js, далі — за викликами». «Пакунок» маленький, тож різниця в цифрах може бути невеликою — це теж чесний результат для токен-звіту.

Бали L1:

З чого почати. Перше повідомлення — перевірка, що агент бачить код: «Покажи дерево тек system/. Нічого не змінюй». Не бачить — ви відкрили не ту теку. Далі — одне завдання і вузьке читання, з точок входу. Промпт з README:

Ти — аналітик, який уперше бачить цю систему. Документації немає, є лише код у system/.
Використовуй лише system/ і submissions/ваш-username/. Інших тек submissions/ і examples/ не читай. Код не змінюй.
Почни з system/services/*/server.js, далі читай лише те, що вони викликають, і config.json.
Поясни мовою аналітика, без коду: що робить кожен сервіс; сутності й статуси; ендпоінти — призначення і хто викликає;
основний сценарій від зміни статусу посилки до повідомлення отримувачу кроками; щонайменше 5 правил; «Неочевидне».
Біля кожного твердження — файл і функція. Що не підтверджено кодом — познач «припущення».
Збережи в submissions/ваш-username/results/l1-explanation.md.

Фокус-питання — окремим повідомленням: «Простеж кроками через обидва сервіси: …» і текст питання з README. Відповідь — розділ «Фокус-питання варіанту NN» того самого файлу.

Перевірка пояснення — головна частина L1. Оберіть щонайменше 3 твердження агента — краще ті, від яких залежить висновок і де агент міг помилитися: числа, «завжди / ніколи», «що буде, якщо», правила з коментарів, «хто викликає». Для кожного:

1. відкрийте файл, який назвав агент: VS Code — Ctrl+P → назва файлу, Ctrl+F → назва функції чи число;
2. знайдіть рядок і прочитайте його з агентом: «Покажи рядки коду, з яких це видно»;
3. коментар над кодом — не доказ: порівняйте, що каже коментар і що робить код;
4. «хто це викликає?» — пошук по всій теці, Ctrl+Shift+F. Функцію ніхто не викликає — вона не працює, хоч би що в ній було написано.

Без VS Code — відкрийте файл у своїй копії на gitlab.com і шукайте Ctrl+F. Для «хто викликає?» попросіть агента: «Знайди в system/ усі місця, де згадується X, — файл і рядок», а один збіг відкрийте самі. Таблицю перевірки ведіть у розділі «Перевірка» файлу пояснення або в розділі 3 звіту — зараховується будь-яке.

#Варіант — ваше фокус-питання

Слайд 257

Варіант — за першою літерою прізвища, як у С1–С5. Він задає фокус-питання L1 і модуль L2 BA. Повний текст питань — з README:

Відповідь на фокус-питання — один сценарій кроками через обидва сервіси: що робить сервіс посилок, що він передає, що робить сервіс сповіщень і що бачить отримувач. Біля кожного кроку — файл і функція. Жодне фокус-питання на демо не розбирали — навмисно: відповідь ви шукаєте самі, у коді.

Модулі L2 BA:

• А · «Вибір каналу і тихі години» — непарні варіанти 01, 03, 05, 07, 09: system/services/notifications/channel.js, phone.js, templates.js, config.json.
• Б · «Статуси і зберігання посилки» — парні варіанти 02, 04, 06, 08, 10: system/services/parcels/parcels.js (створення посилки і його перевірки, переходи статусів, зберігання) і parcels/config.json; а також як сервіс сповіщень використовує ці дані — parcels/events.js і notifications/templates.js.

Демо — не ваш об'єкт. На занятті показали загальне пояснення інтеграції, карту інтеграцій з data mapping одного поля — імені отримувача, відновлення вимог модуля переадресації redirect.js і контракт запиту за даними отримувача GET /internal/parcels/{id}/recipient. Готові об'єкти демо — не ваші: L2 BA — модуль вашого варіанту, L3 QA — webhook POST /v1/events, а в L3 BA потрібен data mapping усіх полів обох стиків.

Що буде, якщо взяти не своє:

#L2 і L3 — за роллю

Слайд 258

L2 і L3 — за роллю, яку ви вказуєте у звіті рядком «Роль:». Рівні рахуються окремо, до 10 балів кожен. Рівень іншої ролі — за бажанням: зробили рівень обох ролей — у бали йде рівень своєї; зробили лише рівень іншої ролі — оцінюємо його.

BA:

QA:

L2 BA — метод демо 3a на модулі вашого варіанту, за шаблоном requirements-recovery.md:

1. AS-IS вимоги — таблиця: ID, правило мовою бізнесу, умова → результат (що бачить користувач, код відповіді), джерело (файл · функція), «факт із коду» чи «припущення». Основна вага рівня — 4 бали.
2. Магічні числа і «правило чи дефект?» — для кожного числа чи неочевидної умови: що означає; де ще в системі є це значення чи те саме поняття, зокрема в іншому сервісі; питання власнику з роллю адресата — власник продукту сповіщень чи власник продукту посилок.
3. Діаграма процесу модуля — Mermaid flowchart, AS-IS, з умовами на розгалуженнях; порядок перевірок — як у коді.
4. TO-BE — 3–5 пропозицій з обґрунтуванням, позначених як пропозиції, а не чинні вимоги.
5. Перевірка — щонайменше 3 пункти «що агент сказав → що в коді → що виправили». Що перевіряти: межі — включно чи ні, числа, порядок перевірок, «завжди / ніколи», правила з коментарів.

Як це робити — розділ 4: таблиця AS-IS, п'ять питань до магічного числа, діаграма з підписаними гілками. Готовий промпт для свого модуля — у шпаргалці.

L2 QA — реєстр щонайменше 10 сценаріїв, за шаблоном scenarios-register.md:

• кожен сценарій проходить через стик — webhook чи callback: ID, стик, тип ризику, передумови, кроки — виклики API словами, один очікуваний результат на кожній стороні, джерело в коді з обох боків, пріоритет;
• передумови — посилка з початкових даних (system/services/parcels/seed/) чи свої дані, з конкретними значеннями;
• сценарій можна описати й як прямий запит на POST /v1/events сервісу сповіщень — так, ніби подію надіслав інший відправник. Тоді в колонці «Очікуване — сервіс посилок» — «не задіяно» або що зробив би відправник, отримавши таку відповідь;
• очікуване AS-IS, яке виглядає дефектом, — позначка «підозра на дефект», а очікуване TO-BE — питанням власнику;
• типові дефекти на стиках — щонайменше 5 типів зі списку в розділі 4 чи своїх, і для кожного — де саме в цій системі підозра (файл · функція) і номери сценаріїв;
• матриця «стик × тип ризику → сценарії» з непокритими клітинками і поясненням, чому вони непокриті;
• відкриті питання — очікувані результати, яких код не визначає, з адресатом-роллю.

Запускати систему в С6 не обов'язково: сценарії можна вивести з коду. Запустили — у звіті скажіть, які сценарії перевірили наживо і що побачили. Приклади запитів — у HOW-TO-RUN.md. Промпти для реєстру сценаріїв і контракту — у шпаргалці.

L3 BA — демо 2, але повністю, за шаблоном data-flows.md:

1. Карта потоків даних — Mermaid flowchart у стилі DFD: джерела, сховища, перетворення, споживачі. Три потоки: подія про статус (webhook), дані отримувача (запит за даними), повідомлення (провайдер).
2. Data mapping — усі поля обох стиків: поле в сервісі посилок → поле в події чи відповіді → як його використовує сервіс сповіщень → куди потрапляє. Для кожного поля — тип і формат на кожному кроці, перетворення, що губиться чи ігнорується, ризик, джерело. Ім'я отримувача розібрали на демо — тут потрібні всі поля.
3. Sequence-діаграма — Mermaid sequenceDiagram з учасниками Оператор, parcels-service, notifications-service і провайдер повідомлень: основний сценарій і щонайменше 5 альтернативних гілок alt / opt / loop, які ви знайшли в коді. Серед них — повтори доставки події (loop) і недоступність даних отримувача.
4. Перевірка діаграм проти коду — щонайменше 3 пункти: що на діаграмі → що в коді → збігається чи ні → що виправили. Наприклад, напрямок кожної стрілки: хто кого викликає.

L3 QA — як демо 3b, але webhook POST /v1/events: обробник — у system/services/notifications/server.js, відправник — system/services/parcels/events.js. Файли:

• results/l3-qa-events-api.yaml — OpenAPI 3.1 за каркасом openapi-skeleton.yaml. Запит: заголовки, які читає обробник, і чи вони справді обов'язкові — як у коді, а не як «мало б бути». Схема тіла — усі поля, типи, формати (date-time, шаблон ідентифікатора), required і enum — перелік кодів статусу посилки в події. Відповіді: кожен код відповіді, який повертає обробник, і кожен варіант тіла — зі схемою і прикладом. Де поведінка виглядає як дефект — description «AS-IS: … ; TO-BE (пропозиція): …» або x-as-is;
• results/l3-qa-contract-notes.md — який валідатор і що він показав, щонайменше 3 звірки «пункт контракту → файл · функція» і щонайменше 8 ідей API-тестів для QA2: позитивні, негативні, межові, дублі, підпис. Межові — точками під, на і над межами правил, які ви знайшли в коді; конкретні значення — з джерелом.

#Здача — QA 03.11 · BA 10.11, 23:59

Слайд 259

Механіку MR ви знаєте з С1–С5. Головна різниця з С5 — робоча тека. У С5 агента запускали в submissions/<username>/. Тепер — у корені своєї копії: агенту потрібна тека system/, а більшість агентів без дозволу не читають вище теки, де їх запустили.

ai-qa-ba-c6/                      ← корінь копії · тут запускаєте агента
├── system/                       ← демо-система · лише читати
└── submissions/<username>/
    ├── c6.md                     ← звіт · templates/c6-report.md
    └── results/
        ├── l1-explanation.md, l1-integration-map.md
        ├── l2-ba-… або l2-qa-…   ← L2
        └── l3-ba-… або l3-qa-….yaml + notes   ← L3

Замість <username> і ваш-username — ваш username на gitlab.com.

Імена файлів у results/ — рекомендація: зараховуються будь-які, якщо у звіті є посилання.

Межа — у кожному промпті. Агент працює з усією копією, тому межі пишете явно — у кожному завданні або першим повідомленням сесії. На слайді:

використовуй лише system/ і submissions/<username>/; інших тек submissions/ і examples/ не читай; запит на їх читання — відхилити

Повна версія з README, крок 5:

Використовуй лише system/ і submissions/ваш-username/. Інших тек submissions/ і теки examples/ не читай.
Нічого не змінюй у system/. Теку system/.data/ не читай — це дані запуску, а не код.
Результати пиши лише в submissions/ваш-username/results/.

• Агент просить прочитати чужу теку в submissions/ чи examples/ — відхиліть. Після злиття MR нові форки містять чужі роботи, а в examples/ після заняття можуть з'явитися результати демо. Скопійований результат не зараховується.
• Агент просить змінити файл у system/ — відхиліть. Дозволяйте лише запис у submissions/<username>/.
• Агент хоче запустити команду — читайте, що саме. BA запуск не потрібен; QA, які запускають систему, — лише команди з HOW-TO-RUN.md і запити до localhost:3001 чи localhost:3002.

Файлів правил у корені копії немає — ні AGENTS.md, ні CLAUDE.md, ні тек агентів. Так у всіх однаковий старт. Свої правила С5 — за бажанням, без балів: першим повідомленням сесії або в особистому файлі правил агента, наприклад ~/.claude/CLAUDE.md. Файл правил у корені копії не створюйте і не комітьте. Якщо у ваших правилах С5 є межа «пиши лише в results/», перевірте її: тут ваша тека — submissions/<username>/results/.

Лише чат. Код візьміть зі своєї копії ZIP-архівом (Code → Download source code → zip) і додайте в чат файли system/services/** вкладеннями або текстом, кожен під заголовком зі шляхом файлу. Почніть з server.js обох сервісів і додавайте інші, коли агент про них питає, — так дешевше. Джерело — так само «файл і функція»: перевіряєте його в самому файлі на gitlab.com. Діаграми — текст Mermaid, а відкривається він чи ні, перевіряєте самі. У звіті — рядок «умови чату»: які файли додали; чи були ввімкнені пам'ять між розмовами чи інструкції проєкту, якщо ваш чат їх має.

MR — як у С5, але в новий проєкт: форк koldovsky/ai-qa-ba-c6 → гілка c6 → MR у koldovsky/ai-qa-ba-c6, гілка main, шаблон опису C6. Назва:

С6 · username · варіант NN

• Звіт — за шаблоном templates/c6-report.md, з прізвищем та ім'ям, варіантом і роллю. Розділи 1–6 і 9 — L1, розділ 7 — L2, розділ 8 — L3 своєї ролі.
• Чернетку звіту може скласти агент — у results/c6-draft.md. Ви переносите її в c6.md і перевіряєте кожне посилання і кожне твердження.
• Через git — спершу прихована пошта (git config user.email з адресою вигляду …@users.noreply.gitlab.com), як у С4–С5. У git status мають бути лише файли з submissions/<username>/. Бачите зміни в system/ — поверніть їх командою git restore system/.
• Лише браузер — + → New file з повним шляхом, як у С4–С5. Не виходить файлами — вміст кожного файлу в «Додаток» звіту блоками коду: зараховується так само.
• У вкладці Changes MR — лише ваша тека: без змін у system/, без файлів правил і тек агента, без чужих файлів.

Формальності — −1 за кожну, разом не більше −2: звіт не в submissions/<username>/c6.md, назва MR не за шаблоном, не вказано варіант або прізвище та ім'я. Діаграма, яка не відкривається, зараховується за змістом, але синтаксис перевірте.

Як перевіряється — як раніше, з README. Після строку кожен MR перевіряє AI-рев'юер за рубрикою, джерела «файл і функція» звіряють з кодом system/. Частину робіт додатково переглядає тренер. Відгук — коментарем у вашому MR; бали в коментарях не публікуються — вони йдуть у рейтинг курсу. Не згодні — коментар у своєму MR, тренер розгляне його особисто.

Строк QA — вівторок, 03.11, тож не відкладайте старт.

Питання щодо завдання — у Telegram-чат когорти, гілки QA і BA. Запис заняття, слайди, конспект і шпаргалка — на сайті курсу.

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

Наприкінці С6 видано фінальний проєкт — одне завдання на сім тижнів, з 28.10 до 14.12. Цей розділ — про нього: що будує QA і що готує BA, обов'язковий діагностичний пакет QA, критичне рев'ю і зміна вимог BA, рубрика на 200 балів, умови «прийнято», ключові дати, перші кроки і здача.

Усі правила — у README фінального проєкту. Покрокові інструкції — у шаблонах: FINAL-QA.md у шаблоні QA, README і FINAL-BA.md у шаблоні BA. Якщо тексти розходяться: правила, бали, строки й умови «прийнято» визначає README фінального проєкту, а структуру файлів, формат ID і команди — шаблон вашої ролі. Слайди — лише орієнтир.

#Фінальний проєкт: 28.10 → 14.12

Слайд 260

Одне завдання на сім тижнів, без проміжних контрольних точок. QA доводить тестами якість власного невеликого продукту. BA доводить сирий запит до пакета, готового до розробки, і показує, що пакет витримує зміну вимог.

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

#Навіщо — і що ви отримуєте сьогодні

Слайд 261

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

• QA — якість продукту доводять три речі, які не залежать від думки автора: мутаційний поріг у CI, тести, що ловлять дефекти, внесені кимось іншим, і діагностика дефекту за моделлю Д1–Д3. Що таке мутаційне тестування і Д1–Д3 — у підрозділах QA нижче.
• BA — пакет виявляє неоднозначності, суперечності й прогалини ще до розробки, лишається узгодженим між вимогами, прототипом, UAT і задачами та витримує зміну вимог.
• Для обох — практики С1–С6 в одному артефакті: джерела, правила і скіли, специфікації, критичне рев'ю, токен-звіт.

Не мета: великий продукт, «красивий» дизайн, реальна предметна область вашої роботи.

Разом із завданням ви отримуєте все для самоперевірки:

Три правила для всіх:

• Тема — вигадана або знеособлена. Жодного корпоративного коду, документів, даних, назв клієнтів і партнерів. Знайдуть реальні дані — роботу не оцінюють, доки їх не приберете: одна спроба, 48 годин у тижні оцінювання.
• Форки публічні. Усе, що ви кладете у форк, бачить будь-хто. Лише навчальні матеріали.
• Агент — будь-який, демо — у Claude Code. Для QA самого лише чату в браузері замало: агент має запускати тести й Stryker та працювати з репозиторієм. BA може готувати тексти пакета в чаті, але задачі в трекері створює скіл через агента з доступом до GitLab — GitLab MCP, як у С3, або glab, консольну утиліту GitLab.

#QA: свій продукт — якість доведена тестами

Слайд 262

QA робить форк шаблону ai-qa-ba-final-qa-template і будує в ньому власний невеликий продукт.

• Стек — TypeScript і Vite: клієнтський застосунок без бекенду і без зовнішніх API; дані — у пам'яті або в localStorage. Це правило для всіх продуктів фіналу, і для власної ідеї теж.
• Тема — ідея з каталогу (14 ідей, список — нижче, у «Почати сьогодні») або своя того самого розміру.
• Специфікації OpenSpec, знайомі з С4, — на кожну функцію продукту. Хоча б одна зміна проходить увесь шлях: openspec/changes/ → реалізація і тести → архів. Окремої зміни від тренера в QA немає: зміна вимог тут — частина звичайної роботи зі специфікацією.
• GitLab CI запускає перевірки на кожен push. На тегу final пайплайн має бути зеленим.

Основних команд шаблону — чотири: їх ви (точніше, агент) запускатимете постійно. Перед першим запуском — npm ci у теці форку; потрібну версію Node.js вказано у файлі .nvmrc шаблону.

npm test                 ← юніт- і компонентні тести · Vitest
npm run mutation         ← мутаційне тестування · Stryker · нижче 60% — помилка
npm run e2e              ← наскрізні тести в браузері · Playwright
npm run defects:check    ← самоперевірка: чи ловлять ваші e2e навмисно внесені дефекти

Мутаційне тестування перевіряє самі тести. Stryker навмисно вносить у код дрібні зміни — «мутанти»: міняє порівняння, прибирає умову, підставляє інше значення — і щоразу запускає тести. Якщо жоден тест не впав, мутант «вижив»: у цьому місці тести насправді нічого не перевіряють. Mutation score — частка мутантів, яких тести помітили. Як пройти поріг 60%, описує FINAL-QA.md.

Код і тести пише агент. Ви ставите задачі природною мовою, перевіряєте, відхиляєте і просите виправити.

Стартовий «Трекер посилки» лишається. Шаблон уже містить невеликий продукт — трекер посилки. У нього тренер внесе дефект для Д1, тому свій продукт ви будуєте поруч: окремі модулі й сторінка в списку PAGES. Код і специфікацію трекера не видаляєте і не змінюєте. Базові тести не видаляєте і не послаблюєте — додавати можна. Якщо трекер переїде з головної адреси /, у e2e/tracking.spec.ts змінюєте лише адресу в page.goto — на '/#/tracking'. Деталі — FINAL-QA.md, розділ 1.

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

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

Доведена якість:

• Stryker ≥ 60% — у CI на всьому src/ і окремо по файлах ваших власних функцій. Друга умова потрібна тому, що базові тести трекера вже дають понад 60%: слабкі тести власного коду «за рахунок» трекера поріг не пройдуть. У звіті Stryker mutation score видно для кожної теки; найпростіше — тримати кожну теку власної функції від 60%. Обидва числа покажіть у final.md.
• E2e — щонайменше по одному на кожен користувацький потік зі специфікації, зі справжніми перевірками.
• ≥ 3 власні навмисні дефекти в defects/ на ваш код — зсув межі правила, пропущена перевірка, не те значення на екрані. Ви описуєте, як саме зламати свій код; npm run defects:check по черзі вносить кожен дефект, запускає e2e і повертає код як був. Ваші e2e мають спіймати всі. Стартові D-01…D-03 шаблону не рахуються; як писати дефекти — defects/README.md шаблону.
• Приховані дефекти тренера. Після подання тренер вносить у ваш продукт дефекти — у місця, які описує ваша ж специфікація. Бали — за кожен, який спіймав хоча б один ваш тест, що падає з правильної причини. Тому межі правил тестуйте точками під, на і над межею.

Підготовка — на заняттях групи QA. QA1, ср 04.11 — Vitest і Stryker; L3 завдання QA1 — перша власна функція в шаблоні фіналу з тестами і mutation score від 60% по її файлах. QA2, ср 18.11 — API-тести, регресія і GitLab CI.

#Д1–Д3 — обов'язковий діагностичний пакет

Слайд 263

Д1–Д3 — модель діагностики, яку докладно розбирають на занятті QA3: ви знаходите дефект, доводите його причину і готуєте виправлення так, щоб рішення лишилося за розробником. Код власноруч не пишете. Обов'язкові всі три частини.

Звідки дефект. До пн 16.11 тренер опублікує в шаблоні QA навмисно внесені дефекти — для кожного варіанту свій: гілки d1/NN (NN — номер варіанту) і симптоми у файлі D1-SYMPTOMS.md гілки main, з оголошенням у чаті. Варіант — той самий номер, що в завданнях курсу. Симптом описано мовою користувача — «після … бачу …», без підказок, де шукати в коді. Як отримати дефект у свій форк — FINAL-QA.md, розділ 3: гілку свого варіанту зливаєте в окрему гілку свого форку, а не в main.

Де лежать файли. diagnostics/d1-localization.md і diagnostics/d2-bug-report.md комітьте в main — у ту гілку, на яку ставите тег final; інакше під час збирання доказів їх не побачать. Сам код дефекту в main не зливайте. Мітку AI-proposed створюєте у своєму форку самі, бо мітки форк не успадковує: Manage → Labels → New label.

Це той самий принцип, що в С6: висновок «де саме» — файл і функція, а не «десь у модулі». Тільки тепер джерело підтверджує ще й тест.

Зразок діагностичного пакета — docs/diagnostic-package-sample/ у шаблоні. QA3, ср 02.12 — розбір Д1–Д3 і типових зауважень: приходьте з чернеткою. Від публікації дефекту до QA3 — два тижні.

Бали: Д1, Д2 і Д3 — по 4, разом 12 в «Інженерних артефактах». Але бракує хоча б однієї частини — обов'язкову умову не виконано, і проєкт не прийнято за будь-якої суми балів.

#BA: сирий запит → пакет для розробки

Слайд 264

BA робить форк шаблону ai-qa-ba-final-ba-template і веде в ньому наскрізний аналітичний пакет. П'ять частин — у тому порядку, в якому їх зазвичай роблять:

Вхід — один із двох:

• кейс каталогу — сирий запит вигаданої компанії: листування, нотатки зустрічі, вкладення. У кожному кейсі навмисно закладено неоднозначності, суперечності й прогалини. Скільки їх і які, не кажуть: знайти їх — частина роботи;
• власний запит — вигаданий або знеособлений, на один епік і 5–8 сторі.

Прототип — у будь-якому інструменті. Він зараховується, якщо:

• основний потік клікається від першого до останнього екрана;
• є хоча б одна гілка помилки чи альтернативи — відмова, порожній стан, перевищення ліміту;
• ID екрана SCR-NN видно на самому екрані і в реєстрі 03-prototype/screens.md;
• кожна сторі з інтерфейсом посилається на екран, а кожен екран — на сторі;
• дані на екранах вигадані.

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

Задачі в трекері створює скіл, а не ручне копіювання:

• трекер — Issues вашого форку. Якщо їх немає в меню: Settings → General → Visibility, project features, permissions → Issues → увімкнути → Save changes;
• скіл — ваш власний, наприклад L3 з С5, або адаптований з бібліотеки курсу; лежить у skills/<назва>/SKILL.md;
• агент працює через GitLab MCP, як у С3, або через glab;
• мінімум — задача на кожну сторі; у кожній — ID, посилання на сторі й AC, критерії готовності, мітки або рядок «Мітки: …» (мітки форк не успадковує). Знімок задач 05-tracker/tasks.md генерує той самий скіл;
• доказ — лог прогону скіла (у review/, наприклад review/skill-runs.md, або у final.md) і однакова структура задач. Ручні задачі без скіла дають лише частину балів.

Наскрізні ID обов'язкові: PS, H, EP, US, AC, SCR, UAT, T, Q, CH. Без них ні скрипт узгодженості, ні рев'юер не бачать зв'язків. Структуру тек і формат ID задає шаблон BA — скрипт читає саме її:

У С6 ви розкладали знахідки на «факт із коду», «припущення» і «питання власнику». У пакеті BA та сама техніка, лише джерело інше: неоднозначність запиту не вирішуєте мовчки, а записуєте в review/questions.md — як питання з адресатом, рішення з джерелом або позначене припущення.

Підготовка — на заняттях групи BA. BA1, ср 11.11 — discovery, problem statement, епік і сторі. BA2, ср 25.11 — прототипи. BA3, ср 09.12 — критичне рев'ю, узгодженість, зміна.

#Критичне рев'ю і зміна вимог

Слайд 265

«Критичне рев'ю пройдено» — обов'язкова умова BA. Вона виконана, якщо одночасно:

1. Скрипт узгодженості — 0 помилок на тегу final у режимі final: npm run check:final. Цей режим додатково вимагає скіл і застосовану зміну. Попередження допустимі, якщо ви пояснили їх у журналі рев'ю.
2. Ваше власне рев'ю є. Повний прогін промптів критичного рев'ю з шаблону — п'ять промптів P1–P5 у prompts/critical-review.md: P1, P2, P4, P3 на v1 і P5, P3 на v2 (v2 — пакет після зміни вимог). Порядок саме такий; як запускати — prompts/README.md шаблону. Кожен прогін — окремим розділом у review/critical-review.md з версією, агентом і датою. Кожну знахідку закрито одним із трьох способів: виправлено; винесено в питання з адресатом; свідомо прийнято з причиною.
3. Під час оцінювання рев'ю за рубрикою не знаходить суттєвих прогалин, які ви пропустили. Остаточно прогалину підтверджує тренер. Суттєва прогалина — це те, через що розробник не може реалізувати сторі, а тестувальник — перевірити її, не поставивши питання: бракує правила, числа, стану чи ролі, або артефакти суперечать один одному. Прогалина, яку ви вже винесли в питання, не рахується.
4. Для кейсів каталогу — ви помітили закладені проблеми. «Помітили» означає: проблему названо явно — як питання, як рішення з джерелом або як позначене припущення. Мовчки обрана одна з версій не рахується.

Зміна вимог. Мета — не вгадати зміну, а показати, що пакет лишається узгодженим, коли вимоги змінюються.

Для власного запиту зміну задає варіант — той самий, що в завданнях курсу, за першою літерою прізвища. Він прив'язаний до вас, а не до теми: змінили власний запит — зміна вимог лишається та сама. Для кейсу каталогу зміна — change.md саме цього кейсу.

Порядок однаковий для всіх:

1. Пакет v1. Зберіть пакет, запустіть скрипт (npm run check — 0 помилок), проведіть рев'ю промптами з шаблону і поставте тег v1. Тег ставить агент або ви самі: Code → Tags → New tag.
2. Коміти CH:. Зміну застосовуєте окремими комітами після v1; повідомлення кожного починається з CH:. Оновлюєте все, що зміна зачіпає: PS і гіпотези, епік, сторі й AC, екрани, UAT, задачі в трекері, питання. Для артефакту, якого зміна не зачіпає, — рядок «без змін» з причиною в change/impact.md.
3. Таблиця впливу в change/impact.md: зміна → які ID зачеплено → що зроблено (змінено, додано, видалено, без змін з причиною) → нові питання, які породила зміна.
4. Скрипт знову — 0 помилок.
5. Тег final. У трекері видно, що сталося: задачі оновлено, додано або закрито з коментарем CH: ….

#Рубрика: 200 балів · 60 · 80 · 30 · 30

Слайд 266

Чотири компоненти — як у програмі курсу: 60, 80, 30 і 30. Повна рубрика, з тим, що саме перевіряють у кожній частині, — у README фінального проєкту, розділ «Рубрика».

Де найбільша вага:

• Доведена якість — 80, найбільший компонент. У QA бали за мутаційний поріг рахують за mutation score на всьому src/, але mutation score по файлах власних функцій теж має бути від 60% — інакше за мутаційний поріг 0. Приховані дефекти — по 10 за кожен, який спіймав хоча б один ваш тест будь-якого рівня, що падає з правильної причини; якщо продукт замалий для трьох дефектів, їх буде два, по 15. Якість тестового набору оцінює критичне AI-рев'ю: справжні перевірки, межі точками під, на і над, негативні випадки, зв'язок «тест ↔ сценарій специфікації». У BA — узгодженість (скрипт на v1 і final плюс ручна вибірка зв'язків), критичне рев'ю, стрес-тест зміни, питання й рішення з адресатами та джерелами.
• Відео і письмове пояснення — по 15, однаково для QA і BA.
• Інженерні артефакти — 30: як ви працювали. У QA найбільша частина — Д1–Д3, 12. У BA — скіл «пакет → задачі», 12: правильний формат SKILL.md, як у С5, загальний, без прив'язки до одного пакета, прогін видно. Правила агента дають бали, коли їхній вплив видно в результаті, а не коли це копія зразка.

Як рахують:

• бали знімаються за недоліки; порожня частина — 0;
• формальності — як у С1–С6: −1 за кожну, разом не більше −2. Формальність — це звіт не за шляхом submissions/<username>/final.md, назва MR не за форматом або звіт без прізвища та імені, ролі чи варіанту;
• у коментарях до MR — лише поради, без балів, як у всіх завданнях. Бали йдуть у реєстр і рейтинг курсу.

#Прийнято — від 120 і всі обов'язкові умови

Слайд 267

«Прийнято» — це дві речі одночасно: щонайменше 120 балів з 200 і всі три обов'язкові умови. Не виконано умову — проєкт не прийнято навіть за 150 балів.

Не прийнято, якщо:

• менше 120 балів;
• не виконано будь-яку обов'язкову умову — навіть за 120 балів і більше;
• подано після пн 14.12, 23:59 — строк не переноситься, як і для завдань;
• робота не своя: ідентична іншій роботі чи зразку шаблону, переписаний чужий пакет;
• реальні дані, код чи назви компанії не прибрано за 48 годин після повідомлення.

Бейджі:

Арифметика проста. Вісім завдань на рівні L1 — це 80 балів, прийнятий фінал — від 120: разом рівно 200, без жодного рядка коду, написаного власноруч. Запас дають рівні L2 і L3 у завданнях або понад 120 балів за проєкт. Усього в курсі — 440 балів: 8 завдань по 30 і 200 за фінальний проєкт. Practitioner присвоюють після оцінювання фінальних проєктів, з пн 21.12.

Неприйнятий проєкт однаково отримує бали за рубрикою — вони йдуть у рейтинг, але бейджа Practitioner не дають. Повторного подання немає; виняток — прибрати реальні дані.

#Сім тижнів: ключові дати

Слайд 268

Самоперевірка 23.11 — для себе. QA: npm test, npm run mutation, npm run e2e, npm run defects:check, пайплайн зелений. BA: скрипт узгодженості і промпти рев'ю на чернетці; пакет v1 майже готовий.

Заняття групи — це кроки проєкту, а не окремі теми:

На QA3 і BA3 приходьте з чернеткою — там звіряєте свою роботу з вимогами перед поданням. Зробили завдання заняття на шаблоні проєкту — частину проєкту вже зроблено.

Скільки часу: орієнтовно 3–4 години на тиждень для QA і близько 3 годин для BA.

Нагадування в чаті: 23.11 — самоперевірка, 30.11 — зміна в кейсах, 07.12 — «тиждень до строку: тег final, відео, звіт», 14.12 — удень.

#Почати сьогодні — частина L1 С6

Слайд 269

Старт фінального проєкту — уже частина L1 завдання С6, тож окремого кроку «колись потім» немає. Із п'яти кроків у завданні С6 оцінюється лише третій — тема в c6.md. Решта — щоб не відкладати старт самого проєкту. П'ять кроків:

1. Форк шаблону своєї ролі — якомога раніше: ai-qa-ba-final-qa-template або ai-qa-ba-final-ba-template. Fork → namespace: ваш username → Fork project. Це ваш робочий форк: увесь проєкт живе в ньому, туди ж ставите теги.
2. Тема. QA — номер ідеї з каталогу ідей або своя ідея того самого розміру. BA — номер кейсу з каталогу кейсів або свій запит на 1 епік і 5–8 сторі. Своя тема — одним абзацом на 2–3 речення, вигадана або знеособлена.
3. У c6.md — розділ 5 «L1 · Тема фінального проєкту»: роль, тема (номер або абзац) і чому саме вона — 1–2 речення. QA — до вт 03.11, BA — до вт 10.11. У С6 оцінюється, чи є осмислений вибір: 1 бал у L1.
4. QA: npm ci і npm test у своєму форку — переконатися, що шаблон працює на вашому комп'ютері. Не працює — питання в гілку QA чату вже цього тижня, а не в грудні.
5. BA з власним запитом: подивіться свій рядок у каталозі змін. Знати зміну заздалегідь — нормально, але у v1 її ще не має бути.

Не здаєте С6 — напишіть тему першим рядком final.md і в гілці своєї групи (QA чи BA) в чаті. Тему можна змінити й пізніше, але для власного запиту BA зміна вимог прив'язана до варіанту, а не до теми.

Каталоги нижче — лише назви. Повний опис — у теці catalog/ фінального проєкту.

QA · каталог ідей. Усі продукти клієнтські, без бекенду. У кожній ідеї вже є бізнес-правила з межами — для юніт-тестів і мутацій — і користувацькі потоки для e2e.

BA · каталог кейсів. Усі компанії вигадані; кожен кейс — сирий запит з листуванням, нотатками і вкладеннями.

Каталог чи своя тема? Каталог безпечніший: розмір уже підібрано, а кейси BA мають закладені проблеми і заздалегідь визначену зміну, тож видно, що саме ви помітили. Своя тема — якщо вона вам ближча і так само вигадана або знеособлена. За балами каталог і своя тема рівні.

#Здача — до пн 14.12, 23:59

Слайд 270

Здаєте у два місця, і в обох є слово «final». Не плутайте:

• тег final — у вашому робочому форку шаблону: позначає версію, яку оцінюють. BA має ще й тег v1, поставлений раніше;
• гілка final — у вашому форку проєкту koldovsky/ai-qa-ba-final: у ній лише звіт.

форк koldovsky/ai-qa-ba-final · гілка final
submissions/<username>/
└── final.md        ← звіт · templates/final-report.md

Кроки:

1. Тег final у робочому форку: Code → Tags → New tag → final · гілка — та, де остаточна версія → Create tag. Або доручіть агенту.
2. Форк koldovsky/ai-qa-ba-final → Fork → namespace: ваш username.
3. Гілка final у ньому: Code → Branches → New branch → final → Create branch.
4. Звіт: у гілці final — + → New file → повний шлях submissions/ваш-username/final.md → текст за шаблоном templates/final-report.md → Commit changes у гілку final. Можна й через git чи агента.
5. MR у koldovsky/ai-qa-ba-final, гілка main, шаблон опису Final — пройдіть його чек-лист. У вкладці Changes — лише ваш final.md. Назва:

Фінал · username · QA · варіант NN
Фінал · username · BA · варіант NN

Що в final.md: прізвище та ім'я, роль, варіант; тема — номер з каталогу або власна; посилання на робочий форк і тег final.

• QA — посилання на пайплайн final, mutation score (обидва числа), посилання на Д1, Д2 і draft MR Д3.
• BA — посилання на тег v1, на трекер (Issues форку), на прототип і як його відкрити; зміна — кейс чи варіант.
• Для обох — відео, «Застосовані практики» і токен-звіт.

Знімок — вт 15.12, 00:05. Дату коміту можна поставити будь-яку, а тег — пересунути. Тому о 00:05 записують, на який коміт вказує кожен тег final і v1, і оцінюють саме цей стан. Тег, пересунутий пізніше, не рахується. Немає тегу final — береться останній коміт гілки, вказаної у final.md, на той самий момент. Тег сам за новими комітами не рухається. Щоб пересунути його до строку: Code → Tags → видалити final → New tag → final знову.

Відео — до 5 хвилин. Посилання з доступом за лінком: YouTube «не в списку», Google Drive «усі, хто має посилання», Loom тощо. Без реальних даних; показувати обличчя не обов'язково. Понад 5 хвилин — дивляться перші 5. QA показує продукт, специфікацію, зелений CI, звіт Stryker, прогін e2e і Д1–Д3. BA — прохід від PS через сторі, прототип (клікаєте), UAT до трекера і зміну v1 → v2. Записуйте з порожнім робочим столом, без робочих вкладок і сповіщень.

«Застосовані практики» — розділ final.md на 1–2 сторінки: які правила і скіли працювали; як ставили задачі агенту; що і як перевіряли; щонайменше три конкретні випадки, коли ви відхилили або виправили результат агента, — з посиланням на коміт чи файл; токен-звіт, як у С1–С6.

Формальності — по −1, разом до −2: не той шлях файлу, назва MR не за форматом, немає прізвища та імені, ролі чи варіанту. Немає посилання на форк — це вже не формальність: форк шукатимуть за автором MR, а не знайдуть — роботу не оцінять.

Строк не переноситься, як і для завдань.

#Питання про фінальний проєкт

Слайд 271

Типові питання і короткі відповіді:

Я не програмую — QA-фінал для мене? Так. Код і тести пише агент; ви ставите задачі, перевіряєте, відхиляєте і просите виправити. Три такі випадки — частина письмового пояснення. Шаблон уже налаштовано, а FINAL-QA.md веде крок за кроком.

Не дотягую до 60% у Stryker. QA1, 04.11: L3 там саме про це. У FINAL-QA.md є інструкція, як пройти поріг. Аналізуйте мутантів, що вижили, і підсилюйте тести; конфігурацію Stryker не чіпайте.

Можна лише чат у браузері? QA — ні: потрібні запуск, тести, CI. BA — для текстів пакета так, але задачі в трекері створює скіл через агента з доступом до GitLab: GitLab MCP або glab.

Чи можна працювати не в Claude Code? Так: Codex, GitHub Copilot, Cursor та інші. Де агент шукає правила і скіли — AGENT-SETUP.md С5. Можна поєднувати кілька агентів — напишіть про це в поясненні.

Моя ідея QA завелика чи замала? Мінімальний обсяг — у підрозділі «QA» вище. Сумніваєтеся — спитайте в гілці QA чату до 03.11.

Можна змінити тему? Так, і що раніше, то краще. У BA зміна вимог для власного запиту прив'язана до варіанту, а не до теми.

BA: зміну для власного запиту я вже знаю — врахувати одразу? Ні. Спершу v1 без зміни і тег v1, потім коміти CH:. Зміна вже у v1 — 0 за стрес-тест.

Прототип у Figma — можна? Так: посилання на перегляд з доступом за лінком у 03-prototype/link.md і експорт кожного екрана PNG чи PDF у 03-prototype/screens/ — один файл на екран з ID у назві: SCR-01.png, SCR-02.png … Без експорту скрипт узгодженості дає помилку.

Issues у форку BA вимкнені. Settings → General → Visibility, project features, permissions → Issues → увімкнути → Save changes.

Скільки проблем закладено в кейсі? Цього не кажуть: знайти їх — частина роботи.

Можна взяти темою робочу задачу чи продукт своєї компанії? Ні. Лише вигадане або знеособлене — так, щоб не можна було впізнати. Сумніваєтеся — оберіть каталог. Знайдуть реальне — роботу не оцінюють, доки не приберете: 48 годин.

Корпоративний ноутбук без прав адміністратора. QA потрібні git, Node.js (версія — у .nvmrc шаблону) і браузери для Playwright; BA — git і агент з доступом до GitLab. Не можете встановити — напишіть тренеру зараз, а не в грудні.

Можна вдвох? Ні, проєкт індивідуальний. Ідентична робота — не прийнято.

Буде проміжна перевірка? Ні. 23.11 — добровільна самоперевірка, без балів і без подання. Питання — у гілках QA і BA чату.

Строк можна перенести? Ні, як і для завдань.

Де шукати відповіді: README ai-qa-ba-final — правила і рубрика, розділ «Часті питання»; FINAL-QA.md — шаблон QA; README і FINAL-BA.md — шаблон BA. Питання — у Telegram-чат когорти, гілки QA і BA.

7. Що далі і ресурси

С6 — останнє спільне заняття курсу. Далі — заняття вашої групи, раз на два тижні: заняття QA — для групи QA, заняття BA — для групи BA. У цьому розділі — що буде на перших заняттях груп і що з С6 там знадобиться, п'ять головних думок С6, де шукати матеріали і короткі відповіді на типові питання про завдання С6.

Строк завдання С6 різний: QA — до вт 03.11, BA — до вт 10.11, 23:59. Розбір — на першому занятті групи: QA1, 04.11, і BA1, 11.11.

#Далі — заняття вашої групи

Слайд 272

• QA1. Ви описуєте сценарій словами, агент пише і запускає автотест у браузері — Playwright. Головне — відрізнити тест, який справді ловить дефекти, від «зеленого, але порожнього». Тому тест перевіряють навмисно внесеним дефектом, а набір тестів — мутаційним тестуванням (Vitest і Stryker). L3 завдання QA1 — перша власна функція в шаблоні фіналу, тож це вже крок фінального проєкту QA.
• BA1. Агент перетворює сирий запит на problem statement, гіпотези і відкриті питання, а ви перевіряєте й уточнюєте. Далі — підготовка до розмов зі стейкхолдерами і декомпозиція до сторі з acceptance criteria. Це перші кроки пакета BA у фінальному проєкті.

Що з С6 знадобиться далі:

• QA — реєстр міжсистемних сценаріїв (L2) і контракт стику (L3) стануть входом для API-тестів на занятті QA2, ср 18.11, на тій самій демо-системі. Тому систему заморожено і змінювати її не можна.
• BA — розподіл знахідок на «факт із коду / припущення / питання власнику». Це та сама техніка discovery, лише джерело інше: замість коду — сирий запит, нотатки і відгуки.
• Фінальний проєкт — не відкладайте. Заняття вашої групи — кроки проєкту. Тема — у c6.md, розділ 5. Шаблон не запускається чи щось незрозуміло — питання в гілку своєї групи в чаті вже цього тижня, а не в грудні.

#П'ять речей, які забираєте

Слайд 273

Кожен пункт — один із блоків заняття, і кожен перевіряється в завданні С6.

Докладніше по пунктах:

• 1 — розділи 2 і 4. Коли документації немає, правда — у коді. Але це правда про те, що є, а не про те, що задумано. Тому AS-IS ви описуєте окремо, а TO-BE — окремо, як пропозицію.
• 2 — розділ 2 і демо 1. Агент охоче переказує коментар над функцією чи пояснює її за назвою, а код може робити інше. Правило С1–С5 «біля кожного твердження — джерело» в С6 звучить так: файл і функція. Кілька тверджень ви перевіряєте самі: відкрити файл, Ctrl+F за назвою функції чи числом, прочитати рядок. Коментар над кодом — не доказ: порівняйте, що каже коментар і що робить код. І спитайте, хто викликає функцію: функція, яку ніхто не викликає, не працює, хоч би що в ній було написано.
• 3 — розділ 3 і демо 2. Чек-лист з 11 питань до стику і карта інтеграцій: для кожного стику — хто кого викликає, яким способом, що передає, як приймач перевіряє відправника і що буває при помилці. Кожен сервіс окремо «працює», а повідомлення губиться між ними.
• 4 — розділ 3 і демо 2. Діаграму пише агент, але це такий самий текст: її можна звірити з кодом, виправити і порівняти версії в diff. Найчастіша помилка — напрямок стрілки: хто кого насправді викликає.
• 5 — розділ 4 і демо 3. Агент і аналітик знаходять поведінку, а вирішити, правило це чи дефект, може лише власник — як задачі «Ухвалити рішення: …» в С3–С5. Для QA те саме: контракт AS-IS не «виправляє» поведінку мовчки. Де вона схожа на дефект, у контракті поруч стоять AS-IS і TO-BE як пропозиція.

Де кожен пункт перевіряється в завданні С6:

#Ресурси

Слайд 274

Де переглянути діаграми і перевірити YAML — у README проєкту С6, розділ «Mermaid і OpenAPI»:

• Mermaid — перегляд файлу у вашій копії на gitlab.com, VS Code з розширенням для перегляду Mermaid у Markdown або mermaid.live. mermaid.live — публічний сервіс: для демо-системи можна, для робочих діаграм — лише за політикою компанії. Діаграма не відкривається — покажіть агенту текст помилки і попросіть виправити синтаксис. Часта причина — дужки, лапки чи «» у тексті вузла без лапок навколо: A["текст (з дужками)"].
• OpenAPI — перевірте YAML валідатором, наприклад Swagger Editor: вставили YAML — помилки показано ліворуч. Підійде й будь-який інший валідатор. Який саме і що він показав, напишіть у l3-qa-contract-notes.md: бал L3 QA дають за перевірку, а не за інструмент.

Питання між заняттями — у Telegram-чат когорти, гілки QA і BA.

#Питання

Слайд 275

Типові питання про завдання С6 і короткі відповіді. Про фінальний проєкт — у розділі 6.

Я не програмую — впораюся? Так. Код ви не пишете: агент читає його і перекладає мовою аналітика й тестувальника, а ви перевіряєте джерела — відкрити файл, Ctrl+F за назвою функції.

Систему треба запускати? Ні. BA лише читають код. QA — за бажанням: Node.js 20 або новіший, npm install не потрібен; як запустити — system/HOW-TO-RUN.md. На занятті QA2 запуск знадобиться.

Де запускати агента? У корені своєї копії ai-qa-ba-c6, а не в submissions/: агенту потрібна тека system/. Межі — у кожному промпті: лише system/ і submissions/<username>/, інших тек не читати, у system/ нічого не змінювати, результати писати лише у свою теку.

Агент просить прочитати чужу теку в submissions/ чи examples/. Відхиліть: там чужі роботи, а скопійований результат не зараховується. Агент змінив файл у system/ — поверніть його (git restore system/) і в MR не додавайте.

Лише чат у браузері? Можна: файли коду з system/services/ — вкладеннями або текстом, кожен під заголовком зі шляхом. Джерело — так само «файл і функція». У звіті — рядок «умови чату», як у С5.

Можна взяти робочий код компанії? Ні. У С6 — лише демо-система.

Фокус-питання — можна інше? Лише свого варіанту: варіант — за першою літерою прізвища, як у С1–С5. За фокус-питання чужого варіанту ця частина отримає 0 з 2.

Який у мене модуль L2 BA? За парністю номера варіанту: непарні — модуль А, парні — модуль Б; таблиця — у README проєкту С6. Переадресацію розібрали в демо 3a, тому як модуль L2 вона не підходить.

L3 QA — можна взяти контракт з демо? Ні: контракт запиту за даними отримувача був у демо 3b. Стик L3 QA — webhook POST /v1/events сервісу сповіщень.

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

Діаграма Mermaid не відкривається. Зміст зараховується, але попросіть агента виправити синтаксис і відкрийте діаграму хоча б в одному переглядачі з README.

Свої правила С5 — підключати? За бажанням, без балів: першим повідомленням сесії або особистим файлом правил агента. Файл правил у корінь копії не комітьте.

Чому в BA пізніший строк? Бо розбір — на занятті вашої групи: QA1 — 04.11, BA1 — 11.11.

Інші питання — у Telegram-чат когорти, гілки QA і BA.