Claude Code: базовий воркфлоу для QA

Чим термінальний агент на кшталт Claude Code відрізняється від звичайного чат-бота?

Чат повертає текст — далі копіювати й запускати доводиться самому; агент замикає цю петлю сам. У нього є інструменти (tools): читати й правити файли, виконувати команди в оболонці, ганяти тести, працювати з git. Через це він не радить, а діє — і одразу спостерігає наслідок своєї дії: вивід ранера, повідомлення компілятора, готовий дифф. Далі він враховує це спостереження й коригує роботу, тобто крутить цикл «дія — спостереження — корекція», а не видає один статичний блок коду. Для QA це означає виконавця, що сидить прямо в репозиторії автотестів і бачить реальні падіння, а не абстрактного порадника.

Що таке сесія і навіщо її вміти зберігати й відновлювати?

Сесія (session) — це одна безперервна розмова з агентом разом з усім накопиченим контекстом: історія повідомлень плюс усе, що агент за цей час прочитав і змінив. Контекст живе в обмеженому вікні, тож нескінченно нарощувати одну розмову не можна — довгі задачі варто розбивати на підходи. Claude Code вміє зберігати сесію й піднімати її пізніше (claude --continue, claude --resume), щоб одна задача пережила кілька заходів без утрати контексту. Практичний виграш для QA: почав розбір флакі-тесту ввечері, повернувся вранці — агент пам'ятає, на чому спинилися, замість того щоб пояснювати все спочатку.

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

Дозволи (permissions) — це запобіжник між агентом і незворотними діями в терміналі. Агент технічно може виконати будь-яку команду, тож саме дозволи стоять між тобою й випадковим видаленням файлів чи пушем не в ту гілку. Читання (перегляд файлів, grep, пошук) стан не змінює й нічого не псує, тому йде без запиту. А от правка файлу, довільна bash-команда чи git push за замовчуванням спершу питають дозволу, бо ціна помилки тут висока. Це і є головна точка контролю: людина санкціонує кожну потенційно небезпечну дію, поки не переведе агента в менш суворий режим свідомо.

Які є режими дозволів і як вони перемикаються?

Базових режимів три, і Shift+Tab гортає їх по колу (окремі додаткові режими для автономних запусків тут не чіпаємо). default — агент питає перед кожною зміною стану, це найобережніший режим. acceptEdits — агент авто-приймає правки файлів, але довільні команди все одно виносить на підтвердження. plan — режим лише для читання: агент нічого не змінює взагалі, тільки досліджує код і складає план. У статус-рядку видно активний режим (наприклад, позначку про plan-режим), тож завжди зрозуміло, наскільки агент зараз «розв'язаний». Вибір режиму — це вибір, скільки контролю віддати: на чужому чи проді лишають default, на своїй пісочниці можна попустити віжки.

Що дає plan-режим і чому виправити план дешевше, ніж виправити дифф?

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

З чого складається сильна постановка задачі для агента?

Якість результату майже цілком визначається постановкою, бо на розмиту задачу агент відповідає вгадуванням. Сильна постановка тримається на трьох речах: що саме зробити, критерії приймання (acceptance criteria — за яких умов задачу можна вважати виконаною) і обмеження (яким інструментом користуватися, чого не чіпати). Плюс явна вказівка на потрібні файли — у Claude Code це роблять через @, наприклад @tests/login.spec.ts, щоб агент одразу підтягнув релевантний контекст, а не шукав наосліп. Без критеріїв приймання агент сам вирішить, що вважати успіхом, і легко вгадає не так — отримаєш красивий, але не той тест. Проста евристика: якщо постановку можна прочитати двома способами, агент вибере не твій.

Навіщо файл CLAUDE.md і що станеться без нього?

CLAUDE.md — це місце, куди виносять постійні конвенції проєкту: house-стиль назв, підхід до локаторів, структуру page object'ів, команди ранера. Агент читає його автоматично на старті сесії, тож ці правила не треба повторювати в кожному промпті. Без нього агент вигадує конвенції на льоту — і вони систематично розходяться з вашими: він може назвати метод не в тому стилі, послатися на неіснуючий хелпер чи вигаданий селектор. Тобто відсутність CLAUDE.md — це не «агент не знає проєкту», а «агент упевнено імпровізує там, де мав дотримуватися правил». Для команди це разова інвестиція, що прибирає цілий клас однакових зауважень на рев'ю.

Опиши цикл «тести → фейли → фікс». Чому саме він відрізняє агента від чата?

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

Головна пастка ітераційного циклу: чому «зелено» не означає «правильно»?

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

Як ти контролюєш якість AI-згенерованого тесту?

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

Чому для QA git — це головна точка контролю, а не побічна деталь?

