Мануальне тестування за допомогою AI в Testomat.IO

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

Всім привіт, мене звати Іра і я працюю в компанії MEV як QA Engineer. Вже близько семи років я в галузі тестування, були різні та цікаві проєкти — тестування веб, десктоп і мобайл-застосунків. Кожного дня я використовую AI-інструменти. Як на мене, це дуже зручний помічник в роботі, але він все одно не замінить мануальне тестування.

Я вирішила зробити research, як можна покращити процеси в роботі QA за допомогою AI та MCP. У цій статті я розповім про свій досвід впровадження таких інструментів: що вийшло, а що ні, і чому я більше не уявляю свою роботу без них.

Що це взагалі таке і навіщо воно мені

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

Що таке LLM

LLM (Large Language Model) = велика мовна модель.

• Штучний інтелект, навчений на величезній кількості тексту.
• Розуміє і генерує текст.
• Приклади: ChatGPT, Claude, Gemini.

Різниця LLM vs Агент vs MCP:

LLM = розумний текстовий генератор.

• Тільки відповідає текстом.
• Не виконує дій.

Агент = LLM + руки.

• Може виконувати дії (створювати тести, відкривати браузер, працювати з API).
• Планує і діє самостійно до результату.
• Працює з локальними інструментами (файли, код, обчислення).

MCP = агент + доступ до вашого робочого середовища.

• Підключається до ваших інструментів (Jira, Confluence, GitHub)
• Читає і оновлює дані без копіпасту
• Автоматизує робочі процеси наскрізь

Аналогія:

• LLM = Консультант (дає поради)
• Агент = Асистент (робить за вас)
• MCP = Асистент з доступом до вашого офісу (робить за вас І має ключі від всіх дверей)

AI Agent — це не просто чат-бот

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

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

MCP — чому це важливо

Model Context Protocol — звучить складно, але суть проста. Це спосіб дати AI доступ до ваших робочих інструментів.

У нас вся документація в Confluence, задачі в Jira. Без MCP мені доводилося копіпастити вимоги в чат з AI. З MCP агент сам може прочитати останню версію документа, побачити зміни в задачах, зв’язати тести з тікетами.

Різниця як між листуванням email’ами і загальним Google Doc — технічно можна і через пошту, але навіщо так себе мучити?

Що обрати: просто агент чи агент + MCP

Коротка відповідь: почніть з агента, додайте MCP, коли відчуєте біль від ручної роботи.

Почніть з AI Agent, якщо:

• Хочете спробувати швидко (налаштовується за годину).
• У вас невелика команда або ви працюєте solo.
• Потрібні базові речі: аналіз вимог, генерація тест-кейсів, чеклісти.

Мінус: доведеться вручну оновлювати контекст при зміні вимог. Копіювати нові AC, пояснювати, що змінилося. Спочатку не критично, але з часом дратує.

Додайте MCP, коли:

• Набридло копіпастити документацію (у мене це сталося через 2 місяці).
• Потрібна traceability між тестами і вимогами.
• Команда зросла і всім потрібен доступ до актуальних даних.
• Вимоги змінюються часто.

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

Мій досвід: почала з агента, через два місяці додала MCP. Не шкодую, що не одразу — спочатку важливо зрозуміти, чи взагалі потрібен AI у вашому процесі, а вже потім інвестувати час у глибшу інтеграцію.

Що агент реально вміє (на прикладах)

Окей, менше теорії, більше практики. Що я реально роблю з агентом кожного дня?

Аналіз AC — знаходимо проблеми до розробки

Ранок. Прийшла нова фіча у Jira. Читаю AC і розумію, що щось не так, але не можу сформулювати, що саме. Зараз я просто кидаю AC агенту:

У мене є критерії прийняття для функції відновлення паролю.
Перевір їх на повноту і знайди неоднозначності.

За хвилину маю список:

• «Відправити листа» — на яку адресу? Що, якщо користувач змінив email?
• Немає згадки про експірацію лінка відновлення.
• Що станеться, якщо користувач натисне на лінк двічі?
• Чи треба логувати спроби відновлення (security)?

Три з цих питань я б і сама згадала. Але про логування — забула б на 100%. Агент не забуває.

Генерація тест-кейсів — від ідеї до готових тестів

Коли AC узгоджені, треба писати тест-кейси. Це найнудніша частина роботи, чесно. Особливо коли треба покрити всі крайні випадки.

