Как определяешь, какие фичи автоматизировать, а какие нет?

Стратегия отбора фич для автоматизации

Приоритизация автоматизации — это не технический, а скорее экономико-стратегический процесс, основанный на анализе возврата инвестиций (ROI). Вот мой алгоритм принятия решений, основанный на многолетнем опыте.

Критерии отбора (по убыванию важности)

1. Частота исполнения и бизнес-критичность

• Автоматизируем в первую очередь: Высокочастотные сценарии (ежедневные smoke-тесты, регресс, критические user journey — например, «покупка товара» в e-commerce). Чем чаще тест выполняется вручную, тем выше экономия времени от автоматизации.
• Пример: Тест логина выполняется перед каждым билдом → автоматизируем всегда.
• Не автоматизируем или откладываем: Узкоспециализированные сценарии, выполняемые раз в квартал или реже (например, генерация специфического отчета для бухгалтерии).

2. Стабильность функционала

• Автоматизируем: Зрелые, стабильные модули продукта, API-контракты, базовые алгоритмы. Их поведение меняется редко, значит, автоматизация будет «жить» долго.
• Не автоматизируем: Фичи в активной разработке, интерфейсы, которые меняются каждый спринт, экспериментальный функционал. Автоматизация таких элементов приведет к высоким затратам на поддержку. Используем ручное тестирование или прототипы скриптов.

3. Сложность ручного выполнения и риск человеческой ошибки

• Автоматизируем:

    *   Сценарии с большим объемом данных (проверка граничных значений, нагрузочные сценарии).
    *   Криптографические расчеты, сложные математические проверки.
    *   Многошаговые подготовительные прекондишены (например, создание сложного окружения).

• Не автоматизируем: Простые, интуитивные проверки «на глаз» (корректность отображения шрифта на одной странице).

4. Возможность и стоимость автоматизации (Feasibility)

Здесь проводится технико-экономическая оценка:

• Автоматизируем, если: Есть стабильные селекторы (API эндпоинты, ID элементов), доступны необходимые инструменты и экспертиза в команде. Стоимость разработки автотеста < (Время на ручной прогон * Количество прогонов за срок жизни фичи).
• Не автоматизируем, если: Элементы генерируются динамически без атрибутов, для тестирования требуется дорогое или уникальное железо (например, специфический сканер отпечатков), а команде не хватает компетенций. Иногда правильнее улучшить тестируемость продукта (добавить test-id), а потом автоматизировать.

5. Обязательства перед регуляторами

• Автоматизируем: Обязательные проверки, требуемые стандартами (например, в финтехе или медицине), чтобы иметь исполняемую документацию и четкий аудит-трейл.

Практическая матрица принятия решений

Я визуализирую приоритизацию на плоскости с осями «Бизнес-важность/Частота» и «Сложность автоматизации/Стабильность».

quadrantChart
    title "Матрица приоритизации автоматизации"
    x-axis "Низкая сложность / Высокая стабильность" --> "Высокая сложность / Низкая стабильность"
    y-axis "Низкая важность / частота" --> "Высокая важность / частота"
    "Критические сценарии (Логин, оплата)": [0.2, 0.9]
    "Стабильные API, расчеты": [0.1, 0.6]
    "Частые, но меняющиеся UI-элементы": [0.8, 0.7]
    "Разовые/экзотические сценарии": [0.9, 0.2]

Высший приоритет (левый верхний квадрат): Высокая важность + низкая сложность автоматизации. Берем в работу сразу.

Процесс и команда

Решение никогда не принимается автотестером в вакууме. Это коллаборация:

1. Менеджер/Владелец продукта предоставляет данные о бизнес-важности и частоте использования фичи.
2. Разработчик дает оценку стабильности компонента и помогает улучшить тестируемость.
3. Ручной тестировщик делится болью — какие проверки самые рутинные, сложные или подвержены ошибкам.
4. Автотестер (я) консолидирую данные, даю оценку сложности и времени на автоматизацию, после чего мы вместе с командой принимаем взвешенное решение.

Золотое правило

Автоматизация — это не цель, а инструмент. Ее задача — не покрыть код 100% автотестами, а максимально увеличить уверенность в качестве продукта, высвободив время команды на исследовательское тестирование, тестирование новых сложных фич и улучшение процессов. Иногда лучший ответ на вопрос «Автоматизировать ли эту фичу?» — «Нет, давайте проверим ее вручную один раз и закроем, а силы потратим на автоматизацию стабильного ядра».