Эффект ряби: правка в одном углу системы ломает что-то в противоположном, и никто не замечает этого до жалобы клиента. Чем старше продукт, тем дороже каждая такая волна. Автоматизация тестирования ставит на пути этой волны проверку, которая срабатывает за минуты после каждого изменения, а не через неделю в виде потерянного заказа.
Это направление из блока корпоративного развития. Оно подключается, когда продукт уже работает и переходит от MVP к MMP и MLP, а выпуск обновлений становится регулярным. Ориентир стоимости направления в прайсе Ingello: $4700.
Во что обходится ручная проверка
Пока система маленькая, её можно прокликать перед каждым релизом. Потом сценариев становится десятки, ролей несколько, интеграций больше одной, и полная ручная проверка занимает дни. Команда начинает проверять выборочно, и ошибки уходят к пользователям. Или релизы становятся редкими и крупными, а значит, ещё более рискованными.
Что входит в работу
В прайсе направление описано тремя пунктами: внедрение автоматических тестов, снижение затрат на ручную проверку функциональности после изменений и снижение риска эффекта ряби при доработках. На практике это несколько уровней проверки:
- Тесты бизнес-правил: расчёты, скидки, статусы, переходы между состояниями. Быстрые и дешёвые, их больше всего.
- Тесты обмена с внешними системами: платежи, CRM, службы доставки. Ответы внешних сервисов подменяются, чтобы тест не зависел от чужой доступности.
- Сквозные сценарии в браузере: регистрация, заказ, оплата, работа в кабинете. Мы используем для этого Playwright.
- Тест матрицы доступа: какой роли какие экраны и действия положены.
- Тестовые данные, которые выглядят как настоящие: генерируются через Faker, без копирования реальных клиентов.
- Запуск всех проверок при каждом изменении кода в процессе CI/CD, который настраивается на этапе деплоя и инфраструктуры.
Что покрывать в первую очередь
Не всё подряд. Сначала то, где ошибка стоит денег: расчёты, права доступа, оформление заказа, обмен с внешними системами из интеграций. Тест на цвет кнопки обычно не окупается никогда.
Отдельно полезно закрывать тестом матрицу доступа. Это единственный надёжный способ, чтобы права не «разъезжались» при доработках, и он напрямую поддерживает безопасность.
Как проходит внедрение
- Разбор: вместе с Вами составляем список сценариев, ошибка в которых стоит денег, и ранжируем их по цене ошибки.
- Подготовка: настраиваем тестовое окружение, генерацию данных и автоматический запуск проверок.
- Покрытие: пишем тесты от самых дорогих сценариев к менее важным и показываем каждый пакет в работе.
- Передача: отчёт о том, что покрыто, и список сценариев, которые стоит закрыть следующими.
Что Вы получаете
- Набор автотестов на денежные сценарии, встроенный в процесс выпуска.
- Отчёт после каждого изменения: что проверено и что упало, с указанием места.
- Возможность выпускать обновления чаще и мельче, а значит, безопаснее.
- Страховку для рефакторинга и для работы новых разработчиков, которые ещё не знают всех связей системы.
Экономика простая
Ручная проверка стоит одинаково каждый раз. Автоматическая стоит дорого один раз и почти ничего дальше. Точка окупаемости наступает тем быстрее, чем чаще Вы выпускаете изменения.
Сколько стоит и от чего зависит
Ориентир в прайсе: $4700 за направление. Объём зависит от числа денежных сценариев, ролей и интеграций, а также от того, насколько код готов к тестированию. Если бизнес-логика размазана по шаблонам и контроллерам, сначала нужен точечный рефакторинг, иначе тесты получаются хрупкими. Если проект делала другая команда, первым шагом идёт аудит: $800 или $2400.
Не путайте это направление с этапом тестирования и передачи (от $800 до $4700). Там проверяется и исправляется то, что сделано по ТЗ, перед сдачей проекта. Здесь создаётся механизм, который повторяет проверки сам при каждом следующем изменении.
Что ломается, если сэкономить
- Ошибки находят клиенты, и каждая стоит заказа, отзыва или звонка в поддержку.
- Релизы откладываются, потому что на ручную проверку нет времени.
- Права доступа незаметно расходятся: сотрудник видит то, что ему не положено.
- Рефакторинг становится лотереей, и код перестают улучшать.
Пример из практики
В нашей технологии Fractal тесты встроены в сам процесс производства систем. Генератор проверяется на эталонных схемах, а по сгенерированным экранам строятся сквозные сценарии Playwright. Поэтому каждый новый прототип или модуль получает базовую проверку интерфейса сразу, без ручного написания сценариев. Подробнее в кейсе об ИИ-программисте, который пишет по архитектуре.
Тот же подход работает и вне кода продукта. В нашем конвейере новостей правила заголовков (длина заголовка для выдачи до 60 символов, фирменный суффикс ровно один раз) держит тест, а не внимательность редактора. Правило, закреплённое тестом, не забывается при смене людей.
Куда дальше
Смежные направления: рефакторинг и документирование. Карта всех этапов в стратегии разработки приложения.
На бесплатной консультации архитектор Ingello разберёт, какие сценарии в Вашей системе стоят денег при ошибке, и предложит, с чего начать покрытие. После неё Вы получаете расчёт цены и сроков по этапам. Обсудить качество продукта.
