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

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

Щоб з’ясувати, як ШІ впливає на роботу початківців в ІТ, DOU запускає нову рубрику — «ШІ vs Джуніори». У першому випуску досліджуємо QA-напрям.

Чи конкурує ШІ з джуніорами в QA? Як розвиток штучного інтелекту впливає на пошук початківців? З якими завданнями джунів він точно не впорається? Джуніор + ШІ — чи погано це для компанії? Щоб відповісти на ці запитання, ми поспілкувалися з досвідченими QA-фахівцями.

Серед них:

• Олександр Хотемський, Engeneering manager та QA practice lead в Doxy.me;
• Олексій Остапов, AQA Engineer в nCube;
• Олег Грудко, QA manager в Omilia Conversational Solutions;
• Свят Логин, Head of Engineering Excellence & Quality в EVO;
• Геннадій Міщевський, колишній Lead SDET у FutureLog.

🫡 Які завдання в QA виконує ШІ

За даними зимового зарплатного опитування DOU, 74% українських QA використовують ШІ-інструменти у своїй роботі. Цікаво, що найбільше — General QA та SDET — по 83%. Трохи менше автоматизатори та мануальники — 81% і 69% відповідно. Найменше ШІ в роботі використовують Embedded QA — 63%.

Опитані експерти зійшлися на думці, що найкраще в тестуванні ШІ може робити рутинні та автоматичні завдання. Свят Логин, Head of Engineering Excellence & Quality в EVO, наводить приклади, що доручають ШІ:

• Написання тест-кейсів. Джунам часто дають створювати або оновлювати тест-кейси — це рутина, яку не люблять досвідчені QA, тож її може виконувати ШІ.
• Перевірка UI та вимог. За чіткого запиту та наявності документації ШІ швидко знаходить невідповідності, які легко пропустити вручну.
• Генерування автотестів за шаблонами. ШІ ефективний у типових BDD-сценаріях, але не підходить для складної логіки.
• Аналіз логів. Якщо вони інформативні, ШІ швидко знаходить баги. «Це, звісно, якщо розробники потурбувались зробити інформативний лог, але і тут ШІ впорається з кількох підходів. Скажіть, який джун і навіть досвідчений QA впорається з прочитанням трейсбеку?» — додає Свят.
• Формування тестових даних, яке раніше могло займати пів години вручну.

Співвідношення завдань, які може виконати ШІ, і завдань тестувальника, варто оцінювати залежно від параметрів роботи. З досвіду Свята Логина, якщо в команді налагоджені процеси, то ШІ може виконувати близько 60% роботи мануальника та близько 30% роботи автоматизатора.

Колишній Lead SDET компанії FutureLog Геннадій Міщевський зазначає, що найбільш корисною є автоматизація «сировини», зокрема — генерування технічної документації до модулів/програм:

«Ти щойно закінчив найцікавішу роботу, і тепер тобі треба описати її людськими словами».

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

«Торік я був суддею на Dev Challenge й дав учасникам завдання — протестувати десктоп-застосунок, який сам написав і навмисно додав у нього баги. Учасники були непоганими тестерами, але мали досвід лише з web або мобільними застосунками. Хоча програма була простою, а баги на поверхні, у середньому звітували лише про 20–30% проблем. І це за кілька днів часу на задачу, яка займає 10 хвилин. Причина — брак контексту: учасники не розуміли, як десктоп-програма взаємодіє з операційною системою, що саме потрібно перевіряти. І навіть запитати у ШІ про це складно, бо не зрозуміло, що саме питати.

Щодо тест-дизайну, то в простих сценаріях ШІ генерує гарні тести, але для складних систем я все ще бачу багато галюцинацій», — пояснює Остапов.

Водночас ШІ поки не здатен виконати жодне завдання повністю, але дуже корисний для часткової автоматизації, зауважує Олександр Хотемський з Doxy.me:

