Як змінилася роль QA-інженера з приходом ШІ: думки ліда та реальний досвід команди

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

Привіт, DOU!

Мене звати Денис, і я QA Lead у SharksCode. Ми з командою будуємо B2B-платформи. Сьогодні я хочу поговорити про те, як ми вирішили «подружити» тестувальників з ШІ.

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

Ми розпочали системне впровадження ШІ на початку 2026 року. Нас мотивувала оптимізація ресурсів. Коли команда витрачає значну частину часу на шаблонне написання тест-кейсів або монотонне рев’ю документації, це сповільнює розвиток продукту. Ми вирішили, що рутину має виконувати машина, а інженер — зосередитися на тестуванні складної логіки продукту .

Після впровадження ШІ-інструментів наша команда заощадила близько 25% робочого часу на перевірці ТЗ і створенні тест-кейсів. Усе відбувається у реальному production-середовищі з реальними дедлайнами. Цей показник одразу руйнує дві протилежні помилкові думки: «ШІ ще не готовий і нічого не змінює» та «ШІ скоро замінить усіх тестувальників». Реальність же значно цікавіша та складніша за обидва ці наративи.

Далі поговоримо про те, що саме змінив штучний інтелект у щоденній роботі QA-інженера і як на ці зміни реагувати, щоб залишатися затребуваним фахівцем через 2–3 роки?

Що конкретно змінив ШІ в роботі QA? Реальна картина ринку

Україна піднялася на 40-те місце у світі в рейтингу AI Readiness Index 2025. Проте навіть у цьому контексті впровадження ШІ в українських QA-командах у 2026 році є чимось середнім між масовою революцією і поодинокими експериментами.

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

Де і як сьогодні ШІ застосовується в реальних командах

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

Ринок зараз переповнений менторами-ентузіастами, які класно розповідають про «ігри» з промптами. Проте вони майже не дають системних знань безпосередньо для QA. Це підтверджує критично малу кількість сертифікованих фахівців. Спеціалістів з акредитацією ISTQB Testing with Generative AI в Україні насправді одиниці. Ми навчилися користуватися інструментом на рівні інтуїції, але ще не побудували навколо нього професійний стандарт.

Генерація тест-кейсів та review вимог

Щоб не говорити абстракціями, ми вирішили поміряти все в «чистих годинах». Один з наших QA-підрозділів узяв в роботу пул із чотирьох схожих задач. Вони йшли в одному спринті.

Раніше за нашими стандартними оцінками на аналіз ТЗ і написання тест-кейсів для цих задач пішло б щонайменше 24 години (стабільно по 6 годин на кожну). А ось як реальний час розподілився, коли колеги підключили зв’язку NotebookLM + Claude:

• Налаштування «бази»: ~1 година пішла на те, щоб закинути в NotebookLM загальну доку по проєкту. Це одноразова дія, щоб ШІ розумів контекст.
• Дока під задачі: ~30 хвилин забирало завантаження специфікацій саме під ці 4 таски.
• Промптинг та генерація: ~1-2 години на ітерації з запитами, поки ШІ не видав потрібний результат.
• Рев’ю та перенесення в TMS: ~14.5 годин (десь 2 повних робочих дні).

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

Що отримали в результаті?

Замість 24 годин за планом, підрозділ витратив сумарно 17 годин (разом із першим налаштуванням) ну і 16 годин, якщо система була вже налаштована. Чиста економія — 7 годин робочого часу (а це майже 25-30% ефективності).

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

Автоматизація рутинних перевірок (регресія, smoke)

Автоматизація базових регресійних і smoke-перевірок сьогодні є реальною практикою. Однак спроба «напромптити» архітектуру автотестів веде до технічного боргу. Без хард-скілів QA такий код перетворюється на некероване «спагеті» вже за місяць. ШІ може написати скрипт. Проте йому не під силу спроєктувати якісну та надійну тест-архітектуру.

Аналіз логів і пошук патернів у дефектах

ШІ демонструє реальну перевагу у пошуку «голки в стозі сіна» після падіння тестів. У найближчі 2–3 роки інструменти знаходитимуть помилку і одразу видаватимуть готовий Root Cause Analysis. QA перестане бути «руками» і перетвориться на архітектора якості. До цього я і моя команда намагаємось прийти в найближчий час.

Онбординг і бази знань на LLM

