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

С 2021 года мы наблюдаем устойчивый рост мирового рынка тестирования — в среднем на 14% в год. Согласно исследованию Performance Lab, 80% респондентов из числа 423 крупнейших IT-компаний освоили практики DevOps и автоматизации тестирования, а к 2025 году 94% компаний планируют внедрить автоматизацию тестирования. Основные цели, которые при этом преследует бизнес, связаны с ускорением и оптимизацией процессов тестирования и сокращением времени вывода продукта на рынок (time to market). 

Как показывает практика SimbirSoft, большую часть запросов на автоматизацию составляет тестирование API, веб- и мобильных приложений. В этой статье на конкретном примере расскажем, кому может быть выгодна автоматизация тестирования и какие результаты можно получить в итоге. Материал будет полезен руководителям проектов, владельцам IT-продуктов и лидам разработки.

Как можно оценить эффективность использования автоматизированного тестирования

Согласно тому же исследованию Performance Lab, внедрение автоматизации тестирования окупается у 74% компаний. Главным инструментом оценки эффективности автотестов являются метрики. С их помощью можно наглядно и объективно провести оценку в любой период времени. 

Однако при сборе метрик важно найти золотую середину — собирать и обрабатывать только необходимый набор данных, исключая избыточные, не объективные и не важные. Далее раскроем на конкретном примере. Правильно подобранный набор метрик поможет оптимизировать внутренние процессы и затраты на реализацию задач, повысить качество и сократить time to market, а значит быстрее начать получать прибыль от его использования. 

Важно! Эффект от автоматизации тестирования, безусловно, достигается вместе с ручным тестированием. Сокращение времени на регрессионное тестирование (далее — регресс) позволяет QA-специалистам фокусироваться на анализе и ревью требований, разработке тестовой документации, анализе отчетов, работе с дефектами и раннем тестировании фич. Важность этих активностей трудно недооценить, а нехватка времени на них может значительно повлиять на качество продукта в целом. Что может быть, если сэкономить на тестировании, рассказывали в этой статье.

Кто клиент и с какой задачей обратился

К нам обратился один из крупных маркетплейсов с проблемой эффективности существующего процесса тестирования, которые заказчик планировал решить за счет внедрения автоматизации тестирования. Эти проблемы заключались в длительных регрессах, которые сильно повлияли на time to market, критичных багах на продакшене и небольшом количестве существующих автотестов. Дополнительно клиент хотел расширить покрытие автотестами и внедрить интеграцию с таск-трекером и TMS-системой.

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

Какое решение мы предложили

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

• Скорость обратной связи и быстрота обнаружения дефектов. Чем она выше, тем быстрее и с меньшими трудозатратами можно локализовывать и исправлять дефекты, тем ниже будет количество багов на продакшн
• Passrate (процент успешно пройденных в рамках прогона) тестов. Эта метрика будет свидетельствовать о сокращении ресурсов на поддержку тестов со стороны инженеров и значительно экономить время QA, что в итоге положительно отразится на скорости тестирования
• Время прохождения тестового набора. Чем оно меньше, тем чаще мы сможем запускать тесты и быстрее получать обратную связь по ним, а значит быстрее выявлять дефекты в сборке (готовой к тестированию и развертыванию версии приложения)

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

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

К каким результатам пришли

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

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

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

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

Мы разработали полноценный фреймворк для автотестов, который позволил разрабатывать тесты быстрее, делать их алгоритмы оптимальнее и значительно повысить качество самих тестов, снижая количество flaky-тестов (автотесты, которые имеют свойство проходить или падать без изменений на уровне приложения или в самой логике тестов). Не последнюю роль сыграло и внедрение системы логирования и регулярные (например, еженедельные) полные прогоны тестов, которые позволяют заблаговременно выявлять и быстро «чинить» нестабильные тесты.

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

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

Повышение стабильности тестов положительно повлияло на среднее время прохождения тестового набора (например, за счет уменьшения времени на их перезапуск), но целевых метрик по времени достигнуть не получилось. Тогда мы продолжили анализ артефактов тестирования и процессов и выяснили, что для проведения регрессионного тестирования приложения команда использовала около 500 тест-кейсов. Изначально на ручное тестирование такого объема тест-кейсов уходило 30 часов. Мы продолжили покрывать автотестами наиболее критичные места приложения и смогли снизить среднее время прохождения регрессионного тестирования до 14 часов. 

В нашем случае экономия составила около 55%, а в среднем автотесты позволяют экономить как минимум от 30 до 50% времени. Как мы писали выше, сокращение времени на регресс позволяет QA-специалистам фокусироваться на анализе и ревью требований, разработке тестовой документации, анализе отчетов, работе с дефектами и раннем тестировании фич. Тем самым, уделить больше внимания развитию и улучшению продукта.

Выводы

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