«У Slack з PM відбулася довга дискусія про фічу, а тепер треба завести багу? Просто формулюємо промпт, вставляємо переписку — і за три секунди маємо готовий баг для копіпасту в Jira».

ШІ на практиці вже використовується для кастомної автоматизації через скрипти. QA Manager Олег Грудко наводить приклад бібліотек для обробки тексту й інтеграції з чат-ботами (OpenAI SDK, Hugging Face Transformers). ШІ здатний за кілька годин написати скрипт, який аналізує відповіді системи й порівнює їх з очікуваними.

🦾 Як ШІ вирішує нестандартні сценарії в QA

Наразі ШІ обмежено ефективний у тестуванні нетипових або креативних сценаріїв, діляться співрозмовники. Зокрема, у нього поки що надто вузький доступ до специфічного проєктного контексту. Теоретично, за словами Олександра Хотемського, ситуація може змінитися, якщо він отримає повний доступ до зустрічей, історії багів, внутрішнього листування та інструментів. «Можливо буде побачити за кілька років», — додає Хотемський.

ШІ може запропонувати edge cases, але лише за умови, що має повний доступ до якісної документації або історії баг-репортів, пояснює Свят Логин. У його компанії це дозволено, однак багато хто не готовий відкривати ШІ свої внутрішні дані, бо вважає свій продукт унікальним. Він додає, що прогресивні компанії знають, які дані можна передавати, і обмежують лише конфіденційну інформацію для ШІ. Крім того, є аутсорсингові компанії, яким складніше погодити з компаніями надання даних для ШІ через ті ж умови конфіденційності.

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

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

ШІ не здатен розв’язувати нетипові задачі, оскільки навчений на типових рішеннях з минулого досвіду, вважає Олексій Остапов. У його практиці ШІ не зміг допомогти з новим типом завдань, бо подібного ще не створювали. Він підсумовує: «Коли зʼявиться творчий ШІ — тоді подивимось».

🤷🏻 Які завдання джуна ШІ не зможе виконати

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

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

«Колишній колега розповів: він запустив ШІ-агента, щоб той „пофіксив“ юніт-тести. Формально усі тести стали зеленими, але, переглянувши коміт, він побачив, що агент просто вимкнув один з проблемних тестів. Ось вам і вся „магія“ штучного інтелекту: без людської перевірки він може просто сховати помилку, а не виправити її».

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

• комунікація з командою та уточнення вимог;
• виявлення edge cases, не описаних у документації;
• визначення пріоритетності тестів у складних фічах;
• інтерпретація неоднозначних ситуацій (наприклад, баг чи фіча).

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

🧑🏻‍💻 Чи впливає ШІ на конкуренцію

Щоб бути нині конкурентним у QA, треба «вміти все і мати 15 років досвіду», зауважує Геннадій Міщевський:

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

За його словами, часто компанії хочуть зекономити на джуніорах, додавши зарплатню мідлам:

«Бізнесу, звісно, хочеться економити: мовляв, навіщо платити джуну 700 доларів, якщо ШІ зробить це майже безплатно? Але в перспективі це створює проблеми. Бо джуна потрібно навчати, а це забирає час у сеньйорів. Замість цього компанія може додати мідлу 200 доларів, купити йому інструмент — і він виконає ту ж роботу. Нібито ефективно, але це руйнує ланцюг росту. Без джунів не буде нових спеціалістів».

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

• чітка документація;
• продукт не змінюється щотижня;
• мінімум комунікації та бізнес-впливів;
• є готові фреймворки, інфраструктура CI/CD, де все автоматизовано.

«А на практиці, чи бачили ви компанії з ідеальною докою й повністю автоматизованими процесами? Я б сказав, що джуни, та і старші QA виконують роль „живого клею“, який з’єднує специфікацію, розробницьку команду і реальний продукт», — пояснює фахівець.