Smart Onboarding на базі NotebookLM став одним із найбільш вражаючих кейсів для команди. ШІ перетворився на провідника по проєкту для новачків, що дозволило їм виходити на пік ефективності в 1,5–2 рази швидше без відволікання Senior-ів. Це конкретна вимірювана цінність для бізнесу.

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

Новий співробітник буде користуватися ШІ, почне розбиратися в продукті швидше і прибере основні питання ментору (Senior QA). Це зекономить час як і Senior QA так і співробітника, який проходить онбордінг

Навички, що втрачають цінність

Є простий тест. Якщо задачу можна вирішити, «нагодувавши» ШІ чітким промптом і отримавши готовий результат, то задача перестає бути навичкою конкурентної переваги для QA-інженера. Це означає, що ринок перестає платити за неї як за окрему компетенцію. Навичка нікуди не ділася, просто стала само собою зрозумілою. Так само, як колись перестали цінувати вміння друкувати на машинці.

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

• Ручне написання очевидних happy-path кейсів. Ми делегуємо написання позитивних сценаріїв та чек-листів за вимогами Claude Sonnet або якщо це пов’язано з добре описаним ТЗ то в зв’язці Cloude+Notebook LM. Людина залишається лише рев’юером. За 2–3 роки ця робота перейде до ШІ повністю.
• Ведення документації «для галочки». Рутинне шаблонне оформлення технічної документації (опис кроків, стандартні формулювання, заповнення полів) ШІ виконує швидше і без втоми. Це не означає, що документація перетворюється на стандарт, який людина задає та валідує.
• Copy-paste шаблонних описів дефектів. Йдеться про генерацію структурованих баг-репортів та шаблонне заповнення.

Навички, що залишаються незамінними

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

Глибоке розуміння продукту та доменної логіки

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

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

Критична валідація результатів ШІ

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

Роль змістилася від виконання перевірок до арбітражу істини, де людина ставить під сумнів кожен результат нейромережі. Це потрібно, аби не допустити накопичення прихованого технічного боргу. Без хард-скілів QA не зможете відрізнити ефективне рішення від «професійної ілюзії». База знань для QA завжди первинна.

Системне мислення та ризик-аналіз

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

Якщо баг пропущено через хибний ШІ-тест-кейс, відповідальність понесе QA-інженер, який не провів якісного рев’ю результату.

Exploratory testing і нестандартні сценарії

ШІ працює в межах описаних даних. Тільки людина може знайти на рівні інтуїції або складного досвіду користувача баг там, де «все логічно», але «щось не так». Це суто людська суперсила.

Так само Security та Privacy. Передача конфіденційної документації або персональних даних у відкриті моделі може стати джерелом витоку. Тут команда працює виключно «своїми мізками» або на локальних ізольованих інструментах.

Навички, яким треба вчитися зараз

На мою думку, є три компетенції, які відрізняють QA, що зростає, від того, хто «завис» на старих підходах.

Prompt Engineering для QA-задач

Prompt Engineering — це про вміння чітко ставити технічне завдання. Спеціаліст повинен оволодіти мистецтвом формулювати думку так, щоб ШІ видавав готовий до роботи результат. Без розуміння цієї специфіки робота стає заплутаною.

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

Оцінка якості та помилок ШІ-виводу

У нас на проєкті під час оцінки якості встановлюють «рамки дозволеного» і перевіряють, чи не виходить ШІ за них. Часто для цього використовують іншу, більш потужну модель для верифікації.

Наприклад, якщо ШІ генерує баг-репорт, спеціалісти дивляться на наявність усіх обов’язкових блоків згідно зі стандартами компанії. Це про технічну коректність.

Адаптивність до великих обсягів знань та вміння бачити нові точки інтеграції ШІ у робочі процеси QA

QA повинні бути здатні критично валідувати результат на відповідність архітектурі та бізнес-логіці проєкту. Тому Prompt Engineering у синергії з фундаментальною базою тестування має бути тим, що відрізняє «архітектора якості» від «оператора чату».

Пастки та антишаблони впровадження

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

«Інноваційний театр»: ШІ заради ШІ

Спроба «покрити все і вся» одним махом часто є найпоширенішою помилкою. У цьому контексті ШІ сприймається як магічна кнопка, котра миттєво замінить цілі процеси. Ринок зараз нагадує «дикий захід», де багато шуму, самопроголошених менторів, але дуже мало фундаментальної експертизи.

Реальна стратегія ж виглядає інакше. Спочатку потрібно автоматизувати дрібну рутину, валідувати результати і лише після цього масштабувати на складніші задачі. Намагання перескочити етап «притирання» призводить до хаосу та втрати контролю над якістю.

