У світі цифрових продуктів дрібна помилка може коштувати мільйони. Тому професія QA вже давно перестала бути «пошуком багів» — сьогодні це стратегія, що визначає успіх проєкту. Українська інженерка Анна Дев’ятко понад дев’ять років працює у сфері забезпечення якості та встигла створити власний фреймворк, який вплинув на десятки міжнародних ігор. Її підходи дозволили командам скоротити тестування з трьох днів до кількох годин і вберегли продукти від провальних релізів. Після злиття ironSource та Unity ці рішення отримали ще більший масштаб і довели: навіть локальні інновації можуть змінювати правила у глобальному бізнесі. Про те, чому QA — це «архітектура довіри», як автоматизація перетворюється на стратегічну перевагу і чим відрізняється мислення сучасного тестувальника, ми говорили з Анною у нашому інтерв’ю.

– Анно, ви майже десять років у QA. Як змінилося ваше розуміння професії за цей час?
– Коли я починала, QA сприймалося як “знайти баг перед релізом”. Сьогодні для мене це зовсім інше: це система, яка впливає на архітектуру, процеси, користувацький досвід і навіть на бізнес-рішення. Я переконана, що якість треба будувати з першого дня, а не на етапі останніх перевірок.

– Ви створили власний фреймворк ще у ironSource. Яким він був і чому став переломним?
– Це був універсальний набір автоматизованих інструментів на Selenium, Appium і CI/CD. Його сила в тому, що він дозволяв підключати нові проєкти буквально за кілька днів. Він працював із понад двадцятьма іграми й виявляв критичні помилки ще до релізу. Один приклад: система зловила збій, через який гра могла вилітати у 7–9% випадків. Ми виправили його до запуску, і crash-rate упав до 0.3%. В іншому випадку — дисбаланс винагород, що загрожував падінням активності на 12%. Ми побачили це завчасно, і в результаті фактичне падіння було лише 1,5%.

– А що дав цей фреймворк команді?
– По-перше, швидкість: замість трьох днів повної регресії ми отримували результати за 6–7 годин. По-друге, стабільність: кількість випадкових збоїв у тестах скоротилася на 65%. По-третє, культура: ми ввели правило, що реліз неможливий, якщо критичні перевірки не пройдені на 95%. Це зробило QA не “останнім бар’єром”, а частиною процесу ухвалення рішень. Ці підходи настільки добре спрацювали, що після злиття ironSource та Unity вони стали застосовуватися вже у ширшій інфраструктурі компанії.

– Але ваш досвід – це не тільки фреймворки. Які ще методики ви впроваджували?
– Я завжди працюю на стику техніки й методології. Наприклад, використовувала risk-based testing для пріоритизації сценаріїв: ми не ганяли все підряд, а концентрувалися на тому, що реально могло завалити реліз. Запроваджувала anomaly detection у логах, щоб бачити проблеми ще до того, як користувачі скаржаться. І, що важливо, я завжди дивлюся на продукт і очима розробника, і очима користувача. Це допомагає ловити речі, які цифри самі по собі не покажуть.

– Команда одразу підтримала вас?
– Спочатку з обережністю. Але коли вони побачили, що замість трьох днів ми маємо результати вже через 6–7 годин, усе стало на свої місця. Один із продюсерів сказав: «Без цього рішення ми не витримали б наступний реліз». Для мене це було підтвердженням, що QA може впливати на бізнес, а не лише на техніку.

– Як ви бачите майбутнє QA?
– Наступний крок – інтеграція штучного інтелекту. Але фундамент уже закладено: автоматизація, методи на основі ризиків, робота з даними. Вони дозволяють QA бути не витратною статтею, а стратегічною перевагою. Мій досвід у ironSource та Unity довів: якщо правильно вибудувати процеси, QA впливає не тільки на код, а й на стратегію створення продуктів.

Олександр МИРОНЕНКО

Підписуйся на сторінки UAINFO Facebook, Telegram, Twitter, YouTube