Я даю агенту AC і кажу:

Створи тест-кейси для цієї функції.
Не забудь про крайні випадки та негативні сценарії.

Агент генерує базові сценарії, альтернативні потоки, edge cases, негативні тести. Мені залишається тільки переглянути і підправити під специфіку нашого проєкту.

Що важливо — він пише у форматі, який ми використовуємо. Спочатку я дала йому пару прикладів існуючих тест-кейсів, і тепер він тримається того ж стилю.

Чеклісти перед релізом — швидко і по ділу

Треба швидко прогнати smoke-тести. Зазвичай я б дивилася на старі чеклісти і намагалася пригадати, що ще треба перевірити.

Тепер:

Створи smoke-тест чекліст для модуля аутентифікації.
Враховуй, що ми щойно виправили баг з session timeout.

За 30 секунд маю актуальний чеклист. Прогнала, все ок, релізимо.

Баг-репорти — структура без зусиль

Знаходжу баг. Раніше я витрачала 10 хвилин на оформлення репорту: describe steps, пишу очікуваний результат, шукаю environment details, думаю про priority.

Зараз я описую агенту, що трапилося, буквально як побачила:

Користувач не може залогінитись після того як змінив email.
Пише "Invalid credentials" хоча пароль точно правильний.
Перевірив в базі — старий email ще там, новий теж є.

Агент робить нормальний баг-репорт з усіма полями, кроками для відтворення, пропонує severity і priority. Мені треба тільки перевірити, чи все правильно і відправити в Jira.

Інтеграція з Jira через MCP — все зв’язане

Найкрутіша штука, яка з’явилась після додавання MCP — автоматичні зв’язки.

Тест провалився → агент бачить це → створює баг у Jira → зв’язує баг з тест-кейсом → додає тег до тесту «has_open_bug».

Я більше не забуваю зв’язати баг з тестом. Агент не забуває ніколи.

Промпти, які я використовую щодня

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

Для роботи з тестами

Створити тест:

Новий тест для логіна в suite AUTH-001.
Назва "Юзер логіниться з валідними даними"

Знайти тести:

Покажи всі тести з @smoke в проєкті

Шукай тести про checkout з high priority

Оновити тест:

Тест TEST-123 зміни priority на critical, додай @regression

Для пошуку і аналізу

Складний пошук:

Знайди автоматизовані тести з @smoke які assigned на QA team

Аналіз покриття:

Скільки у нас automated vs manual в suite PAYMENT-TESTS?

Пошук проблем:

Які тести провалились в останньому прогоні?

Покажи тести які не апдейтились 6 місяців

Для щоденних завдань

Підготовка до тестування:

Візьми всі @smoke тести, зроби план, покажи summary

Після тестування:

Із suite CHECKOUT-TESTS візьми провалені, зроби список для багрепортів

Швидкий аналіз:

Поглянь на тести про payment, покажи результати останніх прогонів

Найважливіше, що я зрозуміла — агент розуміє контекст. Не треба кожного разу пояснювати з нуля, він пам’ятає, про що ми говорили раніше в сесії.

Як це налаштувати (без болю)

Як агента я вибрала Claude Desktop через легкість підключення до нього інших сервісів. Також MCP можна підключати до безкоштовної версії (чого, наприклад, не може ChatGPT). Тепер розповім, як це підключити. Я пройшла через всі граблі, тому ви можете їх уникнути.

Варіант 1: Агент всьому голова

Крок 1: Отримати токен до Testomat.io

Заходите в Testomat.io, клікаєте на аватар → Account → Access Tokens. Там ваш токен (починається з testomat_).

Також треба знайти Project ID. Відкриваєте проект → Settings → там побачите ID.

Крок 2: Конфігурація Claude Desktop

Відкриваєте Claude Desktop → Settings → Developer → Edit Config. Вставляєте це (змінивши на свої дані):

{
    "mcpServers": {
        "testomatio": {
            "command": "npx",
            "args": [
                "-y",
                "@testomatio/mcp@latest",
                "--token",
                "testomat\_ВАШ\_ТОКЕН",
                "--project",
                "ВАШ\_PROJECT\_ID"
            ]
        }
    }
}

Збережіть, перезапустіть Claude. Має запрацювати.