Claude Code працює з git як звичайний інженер: дивиться статус і дифф, робить гілки й коміти, через gh створює pull request'и. Для QA коміт — це чекпоінт: якщо агент пішов не туди, ти відкочуєшся до попереднього стану замість ручного розгрібання наслідків. Тому дисципліна проста й непорушна: працювати в окремій гілці, а не в основній; читати дифф перед кожним комітом; не пушити у спільну гілку без перегляду; лишати осмислені меседжі, щоб історія читалася. Дифф — це саме те місце, де «агент нагенерував купу коду» перетворюється на «я розумію й свідомо приймаю кожен рядок». Без цієї звички швидкість агента обертається швидким накопиченням коду, який ніхто не переглянув.

Агент полагодив локатори після зміни UI. На що дивитися перед тим, як приймати?

Агент схильний хапати найпростіший локатор, який працює прямо зараз: позиційний nth, прив'язку до видимого тексту чи до згенерованого CSS-класу. Проблема в тому, що «працює сьогодні» й «стабільний» — різні речі: такі локатори кришаться на наступному білді, бо позиція елемента, текст і хеш класу змінюються. Тому дифф локаторів дивлюся прицільно: чи прив'язка йде до стабільного якоря — ролі з доступним іменем або data-testid, — чи до крихкого. Якщо бачу .btn_a1b2c3 >> nth=2, замінюю на getByRole або getByTestId і скеровую агента робити так надалі. Це саме та зона, де експертиза в тест-дизайні незамінна: агент напише робочий селектор, а стійкий — тільки під наглядом.

Агент проаналізував падіння тесту й упевнено назвав діагноз. Чи можна одразу заводити баг?

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

Що робити, коли агент зробив геть не те?

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

Чому не варто вмикати авто-прийняття на спільному чи прод-стенді, і як дозволи задають у CI?

acceptEdits пришвидшує роботу, але прибирає точку контролю саме там, де ціна помилкової дії найвища — на спільному стенді чи проді помилкова команда б'є не тільки по тобі. Швидко отримати неправильне не краще, ніж повільно отримати правильне, тож на чужому середовищі лишають default і читають дифф перед застосуванням. У CI ситуація інша: там агент працює неінтерактивно (headless), клацати підтвердження нікому, тож дозволи задаються конфігурацією заздалегідь — що можна, а що ні, вирішено до запуску, а не в діалозі. Практичне правило: рівень автономії має відповідати ціні помилки в конкретному середовищі, а не зручності. Пісочниця пробачає, спільний стенд — ні.

Три ситуації з робочого дня AQA, де воркфлоу вирішує, чи агент зекономить час, чи згенерує проблему: слабка проти сильної постановки задачі, plan-режим як точка рев'ю наміру, і читання диффу, коли зелений тест бреше. Скрізь — що дивитися й чому.

Кейс 1. Постановка задачі: чому одна фраза дає не той тест

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

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

Що дивитися й чому:

• Критерії приймання — це те, що агент перевірятиме асертом. Немає критеріїв — немає й осмисленого expect; агент лишить тест, який «проходить», бо нічого не стверджує.
• @-посилання економлять раунди вгадування. Показавши наявний тест і page object, ви задаєте стиль і патерни асертів, і агент продовжує їх, а не пише з нуля.
• Конвенції місце в CLAUDE.md, не в кожному промпті. Одноразовий запис про data-testid і house-стиль назв прибирає цілий клас однакових зауважень на рев'ю.

Кейс 2. Plan-режим: ловимо неправильний намір до появи коду

Задача: «тест перевіряє, що після оплати замовлення переходить у статус paid». Перед тим як пускати агента до коду, перемикаємо його в plan-режим (Shift+Tab, у статус-рядку видно позначку plan) і читаємо запропонований план.

