Як має думати QA, щоб залишитися незамінним навіть в епоху штучного інтелекту

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до 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-фахівців, які хочуть продемонструвати свою цінність у майбутньому. Наведу приклад: після кількох спринтів я помітила, що кожен баг, який приходить до команди розробки від служби підтримки клієнтів, забирав у розробників до пів дня лише на збір інформації. Тобто з одного боку розробники неефективно витрачають свій час, з іншого — служба підтримки дає відповіді клієнтам стосовно їхніх проблем через 2-3 тижні. Я вирішила це змінити, впровадивши баг репорт структуру і навчиши службу підтримки нею користуватися. Але для того, щоб ця ідея знайшла підтримку замість відповіді «та так завжди було на проєкті», я підрахувала KPI для обох команд.

Для служби підтримки це було скорочення відповіді клієнту на 25%, і як результат покращення «задоволеності клієнта» сервісом компанії, бо вони швидше отримують розв’язання своєї проблеми. Для R&D ж це було усунення додаткових мітингів для з’ясування деталей і чітка структурована інформація в одному місці, яка дозволяла розробнику тримати фокус уваги на задачі й скорочувати час на її вирішення. У результаті компанія одночасно покращила NPS і отримала додаткову продуктивність R&D без нових витрат.

Головний takeaway

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

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ярославо, дуже влучна стаття! Особливо відгукнувся приклад про рефакторинг та як ви донесли його цінність через бізнес-показники. Це саме те, чого часто не вистачає в комунікації QA та менеджменту.

Ви абсолютно праві, що треба звільняти час від рутини для таких бізнес-задач. І я для себе знайшов, що AI в цьому — ідеальний помічник. Він чудово забирає на себе найнудніші задачі: структурування баг-репортів (щоб розробники не питали «що тут?»), створення тестових даних, написання базових тест-кейсів.

Якраз про це і веду свій невеликий канал-експеримент, де ділюся готовими промптами і показую, як застосовувати AI в реальній роботі. Якщо комусь цікаво спробувати AI в дії, а не тільки в теорії, шукайте в Telegram QA Co-pilot.

Підписатись на коментарі