Якщо npx не працює (у мене спочатку npx не знайшовся) — треба було встановити Node.js. Йдете на nodejs.org, качаєте LTS-версію, встановлюєте. Потім npx сама з’являється.

Крок 3: Додаємо коннектор для Atlassian

Claude Desktop → Settings → Connectors → Browse connectors → шукаєте «Atlassian Rovo» → Add → авторизуєтесь.

Все. Серйозно, це просто OAuth, робиться за хвилину.

Важливо: можна налаштувати permissions. Settings → Connectors → Atlassian Rovo → Configure → Custom. Там вибираєте, що саме агент може робити. Я спочатку дала read-only, потім, коли переконалася, що все ок, додала можливість створювати задачі.

Варіант 2: Один агент добре, а два — краще

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

Для цього я використала зв’язку OpenAI API (ChatGPT) + Anthropic API (Claude) + n8n для оркестрації.

n8n — що це і навіщо

n8n — це open-source інструмент для автоматизації робочих процесів. Це платформа, яка дозволяє з’єднувати різні застосунки та сервіси разом без необхідності писати код (або з мінімальним кодуванням).

Ключові можливості n8n — що ви можете робити:

• Автоматизувати повторювані завдання між різними сервісами (наприклад, автоматично зберігати вкладення з Gmail у Google Drive).
• Інтегрувати CRM-системи, бази даних, месенджери, маркетингові інструменти.
• Створювати складні бізнес-процеси через візуальний редактор.

Цей інструмент особливо корисний для автоматизації бізнес-процесів, DevOps-завдань та інтеграції різних систем без необхідності створювати власні API-інтеграції з нуля.

У n8n ви бачите workflow візуально — блоки з’єднані між собою.

Якщо хочете додати будь-яку іншу дію або елемент, просто натисніть «+» у правому куті.

Щоб змінити параметри дії або елемента, двічі клацніть на нього.

Docker — для запуску n8n

Docker — це платформа для розробки, доставки та запуску застосунків у контейнерах.

Простими словами: Docker дозволяє «упакувати» ваш застосунок разом з усім необхідним (бібліотеки, залежності, конфігурації) в один контейнер, який може працювати однаково на будь-якому комп’ютері.

Основна ідея: замість встановлення програм безпосередньо на ваш комп’ютер, ви запускаєте їх в ізольованих контейнерах. Це схоже на віртуальну машину, але набагато легше та швидше.

Навіщо це потрібно:

• «Працює на моєму комп’ютері» — класична проблема розробників. З Docker застосунок буде працювати однаково на вашому ноутбуці, сервері колеги та продакшн-сервері.
• Ізоляція — кожен застосунок працює у своєму контейнері без конфліктів з іншими.
• Швидке розгортання — ви можете запустити базу даних, вебсервер або будь-який інший сервіс за лічені секунди.
• Легке масштабування — просто запустіть більше контейнерів.

Приклад використання: замість встановлення PostgreSQL, Redis, Node.js на ваш комп’ютер, ви просто запускаєте готові Docker-контейнери з цими програмами.

Встановлюєте Docker Desktop (є для Mac і Windows), потім дві команди:

docker volume create n8n_data

docker run -it --rm \
--name n8n \
-p 5678:5678 \
-e GENERIC_TIMEZONE="Europe/Kyiv" \
-e TZ="Europe/Kyiv" \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n

В деяких випадках друга команда може не спрацювати, спробуйте без «\» та однією строкою.

Відкриваєте localhost:5678 — працює. Всі дані зберігаються в n8n_data, тому після перезапуску контейнера все залишається.

Створення workflow в n8n

Тут я розпишу детально, як я налаштовувала цей процес. Спочатку здавалося складно, але коли розібралася — виявилося досить логічно.

Важливий момент: в цьому підході ми не використовуємо MCP. Тут чиста робота через API. Тому нам потрібні API-ключі від усіх сервісів.

Токен для Testomat.io:

Отримання токену для Testomat.io я описувала вище. Testomat.io має REST API з endpoint’ами для всього: читання тестів, створення, оновлення. Документація на docs.testomat.io/test-reporting/api — там все досить зрозуміло розписано.

Токен для OpenAI API (для ChatGPT):

1. Йдете на platform.openai.com.
2. Реєструєтесь / логінитесь.
3. API Keys → Create new secret key.
4. Копіюєте (він показується тільки раз!).
5. Закидаєте на рахунок $5-10 для початку.