План:
1. Замокати весь бекенд (усі /api/*) фікстурами.
2. Застабити відповідь платіжного шлюзу як success.
3. Клікнути "Оплатити", дочекатися редіректу.
4. Перевірити, що на сторінці видно текст "Оплачено".

Тут видно проблему саме на рівні наміру, ще до єдиного рядка коду. Пункт 1 мокає весь бекенд — тоді перехід у статус paid рахує мок, а не реальна логіка застосунку, і тест зеленітиме, навіть якщо продукт зламано. Правити треба напрямок: підмінити лише зовнішній платіжний шлюз (він недетермінований і платний), а власний бекенд лишити живим. Уточнюємо постановку й переганяємо план — і лише потім даємо апрув.

Уточнення: мокати ТІЛЬКИ зовнішній платіжний шлюз (POST /gateway/charge).
Статус замовлення читати з реального API GET /orders/:id — це і є перевірка.

Що дивитися й чому:

• Виправлення в плані коштує один рядок тексту. Той самий недогляд, виловлений уже в диффі, — це відкат коміту й повторний прогін; правити намір на порядок дешевше.
• «Замокати весь бекенд» — типовий обхідний шлях. Агент прибирає недетермінованість найгрубішим способом; ваша робота — звузити мок до справді зовнішньої залежності.
• Апрув плану = апрув напрямку. Схвалюєте не текст, а рішення «що вважати перевіркою»; для джуна це рев'ю підходу до того, як з'явився код.

Кейс 3. Читання диффу: коли зелений тест бреше

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

 test("оновлення профілю зберігає нове ім'я", async ({ page }) => {
   await page.goto('/profile');
-  await page.getByTestId('name-input').fill('Ірина');
-  await page.getByTestId('save-profile').click();
-  await expect(page.getByTestId('profile-name')).toHaveText('Ірина');
+  await page.getByRole('textbox').nth(1).fill('Ірина');
+  await page.locator('.btn_9f8e').click();
+  // await expect(page.getByTestId('profile-name')).toHaveText('Ірина');
 });

Тест зелений з двох причин, і обидві погані. По-перше, агент закоментував єдиний змістовний асерт — тепер тест лише клікає й нічого не стверджує, тож пройде завжди. По-друге, стійкі локатори data-testid замінено на крихкі: позиційний nth(1) і згенерований клас .btn_9f8e, які зламаються на наступному білді. «Зелено» тут не означає «полагоджено» — означає «перестало падати». Повертаємо асерт і стабільні якорі.

test("оновлення профілю зберігає нове ім'я", async ({ page }) => {
  await page.goto('/profile');
  await page.getByTestId('name-input').fill('Ірина');
  await page.getByTestId('save-profile').click();
  // асерт лишається — саме він робить тест перевіркою, а не кліком
  await expect(page.getByTestId('profile-name')).toHaveText('Ірина');
});

Що дивитися й чому:

• Закоментований чи прибраний асерт — перше, що шукати в диффі. Тест без expect зелений завжди; ціль циклу «зелено» штовхає агента саме до цього обхідного шляху.
• getByRole('textbox').nth(1) і .btn_9f8e — крихкі за побудовою. Позиція й хеш класу змінюються щобілда; стійкі якорі — роль з доступним іменем або data-testid.
• Дифф — це місце, де ти реально приймаєш роботу. Якби довіряли кольору прогону, у сюїту поїхав би тест, який нічого не перевіряє й розсиплеться на першому релізі UI.

Агент, а не чат

• Можу пояснити різницю агент vs чат-бот: агент має інструменти (файли, оболонка, тести, git), діє й спостерігає результат, а не лише генерує текст.
• Розумію цикл «дія — спостереження — корекція» і чому саме він дозволяє агенту довести зміну до працездатного стану в одній сесії.

Сесія і дозволи

• Знаю, що сесія — це розмова разом з накопиченим контекстом, і чому довгі задачі варто розбивати (обмежене вікно контексту).
• Можу відновити роботу з місця зупинки через claude --continue / claude --resume.
• Розумію, чому читання йде без запиту, а зміна стану (правка файлу, bash, git push) потребує дозволу.
• Знаю три базові режими дозволів default vs acceptEdits vs plan і що Shift+Tab перемикає їх по колу.
• Знаю, що в CI агент працює неінтерактивно (headless), тож дозволи задають конфігурацією заздалегідь, а не клацанням.

Постановка задачі та контекст

• Можу назвати три складники сильної постановки: що зробити, критерії приймання (acceptance criteria), обмеження.
• Знаю, навіщо вказувати файли через @ і чому це підтягує потрібний контекст замість гадання.
• Розумію роль CLAUDE.md: постійні конвенції читаються на старті сесії, без нього агент імпровізує й посилається на неіснуючі хелпери.

План перед виконанням

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

Цикл тести → фейли → фікс

• Можу описати ітерацію: зміна → прогін тестів → аналіз фейлу → фікс → повторний прогін до зеленого.
• Тримаю в голові інваріант зелено ≠ правильно: зелений тест без осмислених асертів проходить завжди.
• Знаю, що перевірка диффу й самих асертів — крок, який не делегується агенту.

Git як точка контролю

• Розумію, що коміт — це чекпоінт для відкату, а не формальність.
• Дотримуюся дисципліни: окрема гілка, читання диффу перед комітом, жодного пушу у спільну гілку без перегляду, осмислені меседжі.

QA-сценарії та пастки

• Розумію інваріант фейл автотесту ≠ баг застосунку: діагноз агента підтверджую ручним відтворенням флоу.
• Можу відрізнити крихкий локатор (nth, згенерований клас, прив'язка до тексту) від стійкого (роль, data-testid).
• Розумію червоний прапорець для інтерв'юера: сліпа довіра до зеленого прогону й невміння показати, де саме людина перевіряє роботу агента.