Как с помощью автотестов ускорить разработку и снизить затраты проекта

В современной индустрии разработки ПО скорость выхода продукта на рынок и частота его обновлений — это критически важные конкурентные преимущества. При этом гарантия качества продукта путем его тестирования остается ключевым фактором успеха. Однако на практике стремление к регулярным релизам упирается в проблему регрессионного тестирования. С каждой новой итерацией объем необходимых регрессионных тестов возрастает, что не только увеличивает нагрузку на ресурсы, но и повышает вероятность ошибок, обусловленных человеческим фактором.

В этой статье предлагаем разобраться, как автоматизация функционального тестирования ускоряет цикл разработки и снижает затраты самого проекта.

Частые проблемы при проведении тестирования

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

Автоматизация тестирования нужна, чтобы:

• тестировать быстрее и эффективнее;
• выпускать продукт оперативнее, устраняя и исправляя дефекты;
• уменьшить затраты, снижая необходимость ручного труда;
• сделать процесс прозрачным, понятным и контролируемым.

Как автоматизация тестирования ускоряет разработку

Смоук‑ и регрессионное тестирование — одни из самых ресурсоемких и рутинных процессов для QA‑инженера. Именно поэтому их автоматизация часто становится первоочередной задачей при внедрении автоматизированного тестирования на проекте.

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

Чтобы посчитать, сколько времени сэкономит автоматизация, сначала нужно понять, чем ручные тесты отличаются от автоматизированных.

Допустим, процессы тестирования на проекте выстроены, имеется тестовая документация, определена стратегия тестирования и составлены тест‑кейсы. В данном случае приступить к ручному тестированию по имеющимся тест‑кейсам легко — результаты (прохождение тестов либо выявление дефектов) будут видны сразу. Внедрение автоматизированных тестов требует времени, и итоговый отчет формируется с задержкой. Но в долгосрочной перспективе автотесты выгоднее: время, потраченное на их создание, компенсируется многочисленными повторными запусками.

Разница во времени между ручным и автотестированием

Т общ = (Т кейсы + Т данные + Т анализ) × N регрессов

где:

• T общ — общее время, затрачиваемое на тестирование за месяц;
• T кейсы — время на выполнение тест‑кейсов;
• T данные — время на подготовку тестовых данных;
• T анализ — время на анализ результатов тестирования;
• N регрессов — количество регрессионных тестирований в месяц.

По аналогии общие затраты времени на тестирование после автоматизации составят:

T общ = (T анализ + T поддержки) × N регрессов 

где

• T общ — общее время, затрачиваемое на тестирование за месяц;
• T анализ — время на анализ результатов тестирования;
• T поддержки — время на поддержку автотестов;
• N регрессов — количество регрессионных тестирований в месяц.

Экономию времени проведения самого тестирования можно представить как разницу между этими двумя значениями.

Сразу стоит отметить, что внедрение автотестов требует разовых вложений времени на настройку. Но этот этап включает не только автоматизацию тестовых сценариев, но и выполнение сопутствующих операций с тестовым окружением. Например:

• генерацию необходимых тестовых данных;
• установку дополнительных библиотек;
• процессы очистки данных после прогона тестов.

Таким образом, сами автотесты, все пред‑ и постпроцессы проходят в рамках автоматизации, а запускаются во время каждого прогона. Это означает, что весь цикл работы с автоматизированными тестами (не только сами проверки, но и сопутствующие процессы) выполняется программно — без ручного вмешательства.

Кейс: автоматизация регрессионных тестов на проекте 

Пример из практики: регресс‑пак включает в себя около 700 тест‑кейсов, каждый из которых выполняется от 70 до 100 раз в год. Из них примерно 500 кейсов подлежат автоматизации, остальные необходимо тестировать вручную.

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

До автоматизации полный прогон регресс‑тестов занимал порядка 30 часов.

После автоматизации основной объем работы выполняется автотестами в ночное время без участия человека (порядка 3–4 часов). На проверку оставшихся тест‑кейсов, которые невозможно было покрыть автотестами, уходит еще порядка 8 часов. После завершения тестирования около 3 часов тратится на анализ результатов прогона и выявление причины падений автотестов.

Итогом внедрения процессов автоматизации стало сокращение общих трудозатрат с 30 до 11 часов на один цикл регресса.

В среднем автоматизация позволяет экономить от 30 % до 50 % времени, которое можно перенаправить на более сложные и продуктивные задачи: исследовательское тестирование, углубленную проверку новых функций и улучшение качества продукта.

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

Оптимизация времени тестирования

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

• Предварительная генерация тестовых данных и кэширование результатов внешних запросов. Вместо того чтобы создавать данные и обращаться к внешним сервисам при каждом запуске, эти операции можно выполнить заранее. Полученные данные можно многократно использовать в тестах — это существенно сокращает время выполнения.
• Использование моков и стабов. Моки и стабы позволяют воссоздать поведение внешних сервисов. Это избавляет от постоянного обращения к реальным системам при проведении проверок.
• Параллельный запуск тестов. Распределение автотестов на несколько процессов или машин позволяет запускать их одновременно. Такой подход может сократить общее время прогона тестового набора в несколько раз, что ускоряет обратную связь и повышает эффективность работы команды.

Еще одной важной особенностью является настраиваемый прогон автотестов. Современные инструменты тестирования позволяют настраивать запуск различных групп тестов в зависимости от конкретных целей. Тесты можно помечать специальными метками для удобного управления их выполнением. Например, запустить только тестирование графического интерфейса (UI) или проверку взаимодействия между различными компонентами или модулями приложения (API), выполнить быструю проверку основного функционала продукта (смоук‑тест) или регрессионное тестирование для более обширной проверки продукта, а также создать набор тестов для выполнения конкретной задачи.

Тесты можно настраивать: запускать или пропускать в зависимости от того, готова ли функция и подходит ли окружение (ОС, платформа, браузер). Все это автоматизируется — данные берутся из настроек или окружения.

Кроссбраузерное тестирование

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

Автотесты как часть пайплайна

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

Как отмечалось ранее, автоматизированные тесты могут запускаться:

• по расписанию (в ночное время);
• по триггеру — при сборке тестового стенда или при подаче запроса на слияние веток кода.

После завершения тестирования формируется отчет, который содержит:

• время выполнения тестов;
• развернутое описание результатов;
• статистику по пройденным и упавшим тестам;
• скриншоты (при необходимости).

Таким образом, QA‑инженеру остается только просмотреть отчет и разобрать упавшие тесты, эффективно распределив рабочее время.

Так автоматизация встраивается в разработку в рамках CI/CD — автоматизации процессов разработки ПО, которая включает непрерывную интеграцию (автоматическую сборку и тестирование) и непрерывную доставку (CD). Такой подход помогает обнаружить баги на раннем этапе за счет запуска тестов (при изменении кода в нужной ветке). Это значит, что разработчик оперативно получает информацию о влиянии внесенных им изменений на работу модуля, где ведется разработка, и, самое важное, на систему в целом.

Чем раньше обнаружен баг, тем проще и дешевле его исправить. Во‑первых, разработчик уже погружен в контекст и знает о внесенных изменениях, а если баг выявлен позже (например, на регрессе), то его исправление можно поручить другому свободному разработчику. Во‑вторых, в ходе регрессионного тестирования может быть обнаружено множество дефектов — их устранение требует много времени. В условиях высокой загруженности разработчиков существует риск накопления багов, что приводит к их переносу в следующий спринт.

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

Краткие выводы

Автоматизация тестирования, особенно в связке с CI/CD, ускоряет разработку: команда получает возможность выпускать качественные обновления чаще, с большей уверенностью и меньшими затратами.

Но при этом автоматизация тестирования может быть малоэффективной в следующих случаях:

• когда функциональность проверяется всего несколько раз и нет необходимости в повторных запусках тестов;
• при частых изменениях функционала, из‑за которых автотесты быстро устаревают и требуют обновления;
• на этапе разработки MVP (минимально жизнеспособного продукта), когда приоритет — быстрая проверка ключевых функций вручную;
• в условиях острой нехватки времени, когда разработка автотестов может задержать выпуск;
• когда требуется оценка, которую может дать только человек, например тестирование удобства использования (usability) и доступности (accessibility).