Токен для Anthropic API (для Claude):

1. console.anthropic.com.
2. Реєструєтесь.
3. Settings → API Keys → Create Key.
4. Копіюєте ключ.
5. Також кидаєте грошей на рахунок (на старті вже лежить 5$).

Токен для Gmail:

1. Створіть проєкт

1. Перейдіть до Google Cloud Console.
2. Натисніть «New Project» → введіть назву → «Create».

2. Увімкніть Gmail API

1. «APIs & Services» → «Library».
2. Знайдіть «Gmail API» → «Enable».

3. Екран згоди OAuth

1. «OAuth consent screen» → оберіть «External» → «Create».
2. Заповніть:
   • Назву застосунку.
   • Email підтримки користувачів.
   • Контактний email розробника.
3. «Save and Continue» → «Save and Continue» → «Back to Dashboard»

4. Створіть Client ID і Secret

1. «Credentials» → «+ Create Credentials» → «OAuth client ID».
2. Тип застосунку: «Web application».
3. Додайте Redirect URI:
   • localhost:5678/...​auth2-credential/callback (для локального n8n)
4. «Create»
5. Скопіюйте Client ID і Client Secret — використайте в n8n.

Важливо: ці токени для API — це не те саме, що доступ через MCP. Тут ми платимо за кожен запит. Зате повний контроль і можна оркеструвати складні процеси.

Workflow-покращення тест-кейсів із валідацією

Цей робочий процес реалізує систему подвійної перевірки з використанням АІ, яка оцінює тест-кейси за допомогою ChatGPT та Claude для забезпечення найвищих стандартів якості.

Готовий workflow можна знайти на GitHub: github.com/...​chnk/n8n-workflow-testing

Там ви знайдете:

• JSON-файл workflow для імпорту в n8n.
• Детальну інструкцію по налаштуванню (які токени де підставити).
• Список необхідних API-ключів.

Для імпорту workflow в n8n:

Start from scratch → Menu (…) → Import from URL…

Як це працює

1. Ми запускаємо workflow вручну (Manual Trigger).
2. n8n витягає тест кейси череза АРІ Testomat.io та відсилає в ChatGPT.
3. ChatGPT аналізує кожен тест-кейс і вертає покращення для заголовка, опису, тегів та пріоритету.
4. У Claude передаємо результати роботи ChatGPT і просимо валідувати їх якість за допомогою детальної системи оцінювання.
5. n8n створює коментарі до кожного з тест-кейсів в Testomat.io із запропонованими змінами і їх оцінкою.
6. Після завершення всіх перевірок надсилається підсумковий email, який містить: оглядову статистику (загальна кількість переглянутих, схвалених, відхилених), прямі посилання на кожен тест-кейс, згруповані за статусом перевірки, оцінки та рекомендації для легкого прийняття рішень.

Трошки про гроші

Запити до API оплачуються за кількістю токенів на вхід (input) та вихід (output).

GPT-4: ~$0.03/1K input tokens, ~$0.06/1K output tokens.

Claude Sonnet: ~$0.003/1K input tokens, ~$0.015/1K output tokens.

Один тест-кейс це ~500 input tokens та ~300 tokens output для обох LLM.

Виходить ~$0.05 на один тест-кейс.

Якщо обробляємо 20 тестів на день = $1/день = ~$30/місяць.

Цілком прийнятно.

Тестування workflow

Перед запуском на всіх тестах я рекомендую:

1. Створити тестовий проєкт в Testomat.io з 2-3 тестами.
2. В n8n використовувати лише Manual Trigger.
3. Перевірити, що все працює.
4. Подивитись, скільки коштує.
5. Тільки потім запускати на реальних даних.

Альтернатива: MCP vs API-підхід

Тепер коли я розповіла про обидва підходи, можна їх порівняти:

MCP (через Claude Desktop):

• ✅ Простіше налаштувати.
• ✅ Не треба платити за API calls.
• ✅ Працює в інтерфейсі Claude.
• ❌ Менше контролю.
• ❌ Не можна автоматизувати складні workflow.

API через n8n:

• ✅ Повний контроль над процесом.
• ✅ Можна робити складні автоматизації.
• ✅ Дві LLM перевіряють одна одну.
• ✅ Логування і аналітика.
• ❌ Треба платити за API.
• ❌ Складніше налаштувати.
• ❌ Треба підтримувати (Docker, n8n).

