Ефект хвилі: правка в одному куті системи ламає щось у протилежному, і ніхто цього не помічає до скарги клієнта. Що старший продукт, то дорожча кожна така хвиля. Автоматизація тестування ставить на її шляху перевірку, яка спрацьовує за хвилини після кожної зміни, а не за тиждень у вигляді втраченого замовлення.
Це напрям із блоку корпоративного розвитку. Його підключають, коли продукт уже працює і переходить від MVP до MMP та MLP, а випуск оновлень стає регулярним. Орієнтир вартості напряму в прайсі Ingello: $4700.
У що обходиться ручна перевірка
Доки система маленька, її можна проклікати перед кожним релізом. Потім сценаріїв стає десятки, ролей кілька, інтеграцій більше ніж одна, і повна ручна перевірка займає дні. Команда починає перевіряти вибірково, і помилки йдуть до користувачів. Або релізи стають рідкими й великими, а отже, ще ризикованішими.
Що входить у роботу
У прайсі напрям описано трьома пунктами: впровадження автоматичних тестів, зниження витрат на ручну перевірку функціональності після змін і зниження ризику ефекту хвилі під час доопрацювань. На практиці це кілька рівнів перевірки:
- Тести бізнес-правил: розрахунки, знижки, статуси, переходи між станами. Швидкі й дешеві, їх найбільше.
- Тести обміну із зовнішніми системами: платежі, CRM, служби доставки. Відповіді зовнішніх сервісів підміняються, щоб тест не залежав від чужої доступності.
- Наскрізні сценарії в браузері: реєстрація, замовлення, оплата, робота в кабінеті. Ми використовуємо для цього Playwright.
- Тест матриці доступу: якій ролі які екрани й дії належать.
- Тестові дані, що виглядають як справжні: генеруються через Faker, без копіювання реальних клієнтів.
- Запуск усіх перевірок за кожної зміни коду в процесі CI/CD, який налаштовують на етапі деплою та інфраструктури.
Що покривати насамперед
Не все поспіль. Спершу те, де помилка коштує грошей: розрахунки, права доступу, оформлення замовлення, обмін із зовнішніми системами з інтеграцій. Тест на колір кнопки зазвичай не окуповується ніколи.
Окремо корисно закривати тестом матрицю доступу. Це єдиний надійний спосіб, щоб права не «роз'їжджалися» під час доопрацювань, і він напряму підтримує безпеку.
Як проходить впровадження
- Розбір: разом із Вами складаємо перелік сценаріїв, помилка в яких коштує грошей, і ранжуємо їх за ціною помилки.
- Підготовка: налаштовуємо тестове середовище, генерацію даних і автоматичний запуск перевірок.
- Покриття: пишемо тести від найдорожчих сценаріїв до менш важливих і показуємо кожен пакет у роботі.
- Передача: звіт про те, що покрито, і перелік сценаріїв, які варто закрити наступними.
Що Ви отримуєте
- Набір автотестів на грошові сценарії, вбудований у процес випуску.
- Звіт після кожної зміни: що перевірено і що впало, із зазначенням місця.
- Можливість випускати оновлення частіше й меншими порціями, а отже, безпечніше.
- Страховку для рефакторингу і для роботи нових розробників, які ще не знають усіх зв'язків системи.
Економіка проста
Ручна перевірка коштує однаково щоразу. Автоматична коштує дорого один раз і майже нічого далі. Точка окупності настає тим швидше, чим частіше Ви випускаєте зміни.
Скільки коштує і від чого залежить
Орієнтир у прайсі: $4700 за напрям. Обсяг залежить від кількості грошових сценаріїв, ролей та інтеграцій, а також від того, наскільки код готовий до тестування. Якщо бізнес-логіку розмазано по шаблонах і контролерах, спершу потрібен точковий рефакторинг, інакше тести виходять крихкими. Якщо проєкт робила інша команда, першим кроком іде аудит: $800 або $2400.
Не плутайте цей напрям з етапом тестування та передачі (від $800 до $4700). Там перевіряють і виправляють зроблене за ТЗ перед здачею проєкту. Тут створюють механізм, який сам повторює перевірки за кожної наступної зміни.
Що ламається, якщо заощадити
- Помилки знаходять клієнти, і кожна коштує замовлення, відгуку чи дзвінка в підтримку.
- Релізи відкладаються, бо на ручну перевірку немає часу.
- Права доступу непомітно розходяться: співробітник бачить те, що йому не належить.
- Рефакторинг стає лотереєю, і код перестають покращувати.
Приклад із практики
У нашій технології Fractal тести вбудовано в сам процес виробництва систем. Генератор перевіряється на еталонних схемах, а за згенерованими екранами будуються наскрізні сценарії Playwright. Тому кожен новий прототип чи модуль одразу отримує базову перевірку інтерфейсу, без ручного написання сценаріїв. Детальніше в кейсі про ШІ-програміста, який пише за архітектурою.
Той самий підхід працює й поза кодом продукту. У нашому конвеєрі новин правила заголовків (довжина заголовка для видачі до 60 символів, фірмовий суфікс рівно один раз) тримає тест, а не уважність редактора. Правило, закріплене тестом, не забувається, коли змінюються люди.
Куди далі
Суміжні напрями: рефакторинг та документування. Мапа всіх етапів у стратегії розробки застосунку.
На безкоштовній консультації архітектор Ingello розбере, які сценарії у Вашій системі коштують грошей у разі помилки, і запропонує, з чого почати покриття. Після неї Ви отримуєте розрахунок ціни й термінів за етапами. Обговорити якість продукту.
