Использование RPA для тестирования программного обеспечения:«технический хак»?

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

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

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

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

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

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

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

Чтобы получить краткий обзор различий между инструментами RPA и инструментами автоматизации тестирования, сравните следующие определения от Gartner:

Инструменты RPA «выполняют операторы «если, то, иначе» со структурированными данными, обычно используя комбинацию взаимодействий пользовательского интерфейса (UI) или подключаясь к API для управления клиентскими серверами, мейнфреймами или HTML-кодом. Инструмент RPA работает, сопоставляя процесс на языке инструмента RPA с программным «роботом», которому следует следовать, при этом время выполнения выделяется для выполнения сценария с помощью панели управления».

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

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

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

Что эти различия означают для тестирования программного обеспечения?

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

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

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

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

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

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

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

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

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

Уэйн Ариола, автор книги «Непрерывное тестирование для ИТ-руководителей» и известный основной докладчик в сфере DevOps и разработки приложений.