Использование RPA для тестирования ПО: стратегический подход

Неэффективная автоматизация тестирования ПО славится задержками релизов, потребляя невероятные объёмы ресурсов.

Время от времени моя лента новостей содержит статью, предлагающую «Топ 10 жизненных хаков». Это советы и трюки о том, как использовать обычные бытовые продукты неожиданными способами для улучшения вашей жизни — «…и совет №7 взорвёт ваш мозг!!!»

Признаюсь, я попадал на этот кликбейт. Честно говоря, есть моменты, когда я приятно удивлён. Например, кто знал, что можно разрезать раздражающие пластиковые блистеры открывкой для консервов, или использовать рулон туалетной бумаги, чтобы держать упаковочную бумагу от разворачивания?

Я попробовал два «хака» выше и угадайте что? Они «вроде» работали… некоторое время. Открывка для консервов прорезала шов, где пластик был сплавлен, но не смогла прорезать длину упаковки. Рулон туалетной бумаги держал упаковочную бумагу некоторое время, но в конечном счёте картон ослаб и упаковочная бумага развернулась. Неудивительно, ножницы для пластиковых блистеров и маленький кусок скотча для упаковочной бумаги работали намного, намного лучше.

В очень похожей вене, многие организации сейчас рассматривают использование RPA для автоматизации тестирования ПО: «тех-хак» для тестирования ПО, так сказать. Однако, так же как рулон туалетной бумаги не представил устойчивое решение для удержания упаковочной бумаги от разворачивания, RPA — не устойчивое решение для автоматизации тестирования ПО… и модификации, требуемые для сделать RPA-инструмент устойчивым для задачи автоматизации тестирования ПО, были бы, ну, хаком.

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

Однако важно признать, что успешная — и устойчивая — автоматизация тестирования требует гораздо больше, чем способность кликать через пути приложения. Чтобы подняться выше зловещего отраслевого среднего уровня автоматизации тестирования <20%, команды также должны уметь конструировать и стабилизировать эффективный автоматизированный тестовый набор. RPA-инструменты обычно не спроектированы для этого. В результате вы упретесь в дорожные блоки автоматизации тестирования, такие как задержки ожидания требуемых тестовых данных и тестовых сред, неконсистентные результаты, подрывающие доверие к инициативе автоматизации, и «раздутые» тестовые наборы, потребляющие значительные ресурсы, но не доставляющие чётких, действенных обратных связей.

Для быстрого обзора разницы в области между RPA-инструментами и инструментами автоматизации тестирования, сравните следующие определения от Gartner:

RPA-инструменты «выполняют операторы "if, then, else" на структурированных данных, обычно используя комбинацию пользовательских интерфейсных (UI) взаимодействий, или подключая к API для привода клиентских серверов, мейнфреймов или HTML-кода. RPA-инструмент работает отображением процесса в языке RPA-инструмента для софт-робота, чтобы следовать, с runtime, выделенным для выполнения скрипта панелью управления».

Инструменты автоматизации тестирования «позволяют организации проектировать, разрабатывать, поддерживать, управлять, выполнять и анализировать автоматизированные функциональные тесты… Они обеспечивают широту и глубину продуктов и фич по жизненному циклу разработки ПО (SDLC). Это включает дизайн и разработку тестов; поддержку и повторное использование тест-кейсов; и управление тестами, управление тестовыми данными, автоматизированное тестирование и интеграцию, с сильным фокусом на поддержку непрерывного тестирования».

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

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

Что эти различия означают для тестирования ПО?

• Автоматизация должна выполняться в тестовой среде, которая обычно неполная, эволюционирующая и ограниченная
• Управление стейтфул, secure, compliant тестовыми данными становится огромным вызовом
• Эффективный дизайн тест-кейсов — необходим для успеха
• Сбои должны давать инсайт по бизнес-риску

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

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

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

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

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

Теперь представьте, что ваша компания решила добавить $10 плату за изменение для всех предоплаченных броней. Могли бы вы легко вписать это новое требование в существующие автоматизированные тесты — или пришлось бы существенно переработать каждый тест для приспособления к этому минорному изменению?

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

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

Уэйн Ариола — автор Continuous Testing for IT leaders и известный ключевой спикер в DevOps и App Dev пространстве.