Автоматизація тестування давно вважається «болючою необхідністю» для розробницьких команд: усі розуміють, що без неї нікуди, але писати й підтримувати тести ніхто не хоче. На каналі Tech With Tim показали, як платформа KaneAI намагається розв’язати цю проблему за допомогою генеративного ШІ — від створення тестів із текстових описів до самовідновлення сценаріїв після змін у UI.
Від текстового опису до виконуваного тесту
KaneAI позиціонується як «генеративний AI-native тестувальний агент». Ключова ідея: замість того, щоб вручну писати тестові сценарії, команда описує очікувану поведінку системи природною мовою, а платформа:
- перетворює цей опис на структуровані тест-кейси;
- генерує реальний виконуваний код (не псевдокод) для різних мов і фреймворків, зокрема Python + Selenium;
- запускає тести у віртуальному середовищі (наприклад, у Chrome на віртуальній машині);
- формує повноцінні тестові набори (test suites) з історією запусків та логами.
Працювати можна з різними типами інтерфейсів:
- десктопний браузер;
- мобільний браузер;
- мобільний застосунок.
Сценарій виглядає приблизно так: QA-інженер або розробник обирає тип інтерфейсу, вставляє URL і формулює завдання на кшталт: «Перейди на цей сайт і переконайся, що форма не дозволяє надіслати дані, доки всі обов’язкові поля не заповнені». Далі агент сам відкриває сторінку, взаємодіє з елементами й будує послідовність кроків тесту.
Після виконання сценарію користувач отримує:
- список кроків тесту;
- опис тест-кейсу;
- згенерований код, який можна завантажити;
- можливість запускати тести повторно та дивитися результати;
- автоматичне створення «issues», якщо знайдено баг.
Ручний режим, сценарії з PRD та комбіновані тести
Ручне записування дій
Якщо покладатися на повну автоматизацію не хочеться, платформа пропонує режим manual interaction:
- користувач сам клікає по сайту, заповнює поля, виконує дії;
- система в реальному часі записує ці кроки;
- на основі запису формується відтворюваний тест-кейс.
Це корисно, коли потрібно точно зафіксувати специфічну поведінку, а не дозволяти ШІ «здогадуватися», що саме тестувати.
Генерація тестових сценаріїв із PRD
Окремий блок функціональності — вкладка Generate Scenarios. Тут KaneAI працює не з окремим описом, а з повноцінною документацією:
- завантажується PRD (Product Requirements Document) у форматі PDF;
- система аналізує користувацькі історії, опис полів форм, цілі продукту;
- на основі цього формує тест-план.
У продемонстрованому прикладі з одного PRD було згенеровано:
- 19 окремих тестів;
- об’єднаних у 5 тестових наборів;
- із позитивними та негативними сценаріями.
Далі користувач може:
- обрати потрібні тести;
- натиснути «Create and automate»;
- вказати URL;
- дочекатися, поки агент створить і виконає автоматизацію.
Таким чином PRD перетворюється не лише на документацію, а й на джерело для систематичного покриття продукту тестами.
API-тестування та мережеві асерти
KaneAI не обмежується UI. Усередині одного тест-кейсу можна додати API-перевірки:
- Через спеціальну команду додається API-крок (наприклад, GET-запит до
/api/submissions). - Запит виконується безпосередньо з платформи.
- Відповідь аналізується: код статусу (наприклад, 401 Unauthorized без admin-авторизації), тіло відповіді, заголовки.
- На основі цього налаштовуються асерти:
- перевірка URL запиту;
- очікуваний статус-код;
- структура та вміст відповіді.
Ці мережеві перевірки можна комбінувати з UI-кроками в одному сценарії, що дозволяє тестувати наскрізні (end-to-end) кейси: від взаємодії користувача з інтерфейсом до реакції бекенду.
Самовідновлення та інтеграції з інфраструктурою розробки
Self-healing тестів
Одна з типових проблем автоматизованого тестування — «крихкість» сценаріїв: незначна зміна в UI (текст кнопки, атрибут елемента) часто ламає тести. KaneAI намагається зменшити цей ефект за рахунок self-healing:
- система використовує ШІ, щоб «зрозуміти», що змінилося в інтерфейсі;
- намагається автоматично адаптувати локатори та кроки;
- дрібні зміни (перейменування, незначні зміни верстки) не мають повністю руйнувати тест-кейс.
Це зменшує обсяг рутинної підтримки, яка зазвичай накопичує «технічний борг» у тестах.
Інтеграції з CI/CD та трекерами
Щоб автоматизація була корисною в реальних командах, платформа підтримує інтеграції з популярними інструментами:
- CI/CD-системи;
- GitHub;
- Jira;
- Azure DevOps;
- BugHerd;
- ZipBoard та інші.
Сценарії використання:
- автоматичне створення й оновлення задач у трекері при виявленні багів;
- зв’язування тестів із Jira-тикетами;
- запуск тестів у CI/CD-пайплайнах;
- синхронізація статусів між системами.
Це дозволяє вписати AI-тестування в існуючі процеси, а не будувати окремий ізольований інструмент.
Обмеження, крива навчання та роль QA
Попри вражаючі можливості, платформа не позиціонується як заміна QA-команди. Наголошується на кількох моментах:
- Є крива навчання: потрібно зрозуміти, як правильно формулювати запити й будувати сценарії.
- Результати ШІ треба валідувати: швидка генерація тестів не скасовує необхідності перевіряти, чи справді вони покривають потрібні кейси й коректно працюють.
- AI може помилятися: як і в інших генеративних системах, можливі хибні припущення або некоректні кроки.
Фактично KaneAI розглядається як інструмент для:
- зняття рутини з QA-інженерів і розробників;
- пришвидшення створення й оновлення тестів;
- зменшення «боргу» за непротестовані сценарії.
Роль фахівців при цьому зміщується від ручного написання коду тестів до проєктування якісних сценаріїв, аналізу результатів і контролю якості автоматизації.