Можна використовувати обидва підходи: MCP для щоденної ручної роботи, API для автоматизованих процесів.

Поширені помилки при впровадженні

Помилка 1: Спробувати все і одразу

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

Результат: нічого не працює нормально. Витрачається купа часу на налаштування і нічого не доводиться до кінця.

Що треба робити: почати з однієї проблеми. Наприклад, тільки аналіз AC. Налагодити це. Отримати результат. Показати команді. А потім додавати наступне.

Помилка 2: Не давати достатньо контексту

«Створи тест для логіна» — занадто загально. AI не знає специфіки вашого продукту.

«Створи тест для логіна в мобільному застосунку для банку. Враховуй, що у нас є двофакторна аутентифікація через SMS, і треба перевірити, що після 3 невдалих спроб акаунт блокується на 15 хвилин» — ось це нормальний контекст.

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

Помилка 3: Сліпа довіра

Якщо просто робити copy-paste результатів агента без перевірки, можна знайти тест-кейс, який перевіряє неіснуючу функцію. Агент може «галюцюнувати».

Рішення: завжди перевіряти результати роботи AI. Для базових речей (як оформлення баг-репорту) це може бути не критично. Для складної логіки — просто необхідно.

Помилка 4: Ігнорувати security

Якщо просто дати агенту доступ до всього в Confluence, він може читати конфіденційні документи. Security team не буде рада.

Рішення: узгодити з security, що саме AI може читати. Використовувати тестове середовище для експериментів. Не давати доступ до prod даних без необхідності.

Підсумки: чи варто воно того

Залежить від ваших очікувань.

AI не зробить вас суперменом за один день. Перші два тижні ви будете повільнішими, бо вчитеся новому інструменту. Це нормально.

AI не замінить досвід. Він не знає специфіки вашого проєкту. Не розуміє бізнес-контексту. Не відчуває, де «щось не так». Це все ще ваша робота.

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

І звільняє голову для важливого. Коли не треба витрачати дві години на написання 10 схожих тест-кейсів, можна зосередитись на складних сценаріях, edge cases, security issues.

Мій чеклист «чи варто вам це впроваджувати»

✅ Варто спробувати, якщо:

• У вас багато рутинних завдань (документація, однотипні тест-кейси).
• Вимоги часто змінюються і треба постійно оновлювати тести.
• Команда зростає і треба стандартизувати процеси.
• Хочете більше часу на складні речі замість рутини.

❌ Можна почекати, якщо:

• У вас маленький проєкт з 20 тест-кейсами.
• Процеси нестабільні і змінюються кожного тижня.
• Security дуже суворий і буде блокувати доступи місяцями.
• В команді немає ентузіазму пробувати нове.

З чого почати прямо зараз

1. Візьміть Claude (безкоштовно) і спробуйте згенерувати тест-кейс для будь-якої фічі.
2. Якщо сподобалось — підключіть до Testomat.io.
3. Використовуйте тиждень тільки для аналізу AC і генерації базових тестів.
4. Оцініть результати — скільки часу заощадили, чи якість нормальна.
5. Вирішіть, чи йти далі — додавати MCP, масштабувати на команду.

Не намагайтеся впровадити все і одразу. Маленькі кроки, швидкі перемоги, поступове масштабування.

Ціноутворення станом на січень 2026

Основні варіанти для роботи з агентом (стандартні підписки):

Основні варіанти для роботи з n8n:

Важливо: при використанні режиму MCP-агента фактичне споживання повідомлень буде вищим через системні промпти та багатокрокові процеси!

Замість висновку

Рік тому я була скептиком. «ШІ не розуміє контексту», «результати треба все одно переробляти», «швидше сама напишу, ніж буду пояснювати AI, що мені треба».

Зараз я щодня використовую AI в роботі. Не тому що це модно. А тому що це реально економить мій час і робить роботу приємнішою.

Якщо ви досі думаєте «спробувати чи ні» — спробуйте. Найгірше, що може статися — витратите годину і зрозумієте, що вам це не треба. Найкраще — знайдете, інструмент який змінить ваш підхід до тестування.

Успіхів! І пам’ятайте — AI це інструмент, не magic button. Він допоможе, але думати все ще треба вам самим 🙂

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.