Як має думати QA, щоб залишитися незамінним навіть в епоху штучного інтелекту
Вітаю, спільното! Мене звати Ярослава і сьогодні я хочу поділитися своїми думками й подискутувати з вами на тему того, як має думати QA, яка його роль у майбутньому і чи дійсно ця професія вимре під натиском штучного інтелекту.
Перш ніж ми зануримось у тему, дозвольте розповісти трохи про себе і чому ця тема є дотичною до мене. В QA-напрямі я понад 12 років — і як Senior Product Quality Manager y fintech-компанії, і як ментор, і як спікер. Окрім цього я є Head of QA в London Tech Community, найбільшому ІТ-ком’юніті українців в Лондоні, де ми розбираємо питання працевлаштування і допомагаємо поладнати з міжнародним ринком праці. Це дозволяє мені бачити доволі широку картину того, що відбувається з професією QA Enginner у світі, як на неї впливає штучний інтелект і як змінюються вимоги компаній до кандидатів.
Що відбувається зараз
Почати мені хотілось би з все частіше лунаючого «AI незабаром забере твою роботу». Не скажу, що цей страх є безпідставним, бо вже сьогодні алгоритми малюють, пишуть код, допомагають будувати маркетингові стратегії та робити ще десятки речей, які раніше здавалися виключно людськими. Але якщо подивитися глибше, то QA-інженер не стає «зайвим» — його роль трансформується. І щоб залишатися затребуваним, потрібно змінити спосіб мислення: вийти за межі суто технічної ролі та почати дивитися на свою роботу крізь бізнесову призму.
Чому? Бо більшість компаній сприймає QA-фахівців як виключно технічний ресурс — незалежно від того, чи це ручне тестування, автоматизація, чи змішаний формат. І це формує певний підхід: ми зосереджуємося на відсотку коду, покритого тестами, вимірюємо середній час виявлення дефекту, контролюємо кількість нових багів після релізу і наскільки ми покрили вимоги тест кейсами. І це безумовно корисні показники для внутрішньої оцінки роботи. Але вони не демонструють бізнесу, навіщо QA справді потрібен. І якщо ви як QA-спеціаліст залишите позиціювання своєї роботи лише як технічну функцію, AI-рішення дійсно можуть поступово перебрати більшість ваших задач на себе.
Щоб залишатися цінним у майбутньому, QA має бути не лише «охоронцем якості», а й партнером у досягненні бізнес-цілей, яким він насправді є. Ключ до досягнення цього — впровадження бізнесового мислення і застосування його в комунікації з менеджментом. Тобто це здатність бачити власну роботу крізь призму стратегії компанії: як вона створює цінність, як задовольняє потреби клієнтів, як використовує ресурси. По суті, це фокус на головному рушії прибутку будь-якої організації — клієнтові. Саме для нього ми забезпечуємо якість, автоматизуємо процеси й пришвидшуємо релізи.
Як QA навчитися думати бізнесово
1. Орієнтація на клієнта
QA щодня взаємодіє з продуктом і часто знає його краще, ніж будь-хто інший. Це унікальна можливість передбачати проблеми клієнтів і пропонувати рішення ще до того, як вони з’являться. Відповідно створюючи тест-кейси, потрібно приділяти більше уваги саме користувацьким сценаріям. Прям питати себе: яку цінність ця функція несе клієнтові? У яких випадках він її використовуватиме найчастіше? Що може зіпсувати його досвід?
2. Стратегічне мислення
Як тільки ви почнете мислити як користувач і зрозумієте всі проблемні сторони продукту саме через його погляд, ваша задача — почати показувати це бізнесу. Для цього вам якраз знадобиться розуміння стратегічних пріоритетів і цілей компанії — від місії до квартальних OKR. Дізнайтеся, які цілі зараз стоять перед компанією. Якщо їх не озвучують — запитайте напряму у продакт-менеджера чи керівника. Подумайте, як ваша робота пов’язана з цими цілями. Як проблеми, які ви виявили на першому кроці, пов’язані з цими цілями. Навіть дрібна таска чи баг може підтримувати велику мету.
Наприклад, «додати дисклеймер у попап» насправді допомагає формувати прозорість і довіру користувачів. А це своєю чергою напряму впливає на досягнення такої цілі як покращення NPS чи CSAT, яка може стояти перед компанією. Тому почніть формулювати результати своєї роботи й своїх задач через бізнес-цінність. Замість «перевірив, що після апдейту бібліотеки нічого не крешиться» — «перевірив усунення потенційного регуляторного ризику при генерації PDF-документу».
Цей підхід не лише робить ваш внесок зрозумілішим для менеджменту, а й значно полегшує у майбутньому заповнення свого performance review чи оновлення резюме, бо ви починаєте зосереджуватися не лише на переліку обов’язків, а й на підкресленні свого впливу на продукт.
3. Критичне мислення та розв’язання проблем
QA не просто знаходить баги — він аналізує чому вони виникають. Це те, що ви вже робите. Відповідно, додавши бізнес-цінність, ви зможете показувати, як це впливає на бізнес. І як результат — показувати важливість своєї роботи зрозумілою для менеджменту мовою, приводячи зрозумілі бізнесу аргументи. Серед найпереконливіших я виділю три — зекономлені гроші, збережений час, та задоволення користувача. Зазвичай при правильному використанні вони працюють безвідмовно.
Наведу приклад з особистої практики: у кожному спринті у нас було по 15+ багів від служби підтримки на плюс-мінус одну й ту саму логіку. І ці 15 багів без кінця і краю кожний спринт потрібно було виправляти та перевіряти, витрачаючи час девелоперів і QA. Я вирішила знайти їх першопричину і розібратись, чому автотести їх пропускають.
З’ясувалося, що потрібен рефакторинг логіки. Якщо просто прийти й сказати, що потрібен рефакторінг — у 95% менеджмент не дасть вам на це зелене світло, бо є купа інших задач. Тому тут важливо змістити фокус уваги з «рефакторінгу» як інструменту розв’язання проблеми на бізнес-показники. Тобто порахувати KPIs для цієї проблеми й зробити це релевантним для бізнесу чином.
Для цього я підрахувала витрати бізнесу на усунення і перевірку цих дефектів щоспринта і дізналася QA та dev естіймейт на рефаткорінг. Це дозволило мені наочно показати, що інвестиція у вигляді разового рефакторингу окупиться компанії й звільнить третину часу розробників і QA вже через 2 спринти. Як результат, проєкт ухвалили з одним із найвищих пріоритетів. І це один із прикладів, як QA може не лише показати проблему, а й аргументувати її вирішення у категоріях грошей і часу, що зрозуміло бізнесу.
4. Співпраця та комунікація
За статистикою QA-спеціалісти як частина dev-команди найбільше комунікують з розробниками. І тут теж криється пастка виключно «технічного спеціаліста». Чим більше ви почнете взаємодіяти із підтримкою клієнтів, продактами, маркетингом та операційними командами, тим повніше ви зможете бачити картину того, що відбувається в продукті. І як результат ви зможете створювати більше цінності для компанії своєю роботою.
Мислити нестандартно і виходити за рамки звичайних патернів — це нова реальність для QA-фахівців, які хочуть продемонструвати свою цінність у майбутньому. Наведу приклад: після кількох спринтів я помітила, що кожен баг, який приходить до команди розробки від служби підтримки клієнтів, забирав у розробників до пів дня лише на збір інформації. Тобто з одного боку розробники неефективно витрачають свій час, з іншого — служба підтримки дає відповіді клієнтам стосовно їхніх проблем через
Для служби підтримки це було скорочення відповіді клієнту на 25%, і як результат покращення «задоволеності клієнта» сервісом компанії, бо вони швидше отримують розв’язання своєї проблеми. Для R&D ж це було усунення додаткових мітингів для з’ясування деталей і чітка структурована інформація в одному місці, яка дозволяла розробнику тримати фокус уваги на задачі й скорочувати час на її вирішення. У результаті компанія одночасно покращила NPS і отримала додаткову продуктивність R&D без нових витрат.
Головний takeaway
QA сьогодні — це не просто «той, хто шукає баги». Це стратегічний партнер, який мислить бізнесово, допомагає компанії досягати цілей і створювати продукт, що приносить клієнтам реальну цінність. Саме так має думати QA, щоб залишитися незамінним навіть в епоху штучного інтелекту.
1 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів