Автоматизация тестирования в Agile-проектах
Автоматизированное тестирование — важнейший и даже ключевой процесс разработки ПО, особенно когда мы говорим об использовании Agile-методологии. Дело в том, что когда мы переходим к постоянному развёртыванию, автоматизация в тестировании приобретает ещё большую важность, в том числе и благодаря возможности быстрее информировать разработчиков о текущем состоянии разрабатываемого продукта. Дабы обеспечить постоянную обратную связь, автотесты надо выполнять быстро и постоянно, а результаты должны быть достоверны и надёжны.
Чтобы все вышеописанные условия обеспечивались, часть проверок надо проводить непосредственно при разработке новых функциональных возможностей, то есть разработка должна быть неразрывно связана с тестированием и обеспечением качества. Это значит, что не обойтись без «инвертирования пирамиды автоматизации тестирования» и отказа от GUI-тестов, занимающих много времени. При этом отказ должен производиться в пользу низкоуровневого тестирования, допустим, API, где автотесты можно запускать сразу после unit-тестов, что обеспечит нам базовый уровень надёжности.
Какова стратегия автоматизации тестирования?
Качество важнее количества. В большинстве ситуаций будет лучше, если в релиз выйдет одна фича, но надёжная, как скала, чем несколько сырых и полуготовых функциональностей. Минимальный критерий для релиза — отсутствие регрессионных дефектов (новые возможности не нарушают работу существующего функционала).
Как мы уже говорили, важно быстро проинформировать разработчиков о состоянии приложения. Это значит, что нужно найти эффективный механизм, дающий быструю обратную связь. Здесь можно посоветовать повысить число unit-тестов, тестов API и интеграционных тестов. Эти перечисленные тесты относятся к низкоуровневым и помогают сформировать сеть безопасности, которая, в свою очередь, позволит убедиться, что всё работает, как надо. При этом, что касается Unit-тестов, то они являются ещё и основой для автоматизации тестирования на более высоких уровнях.
Кроме того, улучшить работу мы можем, запуская регрессионные тесты чаще и параллельно с непрерывной поставкой (поговорим об этом ниже). Главное, что следует запомнить, заключается в том, что автотестирование должно быть не изолированной задачей, а непрерывным процессом, который неотъемлемо вписан в жизненный цикл программного обеспечения.
Регрессионное тестирование
Автоматические регрессионные тесты являются основой стратегии автоматизации тестирования.
Smoke-пакет регрессионных тестов необходим, чтобы проверить, что приложение в принципе загружается и запускается. Также в него входит ряд ключевых тест-кейсов, позволяющих нам удостовериться, что приложение всё ещё работает.
Цель данного пакета тестов — определить самые очевидные проблемы: приложение не загружается/не запускается основной поток взаимодействия приложения с пользователем и т. п. Именно поэтому Smoke-тесты не должны продолжаться более 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 — наиболее популярный инструмент для автоматизированного тестирования в браузерах.
Полные сценарные тесты
Автоматизированные GUI-тесты, запускаемые для всей системы целиком, применяются как типичные пути пользователей либо полные сценарии взаимодействия. Этот тип тестов имеет ряд проблем (о них ниже), поэтому желательно сократить их до минимума. Полные сценарии обычно включаются в ночные регрессионные пакеты.
Инвертирование пирамиды автоматизации тестирования
Итак, в рамках стратегии автоматизации тестирования надо минимизировать число автоматизированных тестов на GUI-уровне. Дело в том, что несмотря на результативность в плане имитации пользовательского взаимодействия с приложением, есть и ряд минусов: 1. Хрупкость — чтобы определить веб-элементы используются html-локаторы, а значит, когда меняется уникальный ID элемента, тесты перестают работать. Соответственно, мы получаем дополнительные расходы на поддержку. 2. Ограниченное тестирование — GUI не всегда содержит все детали web-ответа, нужные для верификации, поэтому у тестировщика не всегда есть возможность проверить функциональность в полной мере. 3. Низкая скорость — раз тесты проводятся через GUI, то время загрузки страницы значительно повышает общее время тестирования, поэтому обратная связь разработчикам поступает позже. 4. Наименьшая окупаемость — из-за вышеописанных проблем целесообразность проведения GUI-тестов уменьшается (с финансовой точки зрения).
Источник — Test Automation Strategy For Agile Projects.