AI-асистент у Slack ≠ Sci-fi: як ми скоротили оновлення тестів з годин до хвилин

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

Привіт! Я Віталій, QA Architect у Techstack. У тестуванні ми часто спираємось на перевірені патерни, і вони дійсно працюють. Це ефективне рішення для типових задач, але разом із користю приходять і приховані обмеження, рутинність та вузькі місця.

За 15 років у QA я бачив це багато разів. Тому останні два роки ми з командою впроваджуємо AI, щоб зберегти сильні сторони знайомих практик, усуваючи їхні слабкі місця.

У цій статті хочу поділитися нашим досвідом: як ми вирішили типову для будь-якого продукту проблему — застарілі регресійні тести, і що сталося, коли ми віддали їх на «аутсорс» AI-асистенту.

Чому застарілі тести — це глобальний виклик

У світі, де continuous delivery давно стало нормою, а продукти оновлюються ледь не щодня, регресійні тестсети старіють блискавично. Особливо у великих проєктах, де регресія може налічувати тисячі кейсів. Хаос наростає поступово — спочатку здається, що все під контролем, але в якийсь момент з’являється відчуття тривоги. А потім реальність показує:

• тести більше не покривають критичні сценарії;
• частина кейсів втратила актуальність;
• перевірки дублюються або суперечать одна одній.

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

World Quality Report 2024 показує, що 68% компаній називають застарілі тести однією з головних проблем у QA. Щобільше, понад половина опитаних команд (52%) вважають, що саме вони є причиною непередбачуваних збоїв у релізах.

Що команди роблять зараз і чому це не працює

Проблема застарівання тестів існує ще з моменту написання першого тесту в історії. Рішення щоразу різні, але результат завжди тимчасовий. Найпоширеніші з них:

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

State of DevOps 2024 підтверджує: такі команди витрачають на 32% більше часу на підтримку, ніж ті, що вже інтегрували AI.

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

Ще один підхід — використовувати AI точково, це швидкий ефект без глибини. За цей рік багато команд інтегрували AI у свої процеси: використовують його для генерації тест-кейсів, оновлення BDD-сценаріїв чи аналізу вимог. Це дозволяє частково зняти рутину та прискорити роботу, але тут є пастка. Коли AI працює у відриві від загальної системи, він не вирішує хаос, а лише тимчасово приховує його. У багатьох командах це призводить до нових викликів:

• відсутності єдиних стандартів;
• непередбачуваних змін у тестах;
• складності при масштабуванні.

Це як додати новий інструмент без правил гри — спочатку допомагає, але з часом стає ще одним джерелом плутанини.

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

Жодному з цих підходів не вистачає системності. Це не стратегія, а лише «гасіння пожеж».

Наш підхід: AI як частина стратегії якості

Наш досвід показав: справа не в кількості людей чи процесах. Проблема у виборі інструментів, їхньому налаштуванні та гармонійній аугментації в робочі процеси команди.

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

Ось як виглядає наша архітектура:

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

• Векторне сховище. Асистент має повний контекст продукту — історію змін, специфікації, BDD-сценарії автотестів та мануальні тест-скрипти. Це дає AI-агенту повний контекст про застосунок і його актуальний стан, що дозволяє уникати помилкових відповідей через брак інформації.

• Чіткі інструкції. Ми налаштували промпти так, щоб AI працював із фокусом на точність, без зайвої «креативності», яка у QA може призвести до помилок.

• Інтеграція у звичні інструменти. Асистент працює прямо у Slack. QA-інженер запускає workflow — і через кілька хвилин отримує готовий список кейсів для оновлення.

Як це працює в реальності

Щоразу, коли в продукті з’являється нова фіча, до прикладу «оплата частинами» або KYC-перевірка, інженерам потрібно знайти всі тести, дотичні до цієї функціональності, і внести необхідні зміни. Це можуть бути нові перевірки, оновлені кроки або зміна очікуваних результатів.

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

У нашому процесі все виглядає інакше. QA просто пише в Slack номер JIRA-таски і вже за кілька хвилин отримує:

• список тестів, яких стосується зміна;
• що втратило актуальність;
• які кроки варто додати.

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

Зараз система стабільно обробляє понад 2000 тестів у різних проєктах, включно з автомейшен BDD-сценаріями у форматі Gherkin.

Результати, які відчутні кожному члену команди

Процес, який раніше займав години, тепер виконується за хвилини та при цьому гарантує точність та повноту оновлень. Завдяки цим змінам ми стабільно економимо близько 15% робочого часу QA-команди. У періоди високої динаміки змін і значних сайд-ефектів ця цифра може сягати 30%.

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

Рівень актуальності тестів зріс із приблизно 60% до понад 95%. Релізи стали стабільнішими: менше хаосу, менше затримок, більше впевненості у якості.

За даними Capgemini, компанії, які інтегрували AI у QA-процеси, підвищили ефективність тестування на 30–40% і скоротили витрати на підтримку регресії майже вдвічі. Наш практичний досвід певною мірою підтверджує цю статистику.

Але головне — змінився підхід у команді. Люди перестали витрачати час на рутину та перейшли до завдань, які справді потребують людського досвіду: складних сценаріїв, аналітики, планування.

Ризики, які важливо врахувати

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

По-перше, безпека даних. Дані проєкту — це чутлива частина продукту. Впевненість у тому, що вони не потраплять назовні та не використовуватимуться для навчання сторонніх моделей, є для нас ключовою.

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

По-третє — інтеграція в робочий процес. Навіть найкращий AI-інструмент не дасть результату, якщо користуватись ним незручно. Ми подбали про те, щоб він органічно працював у щоденному ритмі команди: Slack, Jira ID, знайомі формати звітів. Без цього інструмент залишився б просто ще однією тулою, яку ніхто не використовує.

Висновок: AI — це партнер у QA, а не заміна

AI у тестуванні вже не просто тренд. Це нова реальність. Gartner прогнозує, що до 2026 року 70% компаній інтегрують AI у свої QA- та DevOps-процеси. А Forrester підрахував, що AI допоможе скоротити час виходу на ринок на 35% у середніх та великих компаніях.

У QA-ком’юніті формується нова культура, і ми всі впливаємо на те, якою вона стане. Наш досвід — практичний приклад інтеграції AI, підкріплений реальними метриками та результатами. AI не замінює інженера, він підсилює його. Лише ті, хто навчиться працювати з ним на повну, отримають справжню перевагу.