Тести, що запускаються після кожного деплою, і баги, що заводяться самі
QA Spider тестує ваш застосунок у справжньому браузері та через його API, запускає набір після кожного деплою і заводить кожну підтверджену регресію в трекері, яким ваша команда вже користується. Тариф Enterprise: зв’яжіться з нами.
Що ви отримуєте
- UI-тести в справжньому браузері
- Контрактні перевірки REST і GraphQL
- Звіти про баги, складені з невдалого запуску: кроки, скриншот, серйозність. Перевірені на дублікати, заводяться лише після вашого схвалення.
- Баги заводяться в Jira, ClickUp, GitHub Issues, Linear, Azure DevOps
- Сповіщення в Slack, Discord, Telegram
- AI-тріаж: нестабільний тест чи справжній баг
- Першопричина з вашого репозиторію, лише читання
- Серйозність
- P1
- Кроки
- Додати товар, відкрити /checkout, застосувати прострочений код, оплатити тестовою карткою.
- Очікувано
- Код відхиляється з повідомленням.
- Фактично
- Показується «Код застосовано», і списується повна сума.
- Заведено в
- Jira, після схвалення. Сповіщення в Slack надіслано.
Як баг подорожує
Деплой запускає набір. Тест, що падає, стає звітом про баг; щойно ви його схвалюєте, він потрапляє у ваш трекер, а чат команди дізнається про це.
Після деплою запускаються тести, один падає, і його звіт про баг переходить у трекер команди, а повідомлення в Slack його оголошує.
Запуск падає
Після кожного деплою, у справжньому браузері й щодо вашого API.
Тріаж вирішує
Нестабільний тест, збій інфраструктури чи справжній баг продукту.
Звіт пишеться сам
Кроки з того, що справді виконувалося, скриншот, серйозність.
Ви схвалюєте
Він потрапляє у ваш трекер і чат, не раніше.
Безпечно за замовчуванням
На production виконуються лише перевірки на читання. Усе, що створює чи змінює дані, виконується лише на dev або staging. Заведення тікета чи повідомлення в чат чекає вашого схвалення. Ми ніколи не ховаємо справжній баг, щоб запуск був зеленим.
Також на Pro
Pro ($29/mo) включає 1 000 кредитів на тестування щомісяця: запуск згенерованих тестів на вимогу, вибір тестів, збереження наборів, генерація тесту за описом і його візуальне редагування. Розклад, заведення в трекер, сповіщення в чат і AI-тріаж — це Enterprise.
Web3 теж. dApp отримують такий самий підхід: павук проходить сценарії з гаманцями за допомогою емульованих гаманців (підключення, перемикання мережі, підпис, відхилення), перевіряє виклики контрактів у testnet і звіряє, що показує ваш UI, з блокчейном.
Питання від команд
Чим це відрізняється від того, щоб писати тести самим?
Вам ніщо не заважає. QA Spider пише стандартний тестовий код, який могла б написати ваша команда. Різниця в тому, хто виконує роботу: він складає тести, запускає їх після кожного деплою, лагодить локатори, коли змінюється ваш UI, і заводить баги. Ваші інженери переглядають результати.
Чи не завалить він наш трекер?
Ні. Кожен збій спершу проходить тріаж: нестабільні тести лагодяться, збої інфраструктури повторюються, а тікетами стають лише підтверджені баги продукту. Заведення потребує вашого схвалення, і кожен тікет перевіряється на дублікати.
Що буде, коли змінюється наш UI?
Якщо локатор зламався через редизайн, павук лагодить тест і робить про це примітку. Якщо поведінка регресувала, він заводить баг, а не тихо править тест, щоб той лишався зеленим.
Як ви працюєте з входом, платежами й тестовими даними?
Ви даєте павуку тестові акаунти для staging. Він входить, оформлює замовлення тестовими картками й надсилає форми там. Сценарії, що змінюють дані, виконуються лише на dev і staging; production отримує лише перевірки на читання.
Чи потрібен вам наш вихідний код?
Для тестів — ні: павук тестує ваш застосунок так, як його зустрічає користувач. За бажанням можна підключити репозиторій лише для читання, щоб збій називав файл і коміт, що за ним стоять.
Чи безпечно запускати це на production?
Запуски на production обмежені smoke-перевірками на читання. Усе, що створює, змінює чи видаляє дані, позначене як змінююче й виконується лише на dev або staging.