Автоматизация тестирования — это инвестиция. Как любая инвестиция, она требует анализа ROI (Return on Investment). Не всё нужно автоматизировать, и не всё выгодно автоматизировать. Эта статья помогает принять решение: что автоматизировать, когда это делать, а когда лучше остаться на ручном тестировании.
ROI автоматизации
Формула ROI
ROI = (Стоимость ручного тестирования — Стоимость автоматизации) / Стоимость автоматизации × 100%
Где:
Стоимость ручного тестирования = Время_ручного × Частота_запуска × Ставка_тестировщика
Стоимость автоматизации = Разработка + Поддержка + Инфраструктура
Когда автоматизация окупается
Фактор
Автоматизация выгодна
Автоматизация НЕ выгодна
Частота запуска
Регрессия каждую итерацию
Тест один раз в год
Стабильность функционала
Стабильный, давно не менялся
Часто меняется
Время ручного выполнения
2+ часа ручного теста
5 минут проверки
Критичность
Критичные бизнес-процессы
Низкоприоритетные фичи
Количество данных
Data-driven (100+ комбинаций)
2-3 сценария
Среда
Стабильная CI/CD
Нестабильная инфраструктура
Пример расчёта
Ручное тестирование регрессии:
- Время: 8 часов (1 день)
- Частота: 2 раза в спринт (10 рабочих дней)
- Ставка: 2000 руб/час
- Стоимость в спринт: 8 × 2 × 2000 = 32 000 руб
Автоматизация того же объёма:
- Разработка: 40 часов × 2000 = 80 000 руб (разово)
- Поддержка: 4 часа в спринт × 2000 = 8 000 руб
- Запуск CI: 1000 руб/спринт
Окупаемость:
Экономия в спринт: 32 000 - 9 000 = 23 000 руб
Окупаемость: 80 000 / 23 000 ≈ 3.5 спринта (≈ 7 недель)
Что автоматизировать
1. Регрессионное тестирование (Regression)
Что: Набор тестов, проверяющих, что существующий функционал не сломался после изменений.
Почему автоматизировать:
Выполняется на каждом спринте / релизе
Объём растёт с каждой новой фичей
Идеален для автоматизации — стабильные сценарии, повторяющиеся проверки
Примеры:
Оформление заказа (весь флоу)
Авторизация и управление аккаунтом
CRUD операции (создание, чтение, обновление, удаление)
Поиск и фильтрация
Инструменты:
UI: Selenium, Playwright, Cypress
API: Postman, Rest Assured, requests
2. Smoke-тесты (Smoke)
Что: Минимальный набор критичных проверок для быстрой оценки стабильности билда.
Почему автоматизировать:
Запускается на каждый билд / деплой
Должен выполняться быстро (5-15 минут)
При провале — остановка пайплайна
Примеры:
Главная страница открывается (HTTP 200)
Пользователь может залогиниться
API-healthcheck отвечает
Основные эндпоинты возвращают 200
Свойства хорошего smoke-набора:
Быстрый (< 10 минут)
Стабильный (не падает от фликеров)
Критичный (покрывает P0-функционал)
Самодостаточный (каждый тест независим)
3. Data-Driven тесты (DDT)
Что: Один тест с множеством наборов данных. Логика одна, данные разные.
Почему автоматизировать:
Вручную проверить 100+ комбинаций нереалистично
Легко добавлять новые наборы данных
Идеально для валидации полей
Примеры:
Валидация форм (email, телефон, ИНН) — 50+ вариантов
Калькулятор (разные входные данные → разные результаты)
Почему нет: Требует человеческой интуиции, креативности, случайных маршрутов. Автоматизация не может «исследовать» — она выполняет заранее заданные шаги.
Что делать: Выделять время на мануальное исследование. Автоматизация покрывает проверенное, человек исследует новое.
2. UX / юзабилити-тестирование
Почему нет: Субъективные оценки («красиво», «удобно», «понятно») не алгоритмизируемы.
Что делать: Проводить юзабилити-тесты с реальными пользователями. Автоматизация может проверить accessibility (a11y), но не удобство.
3. Тестирование нестабильного функционала
Почему нет: Если требования меняются каждую неделю, автоматизированные тесты устареют раньше, чем окупятся.
Что делать: Дождаться стабильности. Использовать manual для «горячих» фич.
Критерий: Если за последний месяц функционал изменился 3+ раза — не автоматизировать.
4. Тесты с нестабильной средой
Почему нет: Если тесты падают из-за среды (а не из-за багов), команда теряет доверие к автоматизации.
Что делать: Сначала стабилизировать инфраструктуру (testcontainers, sandbox, моки), потом автоматизировать.
5. «Одноразовые» тесты
Почему нет: Тест, который запускается один раз (миграция данных, разовая проверка), не окупит время на написание.
Что делать: Проверить вручную или написать скрипт (не полноценный автотест с фреймворком).