Стратегия автоматизации тестирования для Agile-проектов

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

Описанная в этой статье стратегия автоматизации тестирования предполагает модель постоянной поставки с несколькими командами, работающими по методологии Agile.

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

Краткое содержание

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

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

Это требует «инвертирования пирамиды автоматизации тестирования» с отказом от GUI-тестов, которые занимают много времени, в пользу тестирования на более низких уровнях, например, API, где автоматические тесты можно запустить сразу после unit-тестов как часть сборки, чтобы обеспечить базовый уровень надёжности.

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

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

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

Как уже упоминалось, быстрое информирование разработчиков о состоянии приложения имеет огромное значение при непрерывной поставке, следовательно, надо найти механизм, которые позволит быстро давать обратную связь. Один из способов — увеличить количество unit-тестов, интеграционных тестов и тестов API. Эти низкоуровневые тесты формируют сеть безопасности, которая помогает убедиться, что приложение работает так, как было задумано, и позволяет предотвратить дефекты, возникающие на других уровнях тестирования. Unit-тесты служат основой для автоматизации тестирования на более высоких уровнях.

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

Регрессионное тестирование

Автоматические регрессионные тесты — основа стратегии автоматизации тестирования.

«Дымовой» пакет регрессионных тестов нужен для проверки того, что приложение загружается и запускается. В него также входят несколько ключевых сценариев, позволяющих убедиться, что приложение ещё работает.

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

Такие тесты запускаются при каждом развёртывании приложения и могут содержать как API, так и GUI-тесты.

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

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

Эти пакеты должны запускаться в различных окружениях по мере необходимости и проверять, что поведение приложения остаётся неизменным вне зависимости от окружения. Такие тесты запускаются несколько раз в день и должны продолжаться не дольше 15-30 минут.

Поскольку эти тесты более детализированы и занимают больше времени, важно выносить большую часть функциональных тестов на уровень API, где тестирование проходит быстрее. Это нужно для того, чтобы не выходить за временные рамки в 15-30 минут.

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

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

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

Стратегия автоматизации тестирования для нескольких Agile-команд

Автоматизированные unit-тесты

Автоматизация тестирования начинается на уровне unit-тестов. Эти тесты должны создаваться для каждой новой возможности, находящейся в разработке. Именно они ложатся в основу более широкой практики автоматизации вплоть до системных GUI-тестов. Разработчики обязаны убедиться в том, что для каждой новой функциональной возможности разработан полный набор надёжных unit-тестов, позволяющих проверить, что код работает как задумано и отвечает всем требованиям. Unit-тесты наиболее выгодны с точки зрения окупаемости, поскольку их недолго написать, легко поддерживать и изменять (благодаря тому, что нет зависимостей), так что если в коде есть ошибка, то разработчик быстро узнает о ней. Unit-тесты должны запускаться как на компьютере разработчика, так и в среде непрерывной интеграции.

Автоматическая интеграция / API-тесты или сервис-тесты

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

Сервис-тесты обычно запускаются на уровне API без вовлечения GUI-интерфейса, следовательно, тесты направлены на проверку функциональности в чистом виде, а поскольку тесты непосредственно обращаются к компонентам, они быстро проводятся и могут быть частью сборки. При необходимости тестирования взаимодействия с внешними сервисами, в случае, если внешние сервисы не доступны либо не могут гарантировать предоставление данных, отвечающих условиям тестирования, можно использовать эмуляторы внешних сервисов, например WireMock. API-тесты и/или сервис-тесты могут запускаться на компьютере разработчика или быть частью сборки, но если они начинают занимать длительное время, лучше запускать их в среде непрерывной интеграции. Для сервис-тестов можно использовать такие инструменты, как SoapUI.

Тесты приложения

На практике крупное приложение, например, система для электронной коммерции, может быть разбито на несколько приложений, предоставляющих различные возможности. Концепция «тестирования приложений» заключается в том, что группы тестов, направленные на возможности одного приложения, объединяются и прогоняются для этого приложения. Этот пакет можно использовать в случаях, когда команда планирует выпустить индивидуальное приложение и хочет проверить, всё ли работает корректно.

Чтобы протестировать приложение в целом, обычно требуется интерфейс для взаимодействия между различными его компонентами, а значит, тестирование лучше проводить с использованием браузера или GUI. Цель этих тестов — убедиться в том, что приложение работает корректно. Такие тесты называют “вертикальными”, т.к. они направлены на проверку работоспособности конкретного приложения или компонента, а не всей системы целиком. Эти тесты отличаются глубиной проработки и большим объёмом.

Для проведения таких тестов в браузере можно использовать Selenium WebDriver. Этот инструмент является наиболее популярным для проведения автоматизированного тестирования в браузерах и предоставляет богатые возможности API для проведения сложных проверок.

Полные сценарные тесты

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

Инвертирование пирамиды автоматизации тестирования

В рамках стратегии автоматизации тестирования нам необходимо минимизировать количество автоматизированных тестов на уровне GUI.

Несмотря на то, что проведение автоматизированного GUI-тестирования даёт хорошие и значимые результаты с точки зрения симуляции пользовательского взаимодействия с приложением, оно имеет и ряд своих недостатков:

1. Хрупкость — для определения веб-элементов для взаимодействия тесты используют html-локаторы, поэтому как только меняется уникальный ID какого-либо элемента интерфейса, тесты перестают работать, а это влечёт за собой значительные расходы на поддержку.
2. Ограниченное тестирование — GUI может не позволить тестировщику полностью проверить функциональность,  поскольку он не всегда содержит все детали веб-ответа, необходимые для верификации.
3. Низкая скорость — поскольку тесты проводятся через GUI, время загрузки страницы существенно увеличивает общее время тестирования, и обратная связь разработчикам поступает значительно позже.
4. Наименьшая окупаемость — из-за всех проблем, перечисленных выше, GUI-тесты становятся наименее целесообразными с финансовой точки зрения.

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

За перевод выражаем благодарность международной IT-компании Noveo