22.11.21 15:59

Новости

Автор:

Администратор

Как автоматизировать QA-тестирование SaaS и low-code приложений

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

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


Автор: Исаак Саколик, редактор InfoWorld

 

Инженеры по автоматизации контроля качества тестируют приложения, разработанные собственными силами, от устаревших монолитов до облачных приложений, использующих микросервисы. Типичное критически важное приложение требует сочетания модульного тестирования на уровне кода, анализа кода, тестов API, автоматизированного тестирования пользовательского интерфейса, тестирования безопасности и тестирования производительности. Лучшая практика DevOps – автоматизировать выполнение этих тестов, а затем выбрать оптимальное подмножество для непрерывного тестирования внутри конвейеров CI/CD (непрерывная интеграция и непрерывная доставка).

 

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

 

Этот вопрос напоминает мне о том, чему нас учил мой школьный учитель математики. Она говорила: «Если вы предполагаете, то вы делаете из нас с вами задницу». В случаях SaaS, low-code и no-codeпредположение, что приложение функционирует должным образом без плана тестирования, может привести ко многим проблемам:

 

* Раздраженные заинтересованные стороны, разочарованные неожиданными результатами

* Бреши в системе безопасности, которые открывают доступ к данным для общественности или сотрудников, которые не должны иметь доступа

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

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

* Разочарованные ИТ-команды, призванные доработать приложения или разработать обходные пути

 

Итак, что следует проверить? Как можно протестировать эти приложения без доступа к базовому исходному коду? Где следует расставлять приоритеты в тестировании, особенно учитывая, что во многих организациях DevOps не хватает инженеров по контролю качества? 

 

Я поговорил с экспертами, чтобы они помогли мне разобраться в ответах на некоторые вопросы.

 

Начните с определения и внедрения гибкого приемочного тестирования

 

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

 

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

 

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

 

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

 

Low-code и no-code требуют тестирования бизнес-логики

 

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

 

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

 

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

 

Эндрю Кларк, технический директор Monitaur, предлагает сосредоточить автоматическое тестирование на рабочем процессе и на том, как приложение поддерживает бизнес-процесс. «Хороший способ протестировать SaaS и приложения с низким уровнем кода – выполнить базовую проверку ввода и вывода. Вам нужно будет создать матрицу ключевых событий/действий, которые мы ожидаем от системы, и настроить тестовые примеры для проверки того, что система работает должным образом», - говорит он.

 

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

 

Используйте платформы тестирования с низким уровнем кода и машинное обучение

 

Хотя разработка с низким уровнем кода и без кода часто ускоряет процесс и позволяет упростить усовершенствования, команды DevOps все равно должны выполнять тестирование и проверку конфигурации.

Хорошей новостью является то, что инженеры QA могут разрабатывать тесты с помощью платформ тестирования с низким уровнем кода. «При тестировании с низким уровнем кода вы используете передовые технологии искусственного интеллекта и машинного обучения, поэтому процесс написания и поддержки тестовых сценариев выполняется с помощью машин. Это может значительно сократить время и затраты, а также уменьшить вашу зависимость от инженеров по автоматизации тестирования, поскольку обычные программисты и даже не программисты теперь могут создавать сценарии автоматизации тестирования. В конечном счете, тестировщики теперь могут сосредоточиться на бизнес-потребностях программного обеспечения и гарантировать сохранение намерений пользователя», - говорит  Рам Шанмугам, генеральный директор Autonomiq, компании Sauce Labs.

 

Как low-code платформы и SaaS автоматизируют тестирование

 

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

Общее качество также зависит от того, как платформа с низким уровнем кода или поставщик SaaS тестируют свои технологии и управляют базовыми облачными сервисами и инфраструктурой. Большинство поставщиков платформ предоставляют свои сертификаты безопасности, уровни обслуживания и учетные данные соответствия, такие как ISO, SOC, GDPR, PCI и FedRAMP. Ведущие поставщики также делятся своими расписаниями выпуска, примечаниями к выпуску, известными дефектами, записями об уровне обслуживания и доступом к веб-страницам для проверки статуса безотказной работы. Но не так много поставщиков предоставляют подробную информацию о своей архитектуре, стандартах разработки и методах тестирования.

 

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

 

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

 

Итог: если вы не тестируете приложение с низким уровнем кода или SaaS, то, возможно, вы делаете слишком много предположений.

 

Ссылка на источник