Тестирование SAP: виды, фазы и ответственные

Тестирование SAP доказывает, что настроенная система SAP правильно выполняет ваши бизнес-процессы, на ваших данных и на ваших объёмах, до go-live и после каждого последующего изменения. В программе S/4HANA оно включает шесть видов тестов: модульное, системное интеграционное (SIT), приёмочное (UAT), регрессионное, нагрузочное тестирование и репетицию перехода (cutover).

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

Эта страница даёт общую картину. У каждого вида тестирования есть отдельное руководство, ссылки на них в разделах ниже.

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

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

Тестирование не заканчивается и на go-live. Изменения в рамках сопровождения, релизы SAP и новые тиражирования меняют систему, поэтому та же дисциплина продолжается и в фазе Run.

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

Вид тестирования	Что он доказывает	Место в SAP Activate	Кто отвечает
Модульное тестирование	Каждая настройка, программа или расширение работает сама по себе	Realize, внутри каждого спринта разработки	Функциональные и технические консультанты
Системное интеграционное тестирование (SIT)	Полные процессы проходят через модули и интерфейсы на реалистичных данных	Realize, циклами после стабилизации разработки	Руководитель тестирования программы вместе с владельцами процессов
Приёмочное тестирование (UAT)	Бизнес может выполнять в системе свои реальные сценарии	Конец Realize, до Deploy	Бизнес
Регрессионное тестирование	То, что работало раньше, работает и после изменения	С Realize и далее, затем каждый релиз в Run	Руководитель тестирования, с автоматизацией там, где её оправдывает объём
Нагрузочное тестирование	Система выдерживает много пользователей и продуктивные объёмы одновременно	Realize, завершается до go-live	Руководитель по производительности на уровне программы вместе с Basis
Репетиция перехода	Последовательность go-live, загрузки данных и тайминги работают целиком	Deploy	Менеджер перехода

Тестирование SAP по фазам SAP Activate

1. 01

   Prepare

   Подготовьте инструмент тестирования, команду и тестовый ландшафт.

2. 02

   Explore

   Пишите стратегию тестирования, пока принимаются решения fit-to-standard, чтобы требования можно было проверить.

3. 03

   Realize

   Модульные тесты в спринтах, затем циклы SIT, нагрузочное тестирование и UAT, когда разработка стабилизировалась.

4. 04

   Deploy

   Репетиции перехода по согласованному чек-листу, затем решение о go-live.

5. 05

   Run

   Регрессионное тестирование для каждого изменения сопровождения, обновления и релиза.

Модульное тестирование

Модульное тестирование проводят те, кто создал объект. Функциональный консультант проверяет условие ценообразования, разработчик проверяет расширение или сопоставление полей интерфейса.

Оно необходимо, но недостаточно. Чистый модульный тест ничего не говорит о том, что произойдёт, когда этот объект встретится с остальным процессом.

Системное интеграционное тестирование

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

Я планирую SIT циклами, а не одним прогоном. Дефекты из первого цикла исправляют, а следующий цикл доказывает, что исправления ничего не сломали. Как сочетаются циклы, критерии входа и критерии выхода, я описал в своём руководстве по стратегии тестирования S/4HANA.

Приёмочное тестирование

UAT означает, что бизнес подтверждает: система поддерживает тот способ работы, который будет после go-live. Оно принадлежит бизнесу, а не системному интегратору, потому что принять систему может только бизнес.

На UAT нужно минимум от 6 до 8 недель. Сожмите его под опоздавшую разработку, и вы получите подпись на бумаге и проблемы в продуктивной системе. Сценарии, роли и подписание описаны в моём руководстве по приёмочному тестированию SAP.

Регрессионное тестирование

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

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

Нагрузочное тестирование

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

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

Репетиция перехода

Репетиция перехода проверяет сам go-live: последовательность технических шагов, загрузки данных, сверки и подписания, с таймингами. При конверсии brownfield я планирую три пробные конверсии до перехода.

Критерий go-live, на котором я настаиваю: подробный чек-лист перехода, согласованный заранее. Если чек-лист пишут в выходные перехода, репетиции на самом деле не были репетициями.

По моему опыту, тестирование занимает около 35 процентов трудозатрат программы. Эта цифра удивляет спонсоров, которые считают тестирование коротким промежутком между разработкой и go-live.

Усилия распределены между многими людьми. Консультанты проводят модульные тесты, команда тестирования готовит и проводит SIT, бизнес-пользователи проводят UAT, а команды Basis и интеграции поддерживают нагрузочное тестирование и репетиции перехода.

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

Самая частая ошибка тестирования, которую я вижу: просто недостаточно тестирования в SIT и UAT. Циклы урезают, когда разработка опаздывает, а дата go-live остаётся на месте. В 21 программе SAP, которые я вёл или спасал, главной ошибкой по-прежнему остаётся плохое планирование в начале, и тестирование обычно первым это показывает.

Тесты хороши ровно настолько, насколько хороши данные, на которых они идут. Моё правило: маскированные данные, но на уровне продуктивной системы. Продуктивные объёмы и реалистичные записи, с замаскированными персональными и чувствительными полями.

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

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

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

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

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

Инструменты делятся на три группы: управление тестированием, функциональная автоматизация и нагрузочное тестирование. Команды, которые я вёл или с которыми работал, использовали Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath и LoadRunner.

Вот что делает каждая группа и какие продукты в неё входят:

Группа инструментов	Что она делает	Продукты, которые обычно используют команды
Управление тестированием	Планы тестирования, тестовые сценарии, записи о прогонах, дефекты и трассируемость к требованиям	SAP Cloud ALM, SAP Solution Manager, Panaya
Функциональная автоматизация тестирования	Выполняет скриптовые или модельные тесты в приложениях SAP и не SAP	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Нагрузочное тестирование	Имитирует много одновременных пользователей и продуктивные объёмы	OpenText LoadRunner, теперь продаётся как OpenText Professional Performance Engineering

Несколько фактов о продуктах стоит знать до выбора.

1. SAP Cloud ALM входит в поставку для клиентов с SAP Enterprise Support или с облачной подпиской, которая включает Enterprise Support, cloud editions (SAP Support). Его управление тестированием охватывает подготовку тестов, планы тестирования и выполнение, включая ручные тестовые сценарии для UAT (SAP Learning).
2. SAP Solution Manager 7.2: основная поддержка заканчивается в конце 2027 года, с возможной расширенной поддержкой до конца 2030 года для части функций, включая набор для тестирования (SAP Support).
3. SAP Test Automation by Tricentis это продукт автоматизации, который SAP перепродаёт. Он интегрирован с SAP Cloud ALM и создан для систем SAP и сторонних систем (SAP).
4. LoadRunner это продукт OpenText. LoadRunner Professional теперь называется OpenText Professional Performance Engineering и поддерживает протоколы SAP GUI и SAP Web (OpenText).

Если вы начинаете новую программу, планируйте управление тестированием в Cloud ALM, а не в Solution Manager. Более подробное сравнение есть в моём руководстве по инструментам тестирования SAP.

В SAP Cloud ERP public edition (S/4HANA Cloud Public Edition) SAP обновляет каждого клиента по собственному графику. SAP Learning описывает обновления раз в шесть месяцев, сейчас в феврале и августе, а между ними новые функции выходят ежемесячно (SAP Learning).

Дату обновления выбираете не вы, поэтому регрессионное тестирование становится постоянным пунктом календаря, а не проектом. Это самый сильный довод за раннюю автоматизацию регрессии в системе public cloud.

В private cloud и on-premise сроки обновлений контролируете вы. Но каждому обновлению всё равно нужен цикл регрессии по размеру процессов, которые затрагивает изменение.

Прежде всего внесите тестирование в план как отдельное направление со своим ответственным и бюджетом, примерно на треть усилий. Затем назовите владельца UAT со стороны бизнеса и забронируйте для него от 6 до 8 недель в календаре сейчас, пока разработка его не сжала.

Свяжите результаты тестов с решениями go/no-go через измеримые критерии выхода. Как это сделать, показано в моём руководстве по quality gates в SAP. Если ваша программа уже в беде, мои заметки о восстановлении программ SAP описывают, что исправлять в первую очередь.

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

Что такое тестирование SAP?

Тестирование SAP доказывает, что настроенная система SAP правильно выполняет ваши бизнес-процессы, на ваших данных и на ваших объёмах. В программе S/4HANA оно включает модульное тестирование, системное интеграционное тестирование, приёмочное тестирование, регрессионное тестирование, нагрузочное тестирование и репетицию перехода. После go-live оно продолжается для каждого изменения сопровождения и каждого релиза.

Какие бывают виды тестирования SAP?

Шесть основных видов: модульное тестирование, системное интеграционное тестирование (SIT), приёмочное тестирование (UAT), регрессионное тестирование, нагрузочное тестирование и репетиция перехода. Модульные тесты проверяют отдельные объекты, SIT проверяет полные процессы через модули и интерфейсы, а UAT означает, что бизнес принимает систему. Регрессия, нагрузочное тестирование и репетиция перехода защищают от последствий изменений, нагрузки и проблем самого go-live.

Сколько длится приёмочное тестирование SAP?

Планируйте на UAT минимум от 6 до 8 недель. Владельцем должен быть бизнес: он выполняет свои реальные сценарии и подписывает результат. Недостаточное тестирование в UAT и SIT остаётся самой частой ошибкой тестирования, которую я вижу.

Какую долю проекта SAP занимает тестирование?

По моему опыту, тестирование занимает около 35 процентов трудозатрат программы. Сюда входят подготовка и проведение модульных тестов, циклы SIT, UAT, регрессия, нагрузочное тестирование и репетиции перехода. Параллельно идёт миграция данных, и каждому циклу тестов нужны данные, похожие на продуктивные.

Нужно ли автоматизировать тестирование SAP?

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

Какой инструмент используется для тестирования SAP?

Большинство программ сочетают инструмент управления тестированием с инструментом автоматизации и инструментом нагрузочного тестирования. Обычный выбор: SAP Cloud ALM или Solution Manager для управления тестированием, Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft или UiPath для автоматизации и OpenText LoadRunner для нагрузки. Новым программам стоит планировать работу в Cloud ALM, поскольку основная поддержка Solution Manager заканчивается в 2027 году.