Джуни без бази + ШІ = некерований хаос

Я свідомо обмежую в команді використання ШІ для Junior-спеціалістів. Це питання виживання їх як професіоналів. Ось що відбувається у протилежному випадку:

• Атрофія хард-скілів. Якщо джун із першого дня делегує все нейронці, він не вчиться думати. Без розуміння «бази» неможливо відрізнити якісний результат від галюцинації ШІ.
• Ілюзія компетентності. ШІ не дає досвіду. Мозок не проходить шлях дослідження. У результаті спеціаліст залишається «оператором чату» і не прогресує до рівня інженера.

Джун, якому дозволили повністю покластися на інструменти зі штучним інтелектом з першого дня, стає людиною без фундаменту. Такий спеціаліст нездатен критично оцінити те, що підказує ШІ.

Прихована вартість: очищення даних, моніторинг, підтримка

Впровадження ШІ коштує дорого. За кожним «зекономленим» часом стоять витрати на підготовку даних, створення промптів, моніторинг якості виводу та підтримку системи. Ці витрати часто недооцінюють на старті.

Переоцінка точності: відповідальність за баги зі ШІ-кейсів

У випадку, коли штучний інтелект видав хибний результат, за наслідки несуть відповідальність QA-лід та QA-інженер. Якщо баг пропущено через хибний ШІ-тест-кейс, це означає, що інженер не провів якісне ревʼю. Єдиним реальним запобіжником у цій системі є кваліфікація людини.

QA-інженер епохи ШІ — хто це?

На мою думку, портрет спеціаліста, якого шукатимуть через 2–3 роки, формується вже зараз.

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

Ключові характеристики такого спеціаліста:

• Технічна глибина. Спеціаліст розуміє архітектуру та ризики.
• Prompt Engineering + критична валідація ШІ-виводу як базові компетенції.
• Системне мислення. Спеціаліст пов’язує якість продукту з бізнес-ризиками.
• Безперервне навчання. Адаптується до нових інструментів без страху.
• Відповідальність. Розуміє, що ШІ — інструмент, а за баги несе відповідальність саме він.

Конкретні кроки розвитку: Junior

Сьогодні джун має вміти використовувати ШІ як інтерактивний тренажер для прискорення навчання, але обов’язково з опорою на класичну базу. Якщо ви тільки заходите в професію, я б радив такий шлях.

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

Не бійтеся підключати NotebookLM. Це чудовий інструмент, щоб розкласти складні стандарти на кшталт ISTQB на зрозумілі частини й вчитися інтерактивно.

Обовʼязково навчіться ставити ШІ чіткі технічні запити і критично перевіряти те, що він видає. Модель упевнено підсовує і правильне, і хибне однаковим тоном, тож перевірка має бути експертною.

Памʼятайте, що ШІ може бути персональним ментором і тренажром, але не заміною власному мисленню. Думати все одно доведеться.

Конкретні кроки розвитку: Middle

Якщо джун вчиться не покладатися на ШІ сліпо, то на рівні middle задача змінюється. Тут уже треба навчитися робити з ним систему. Що це означає на практиці?

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

Важливо вміти вимірювати й обґрунтовувати ефективність ШІ-інструментів. У SharksCode ми це робимо через спринти. Так одразу видно, що реально змінилося в швидкості й якості.

Також тут не обійтися без прокачки ризик-аналізу. Це саме та зона, яку ШІ замінити не може. Оцінити, де продукт реально вразливий і на чому зосередити тестування, здатна тільки людина з досвідом.

Конкретні кроки розвитку: Senior

А от на рівні senior усе виходить на інший масштаб. Тут потрібно замислюватися над тим, як вибудувати середовище, де ШІ посилює команду. Ви починаєте вибудовувати стратегію інтеграції ШІ у QA-процеси на рівні всієї команди й проєкту. Тобто, думаєте системно.

Окремо й дуже свідомо ви визначаєте зони, де ШІ заборонений. Наприклад, у Security, Privacy, Exploratory Testing сліпа довіра до моделі коштує надто дорого.

Паралельно варто підвести під усе це системну базу, щоб структурувати знання, які до цього накопичувалися шматками. Сертифікація на кшталт ISTQB Testing with Generative AI або навіть ISTQB Testing AI тут гарний орієнтир.

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

Висновок

ШІ не замінить QA-інженера, але змусить його еволюціонувати.

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