Повна заміна джунів можлива не через прорив ШІ, а через рішення компаній скоротити витрати. Компанії можуть локально замінити джунів, що в короткостроковій перспективі посилить конкуренцію на ринку. Але з часом ринок збалансується, бо якщо бракуватиме мідлів, їхні позиції можуть пропонувати джунам, додає Олег Грудко. Він зауважує, що в QA вже сформувався skill gap. Джуни, які вміють ефективно працювати з ШІ, можуть створювати конкуренцію мідлам, а іноді й сеньйорам.

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

Втім, як підкреслюють співрозмовники, всі інженери колись були джунами, тож і зараз важливо, аби було кому навчатися.

🆚 Джун vs ШІ? А може, джун плюс ШІ?

Згідно з опитуванням DOU, найпоширеніший ШІ-інструмент, яким користуються тестувальники — це ChatGPT. Його використовують 70% фахівців. Також поширені GitHub Copilot, Gemini (ex Bard), Claude та інші (Bing AI, Perplexity AI, Codium, Midjourney тощо).

Водночас досвідчені тестувальники, за винятком Manual QA, користуються ШІ-інструментами рідше за новачків, однак звертаються до більшої кількості ШІ-помічників.

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

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

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

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

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

«Один із джунів у нашій команді використовував GPT для генерування SQL-запитів до тестової БД: отримав базовий синтаксис, підставив назви таблиць і колонок — і сформував правильний запит. Це зекономило йому години, які він витратив би на гуглення чи звернення до розробників.

Проте був і зворотний приклад. Інший джун, не розібравшись у згенерованому коді, скопіював інструкцію для API-тесту, яка містила запит на видалення з БД. У результаті він випадково видалив половину тестових даних. Добре, що це була лише тестова інфраструктура, але час на відновлення середовища все одно довелося витратити».

Олександр Хотемський додає: якщо джуніор лише копіпастить, то ризикує залишитися без роботи:

«Можу дати правило, яким сам користуюсь: «Забороняється використовувати аутпут АІ без розуміння цього аутпуту».

🤖 Manual vs Automation — кого замінять швидше

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

З’являться нові професії, які відповідатимуть за більші обсяги роботи. ШІ вже зараз може забрати на себе рутинну частину роботи як у джунів-мануальників, так і у джунів-автоматизаторів.

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

ШІ допоможе розширити межі функціональності тестувальника, наприклад, поєднувати ролі BA, PM і QA, якщо правильно формулювати інструкції та запити:

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

Однак, якщо говорити про досвідчених QA, то, на думку експерта, Manual QA більше в зоні ризику, бо саме вони займаються:

• рутинною роботою: вичитуванням багів у вимогах, написанням тест-кейсів тощо;
• перевірками UI;
• базовими smoke-тестами.

QA Automation, навпаки, стає потрібнішим, бо ШІ не створює з нуля продуману архітектуру автотестів чи CI/CD pipeline. Він може лише писати прості тести без глибини — натиснути, відкрити. У цьому випадку ШІ — асистент, а не замінник.

Олег Грудко вважає, що серед Manual QA ризикують ті, хто виконує лише тест-кейси без глибшого розуміння тест-дизайну. Серед Automation QA — ті, хто обмежується лише «скриптингом готових сценаріїв». Проте більшість адаптуються і додають ШІ до свого інструментарію.

🔍 Що буде з пошуком фахівців

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

Олександр Хотемський вважає, що основні платформи для пошуку фахівців залишаться незмінними:

«Основними каналами й далі залишатимуться DOU, Djinni, LinkedIn. Сам пошук теж буде багато в чому автоматизований. Думаю, скоро зʼявляться спеціальні версії резюме для ШІ та окремо для людини».

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

Олег Грудко переконаний, що джуни, які добре використовують ШІ, зможуть виконувати деякі завдання мідлів. Відповідно у них буде простір для зростання та набуття досвіду. Наостанок додає:

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU