Автоматизация тестирования SAP: с чего начать и когда она окупается

Автоматизация тестирования SAP означает, что тесты SAP, которые вы запускаете снова и снова (в основном регрессионные), выполняет инструмент, а не люди. Она окупается, когда много тестовых сценариев нужно тщательно и многократно проверять; если их меньше, ручного тестирования достаточно.

Это правило, которым я пользуюсь в программах S/4HANA. По моему опыту, тестирование занимает около 35 процентов трудозатрат программы, поэтому вопрос никогда не стоит так, тестировать или нет. Вопрос в том, какую часть этой работы должен взять на себя инструмент.

О том, как автоматизация сочетается с модульным, интеграционным, приёмочным и нагрузочным тестированием, лучше начать с моего обзора тестирования SAP. В этой статье: с чего начать, когда автоматизация окупается, какие бывают подходы и что дают SAP Cloud ALM, Solution Manager и Tricentis.

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

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

В программе SAP повторения возникают в предсказуемых местах:

1. Транспорты. Каждое изменение, перенесённое в систему контроля качества, может сломать то, что работало вчера.
2. Релизы SAP и пакеты поддержки. Обновления on-premise и в private cloud, а также плановые обновления SAP S/4HANA Cloud Public Edition.
3. Повторные циклы тестов. Системное интеграционное тестирование (SIT) прогоняет одни и те же сквозные процессы больше чем в одном цикле.
4. Волны тиражирования. Глобальный шаблон тестируют заново для каждой страны или балансовой единицы.
5. Проверки с большим объёмом данных. Множество комбинаций ценообразования, налогов или определения счетов, где меняются только данные.

Если ничего из этого к вам не относится, инструмент обойдётся дороже, чем сэкономит.

В таблице видно, как я бы разделил работу по видам тестов.

Вид теста	Автоматизировать?	Почему
Регрессия основных процессов, таких как «от заказа до оплаты», «от закупки до платежа» и «от учёта до отчётности»	Да, в первую очередь	Запускается после каждого транспорта и каждого релиза
Циклы SIT	Частично	Автоматизируйте стабильные процессы; новые и меняющиеся сценарии оставьте ручными
Приёмочное тестирование (UAT)	Редко	Бизнес-пользователи решают, работает ли процесс для них, а скрипт этого не может
Исследовательские и негативные тесты	Нет	Ценность в человеке, который ищет то, чего никто не прописал в сценарии
Производительность и нагрузка	Да, с инструментом нагрузочного тестирования	Много одновременных пользователей вручную не создать
Разовые проверки миграции данных	Обычно нет	Отчёты сверки справляются лучше, если только одна и та же загрузка не повторяется в пробных прогонах

Decide

Стоит ли автоматизировать этот тест SAP?

Много тестовых сценариев, повторяются после каждого изменения или релиза

→Автоматизировать

Мало тестовых сценариев или запуск один-два раза

→Тестировать вручную

Проект процесса ещё меняется

→Дождаться стабильности, затем решить

Автоматизация, которая разочаровывает, обычно начиналась слишком широко: всё сразу, во время проектирования, и без владельца результата. Вот порядок, которому я бы следовал:

1. Выберите процессы, поломку которых бизнес не может себе позволить. Закрытие месяца, фактурирование, платежи и всё, что тиражируется на многие площадки, идут раньше отчётов из разряда «хорошо бы иметь».
2. Сначала прогоните тесты вручную. Инструмент автоматизирует тест, который уже работает вручную. Он не спроектирует тест за вас.
3. Дождитесь стабильного проекта решения. Автоматизация во время Explore или в начале Realize означает переделку тестов при каждом изменении проектного решения.
4. Соберите небольшой регрессионный пакет. Покройте критичные процессы от начала до конца, затем запускайте пакет при каждом транспорте в систему контроля качества.
5. Назначьте ответственного за сопровождение. Кто-то должен чинить тесты, когда меняются экраны, роли или данные, иначе пакет деградирует за несколько релизов.
6. Расширяйте покрытие только там, где это оправдывают повторения. Добавляйте тест, когда он будет запускаться часто, а не потому, что этого требует целевой показатель покрытия.

Отделите проект от текущей деятельности

Во время программы я держу два отдельных ландшафта: один для проекта и один для текущей деятельности (BAU). Тогда изменения сопровождения и изменения проекта тестируются раздельно.

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

В своих программах я использовал сам или мои команды использовали Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath и LoadRunner. Рейтинга в этой статье нет. Правильный выбор зависит от вашего ландшафта, договора поддержки и от того, кто будет сопровождать тесты.

Начните с того, что SAP уже предоставляет, потому что часть этого, возможно, уже оплачена.

SAP Cloud ALM

SAP Cloud ALM это уровень управления тестированием. Он планирует, запускает и трассирует ручные и автоматические тесты относительно ваших процессов и требований. Клиенты с SAP Enterprise Support, Product Support for Large Enterprises или подходящей облачной подпиской могут развернуть один тенант (права использования SAP).

Сам он автотесты не выполняет. SAP указывает, что у Cloud ALM нет собственного движка автоматизации и что её платформы ALM остаются открытыми для сторонней автоматизации тестирования (SAP Support, автоматизация тестирования).

Руководство SAP по настройке описывает встроенные интеграции и публичный Test Automation API для других поставщиков (SAP Help Portal). Panaya и UiPath документируют интеграции с Cloud ALM для автоматических тестовых сценариев. Worksoft указывает Cloud ALM и Solution Manager среди своих интеграций, а OpenText предлагает интеграцию с Cloud ALM для своего облачного продукта нагрузочного тестирования.

Tricentis Test Automation for SAP и SAP Test Automation by Tricentis

Проверьте свои права до любой покупки. SAP предоставляет срочную лицензию на Tricentis Test Automation for SAP, интегрированный с Cloud ALM, вместе с SAP Enterprise Support, Enterprise Support cloud editions и Product Support for Large Enterprises. Сейчас она действует до 31 декабря 2028 года (права использования SAP).

Ограничения жёсткие: 5 именованных пользователей, 500 прогонов тестов в календарный месяц, 5 агентов выполнения под управлением клиента и 12 месяцев хранения результатов. Её нельзя использовать для автоматизации продуктивных бизнес-процессов. Рассматривайте её как способ начать, а не как инструмент масштаба программы.

SAP Test Automation by Tricentis это следующая, платная ступень. Это продукт по модели software-as-a-service, который SAP продаёт и поддерживает как solution extension, для приложений SAP и сторонних приложений. Он расширяет возможности Tricentis, входящие в Cloud ALM, когда в рамках права становится тесно.

SAP Solution Manager

Основная поддержка Solution Manager 7.2 действует до конца 2027 года. Клиенты, которые выбирают расширенную поддержку SAP Business Suite 7, получают расширенную поддержку Solution Manager до конца 2030 года. Она охватывает ограниченный набор областей, включая набор для тестирования (SAP Support).

Его собственная автоматизация, Component-Based Test Automation (CBTA), не будет распространена на облачные продукты SAP. Лицензия Tricentis для интеграции с Solution Manager сейчас действует до 31 декабря 2027 года. Если у вас уже работает Solution Manager, оставьте его, пока ландшафт не переедет, но не стройте вокруг него новую автоматизацию.

SAP S/4HANA Cloud Public Edition

В Public Edition есть собственный Test Automation Tool. SAP рекомендует, чтобы партнёры создавали или обновляли тестовые автоматы по мере настройки каждого процесса, чтобы их можно было запускать в тестовой системе во время обновлений (SAP Learning).

С вашего согласия SAP проводит тесты после обновления на стандартных, неизменённых процессах. После go-live регрессионное тестирование всего, что вы доработали, на вас, с вашими собственными автоматами.

Таблица сводит названные выше инструменты по задачам, а не по предпочтениям.

Инструмент	Основная задача	Где он к месту
SAP Cloud ALM	Управление и оркестрация тестирования	Новые программы; связывает ручные и автоматические тесты с процессами
SAP Solution Manager	Управление тестированием, on-premise	Ландшафты, где он уже работает; основная поддержка заканчивается в 2027 году
Tricentis Tosca и SAP Test Automation by Tricentis	Модельная автоматизация	Приложения SAP и не SAP; перепродаётся и поддерживается SAP
Worksoft	Автоматизация процессов без кода	Интегрируется с Cloud ALM и Solution Manager
Panaya	Управление тестированием и автоматизация без кода	Интеграция с Cloud ALM для автотестов
UiPath	Платформа автоматизации с Test Manager	Интеграция с Cloud ALM для автоматических тестовых сценариев
OpenText LoadRunner	Тестирование производительности и нагрузки	Тесты параллельной работы и объёмов до go-live

Более подробное сравнение, включая Xray for Jira, есть в моём руководстве по инструментам тестирования SAP. О нагрузочном тестировании читайте тестирование производительности SAP для ИТ-руководителей.

Инструмент важен меньше, чем то, как построены тесты и кто их сопровождает. Большая часть автоматизации SAP относится к одному из этих подходов:

1. Модельный. Экраны и API сканируются в повторно используемые модули, из которых затем собираются тестовые сценарии. Функциональные консультанты могут создавать и читать их без кода.
2. Запись процессов без кода. Шаги бизнес-процесса записываются и превращаются в повторно используемые тесты. Подходит командам, где ключевые пользователи помогают собирать регрессионный пакет.
3. На основе кода. Инженеры по тестированию пишут тесты в программном фреймворке. Подходит для приложений Fiori и API, которыми владеет команда разработки, и требует разработчиков для сопровождения.
4. Платформы роботизированной автоматизации процессов с модулями тестирования. Одна платформа для автоматизации бизнеса и автоматизации тестов, полезна, если она у вас уже работает.
5. Автоматы от SAP. В Public Edition это тестовые автоматы, поставляемые с Test Automation Tool и адаптированные к вашим данным и изменениям.

Какой бы подход вы ни выбрали, три проектных решения определяют, выживут ли тесты:

1. Тестируйте на уровне API, где это возможно. Тесты API ломаются реже, чем тесты, которые прокликивают экраны.
2. Делайте тестовые данные сбрасываемыми. Тест, который зависит от данных, израсходованных прошлым прогоном, падает не по той причине.
3. Стройте из общих модулей. Когда меняется экран, вы чините один модуль, а не каждый тест, который его затрагивает.

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

Привяжите его к управлению изменениями. Ни один транспорт не уходит в продуктив, пока регрессионный пакет не отработал и его результаты не записаны в инструмент управления тестированием. В моей статье о quality gates в SAP показано, как сделать результаты тестов частью решения go или no-go.

Учитывайте и ритм релизов SAP. Обновления Public Edition приходят по графику SAP, а не по вашему, а системам private cloud и on-premise всё равно нужны пакеты поддержки и обновления. Каждое из них означает прогон регрессии, и именно здесь автоматизация окупает свою стоимость.

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

Автоматизация тоже должна жить внутри плана тестирования. Сначала циклы, критерии входа и выхода и роли; их описывает моя стратегия тестирования S/4HANA.

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

Если сценариев много и прогоны повторяются, у вас есть обоснование для автоматизации. Затем проверьте, что уже включено в ваш договор поддержки SAP, прежде чем кто-нибудь покажет вам демо.

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

Что такое автоматизация тестирования SAP?

Это использование инструмента для выполнения тестов SAP, которые иначе прогоняли бы вручную, в основном регрессионных тестов после изменений и обновлений. Инструмент управления тестированием, например SAP Cloud ALM, планирует и фиксирует тесты, а инструмент автоматизации их запускает.

Когда стоит автоматизировать тестирование SAP?

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

Выполняет ли SAP Cloud ALM автоматизацию тестирования?

Он управляет автотестами и запускает их, но собственного движка автоматизации не имеет. Он интегрируется с Tricentis Test Automation for SAP, с Test Automation Tool в S/4HANA Cloud Public Edition и с другими поставщиками через публичный Test Automation API.

Что такое SAP Test Automation by Tricentis?

Это продукт автоматизации тестирования по модели software-as-a-service, который SAP продаёт и поддерживает как solution extension, для приложений SAP и сторонних приложений. Он расширяет базовую лицензию Tricentis Test Automation for SAP, входящую в SAP Enterprise Support. Эта лицензия ограничена 5 именованными пользователями и 500 прогонами тестов в месяц.

Можно ли автоматизировать приёмочное тестирование SAP?

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

Стоит ли по-прежнему использовать SAP Solution Manager для автоматизации тестирования?

Только если он уже работает в вашем ландшафте. Основная поддержка Solution Manager 7.2 заканчивается в 2027 году, а его автоматизация CBTA не будет распространена на облачные продукты SAP. Планируйте новую автоматизацию вокруг Cloud ALM.