сувора QA конференція
AI в тестуванні

“I owe you an apology”, – написав мені AI-агент після того, як, оновлюючи дизайн одного документа, випадково видалив два інших. Дуже ввічливо. І абсолютно марно: файли від вибачення не повернулися.
Саме так виглядає нова реальність: AI уже не просто відповідає на запитання – він запускає інструменти, змінює системи та ухвалює рішення з цілком реальними наслідками.
У цій доповіді ми розберемо, що може піти не так, коли AI-агент отримує автономність: надто широкі дозволи, неконтрольовані дії, self-approval, дрейф, нескінченні цикли та непередбачувані витрати. А головне – що необхідно перевірити до його виходу в продакшн: межі автономності, human oversight, observability, контроль вартості, evidence trail і справжню кнопку Stop.
Ваш AI-агент уже у продакшні. Але чи справді це хороша новина?

LLM та AI-інструменти вже стали частиною нашої роботи. Якщо для розробників їх використання виглядає досить очевидним, то для QA часто виникає питання: що робити далі після першого промпту?

У цьому Майстеркласі ми вирушимо на невелику секретну місію та розберемося, що таке SKILLS, MCP та AI-агенти, як вони працюють разом і чим можуть бути корисними для тестувальника. Також подивимося, як підключати зовнішні системи, зокрема TMS, та використовувати їх у реальних робочих сценаріях.

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

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

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

Як не стати жертвою AI-slop

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

Розберемо CLAUDE.md та AGENTS.md, Rules, та nested інструкції: що в них записувати, як підтримувати їх актуальними й коли виносити інструкції у вкладені файли для складних модулів, та як будувати карту проекту.

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

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

Покажу, як поєднати ці практики, налаштувати verification loop, щоб агент отримував результати перевірок і виправляв помилки під час виконання задачі; збирати лог роботи й використовувати його для learning – оновлення інструкцій, перевірок і самого процесу.

AI-асистенти вже вміють писати тест-кейси, аналізувати вимоги, готувати артефакти й допомагати QA-командам рухатись швидше. Але в якийсь момент у кімнату заходить меркантильна підрахуйка і ставить неприємне питання: а скільки користі ми насправді отримали?

“AI допоміг” звучить добре. “AI зекономив нам час” звучить ще краще. Але без зрозумілої методики це легко перетворюється на відчуття продуктивності, яке ніхто не може перевірити.

У цій доповіді я покажу практичний підхід до вимірювання ROI агентного AI-асистента в QA та BA-процесах. Не через абстрактні обіцянки, не через красиві демо і не через віру в магію промптів, а через human-in-the-loop модель, де людина не зникає з процесу, а залишається reviewer, decision-maker і quality gate.

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

Це доповідь про те, як перейти від “нам здається, що AI корисний” до “ми можемо це порахувати”.

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

– AI не замінює експертизу – він дозволяє їй масштабуватися.
– Ми не переписали STLC – ми iнтегрували AI на кожному його етапі.
– Практичний досвід створення AI-екосистеми для QA департаменту.

Нове бачення полягає в тому, що замість кількох БА або ПМ на продакт дзвінках (та посадах) присутні ноуттрекери. Після дзвінка ноутси обробляє налаштований АІ агент який з цього формує запити/фічі/задачі. Формує список задач, питань та ін. Сформований список агентом передається на апрув причетним особам які підтверджують що саме такі задачі і в такому приорітеті вони хочуть бачити. Далі агент передає цей список відповідальній особі (одному БА або ПМ), який запускає процес написання задач. Готові задачі передаються в роботу.

Про довіру до AI-generated артефактів, дріфт, та відповідальність людини за результат.

Гості панельної дискусії:
– Марина Дідковська, Senior Director в EPAM Systems
– Володимир Обрізан, founder of Testinel
– Михайло Чуб, QE Director в Tieto Ukraine
– Павло Сафонов, senpai