Автоматизация тестирования: когда она окупается

Автоматизация тестирования — это программы, которые сами проверяют работу системы: нажимают кнопки, отправляют запросы, сравнивают результаты с ожидаемыми. Автотесты не устают и не пропускают шаги, но их нужно писать и поддерживать. Поэтому вопрос не «нужна ли автоматизация», а «что именно автоматизировать».

Когда автоматизация окупается

• Система регулярно обновляется, и перед каждым выпуском нужно проверять, что старые функции не сломались
• Есть стабильные критичные сценарии: оформление заказа, оплата, запись, расчёт
• Ручная регрессия занимает дни и откладывает выпуски
• Проект долгоживущий и будет развиваться годами
• Есть интеграции, которые ломаются незаметно при изменениях на другой стороне

Когда рано

Продукт меняется каждую неделю, и интерфейс ещё не устоялся: тесты придётся переписывать постоянно. Разовый проект без дальнейших доработок. Прототип для проверки гипотезы. В этих случаях достаточно ручного тестирования по чек-листу.

Пирамида тестирования

Модульные тесты

Проверяют отдельные функции: расчёт скидки, проверку статуса, преобразование данных. Пишутся разработчиками, выполняются за секунды, их может быть очень много. Основание пирамиды.

Интеграционные тесты и тесты API

Проверяют, как части системы работают вместе: API принимает заказ, сохраняет в базу, возвращает правильный ответ. Быстрее и стабильнее тестов интерфейса, при этом ловят большую часть реальных ошибок.

Сквозные тесты интерфейса

Имитируют пользователя в браузере или приложении: открыть сайт, найти товар, оформить заказ. Самые близкие к реальности, но медленные и хрупкие: смена надписи на кнопке может сломать тест. Их должно быть немного — только для главных сценариев.

Частая ошибка — перевёрнутая пирамида: сотни медленных тестов интерфейса и почти нет модульных. Такие наборы долго выполняются и постоянно «краснеют» без реальных ошибок.

Что оставить ручным тестировщикам

Исследовательское тестирование новых функций, проверку удобства интерфейса, внешний вид на разных устройствах, нестандартные сценарии, которые сложно предсказать заранее. Автотесты проверяют известное, люди находят неизвестное.

Как начать

1. Составьте список критичных сценариев, поломка которых обходится дороже всего.
2. Начните с тестов API для этих сценариев: они дают наибольшую отдачу.
3. Добавьте несколько сквозных тестов на самые важные пользовательские пути.
4. Настройте автоматический запуск тестов при каждом изменении кода, до выпуска.
5. Договоритесь, что упавший тест — повод остановить выпуск, а не отключить тест.

Поддержка автотестов

Тесты — тоже код, и они требуют внимания. При изменении функций тесты обновляются вместе с ними. Нестабильные тесты, которые падают то так, то так, нужно чинить сразу, иначе команда перестанет доверять результатам. Тестовые данные должны готовиться автоматически, а не зависеть от состояния общей тестовой базы.

Как оценить эффект

Сравните, сколько времени занимает проверка перед выпуском до и после, сколько ошибок доходит до пользователей, как часто команда может выпускать обновления. Если автотесты есть, но выпуски по-прежнему сопровождаются ручной полной регрессией, значит, им не доверяют — и это нужно разобрать.

Вопросы подрядчику

Какие виды тестов вы пишете? Как часто они запускаются? Что происходит, если тест упал перед выпуском? Будут ли тесты переданы нам вместе с кодом? Ответы покажут, станет ли автоматизация реальной защитой или останется пунктом в коммерческом предложении.

Отдельно уточните, кто будет поддерживать автотесты после окончания проекта. Если поддержка переходит к вашей команде или другому подрядчику, тесты должны запускаться одной командой по инструкции, а не только на компьютере автора.