Регрессионное тестирование SAP: обновления, релизы и объём

Регрессионное тестирование SAP доказывает, что изменение, пакет поддержки или новый релиз не сломали бизнес-процессы, которые уже работали. Объём определяют через анализ влияния, самые рискованные процессы прогоняют первыми, а повторяют его при каждом изменении системы, а не один раз перед go-live.

Поводы для него: транспорты, обновления и облачные релизы. В SAP Cloud ERP public edition даты обновлений устанавливает SAP, поэтому ваш регрессионный набор должен быть готов до прихода релиза.

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

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

Регрессионное тестирование повторно прогоняет тесты на процессах, которые не должны были измениться. Функциональное тестирование спрашивает, работает ли новое, а регрессия спрашивает, работает ли по-прежнему всё остальное.

Оно нужно на протяжении всей жизни системы, а не только во время программы:

1. Транспорты. Каждое изменение, перенесённое из разработки в систему качества, несёт регрессионный риск для процессов, которые оно затрагивает.
2. Пакеты поддержки и feature packs. Исправления и новые функции SAP меняют стандартный код под вашими настройками.
3. Обновления релиза. Переход на новый релиз или облачный релиз, который вы не планировали, меняет гораздо больше за один раз.
4. Конверсии. Конверсия ECC в S/4HANA сохраняет ваши настройки и собственный код, поэтому всё сохранённое нужно протестировать заново. Где это стоит в плане, объясняет моё руководство по миграции ECC в S/4HANA.
5. Интеграции и расширения. Изменение в связанной системе или в расширении side-by-side может сломать сторону SAP без единого транспорта SAP.

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

On-premise вы сами выбираете, когда обновляться. В облачных редакциях большую часть графика задаёт SAP, и регрессионное тестирование становится регулярным обязательством в календаре.

Public edition: два обновления в год

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

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

Курс SAP по Cloud ALM о тестировании после обновления и регрессионном тестировании рекомендует создать план регрессионного тестирования в Cloud ALM и использовать его повторно для каждого релиза. В public edition также есть бесплатный инструмент автоматизации тестирования с готовыми тестовыми скриптами, так что у стандартных процессов есть отправная точка.

Private edition: двухлетний цикл релизов

SAP Cloud ERP Private, частная редакция, которая продаётся через RISE with SAP, следует циклу релизов on-premise. По данным SAP Learning, новый базовый релиз выходит раз в два года, feature pack stacks следуют каждые шесть месяцев, а у каждого релиза семь лет основной поддержки.

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

Для бюджета это разделение важно. Само обновление может входить в подписку, а регрессионное тестирование вокруг него нет.

В этой таблице поводы для регрессии стоят рядом:

Изменение	Как часто	Кто устанавливает дату	Что должен охватить прогон регрессии
Транспорт в систему качества	Ежедневно или еженедельно	Ваша команда	Процессы, которые затрагивают изменённые объекты
Обновление public edition	Дважды в год, в феврале и августе	SAP	Все процессы в объёме, собственная логика первой, в окне до продуктивной системы
Feature pack stack для private edition	Каждые шесть месяцев, если вы его берёте	Вы, в рамках графика SAP	Изменённые стандартные функции, которыми вы пользуетесь, плюс собственный код
Обновление релиза private edition	Не реже раза в семь лет, по запросу в RISE до одного в год	Вы вместе с SAP	Полный набор, собственный код и интеграции
Конверсия ECC в S/4HANA	Один раз	Вы	Всё, что вы сохранили

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

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

Вот инструменты, с которыми вы столкнётесь:

1. SAP Solution Manager. Business Process Change Analyzer, часть Test Suite, показывает, какие бизнес-процессы затрагивает изменение. Scope and Effort Analyzer оценивает влияние пакета поддержки или пакета расширения до установки, и SAP называет его инструментом планирования.
2. SAP Cloud ALM. Cloud ALM управляет планами регрессионного тестирования, выполнением и дефектами и подключается к инструментам автоматизации. Для обновлений public edition инструмент SAP Release Assessment and Scope Dependency показывает, какие изменения релиза затрагивают ваш объём.
3. Tricentis LiveCompare. Согласно документации LiveCompare, он определяет минимальный набор объектов с наибольшим риском для тестирования, а затем сообщает о покрытии и пробелах тестов относительно вашего репозитория тестов. SAP перепродаёт его как SAP Change Impact Analysis by Tricentis, и он интегрируется с Tricentis Tosca.
4. Panaya. Продукт Panaya для обновлений SAP сочетает анализ влияния изменений, исправление кода, управление тестированием и автоматизацию и охватывает версии S/4HANA, feature pack stacks и support package stacks.

Прежде чем строить на Solution Manager, проверьте его статус. SAP Support сообщает, что основная поддержка Solution Manager 7.2 заканчивается в конце 2027 года. Клиенты, которые берут расширенную поддержку Business Suite 7, сохраняют её до конца 2030 года, а SAP рекомендует перейти на Cloud ALM до конца 2027 года.

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

Как эти продукты сочетаются и что уже входит в ваш договор поддержки SAP, описано в моём сравнении инструментов тестирования и проверки SAP.

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

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

Клиент public edition, который прогоняет полный набор дважды в год плюс транспорты между релизами, быстро достигает этой планки. Небольшая система private edition, которая меняется несколько раз в год, может её не достичь.

Задайте эти вопросы до покупки:

1. Сколько у вас регрессионных тестовых сценариев, и сколько из них прогоняются в каждом цикле?
2. Как часто вы их прогоняете, с учётом транспортов, feature packs и обновлений, а не только обновлений релиза?
3. Сколько длится ручной прогон, и укладывается ли он в окно для регрессии?
4. Кто будет сопровождать скрипты, когда меняются экраны и процессы?

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

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

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

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

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

Ландшафт проектаЛандшафт BAU

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

Фокус регрессииЛандшафт проектаПроцессы, которые меняет программа, плюс основной наборЛандшафт BAUПроцессы, которые затрагивает каждое исправление, плюс основной набор

Уходит в продуктивЛандшафт проектаПри go-live или волне релизаЛандшафт BAUКак релизы сопровождения, по обычному графику

Два ландшафта решают задачу разделения, но создают новую работу. Каждое исправление BAU должно попасть и в ландшафт проекта, иначе проект выйдет в go-live без него.

Планируйте это с самого начала:

1. Переносите каждое изменение BAU в ландшафт проекта (retrofit) в фиксированном ритме и отслеживайте каждое.
2. Повторно прогоняйте затронутые тесты проекта после каждого переноса, а не только в конце.
3. Замораживайте изменения BAU по мере приближения перехода, кроме срочных исправлений, которые проходят через оба ландшафта.
4. Прогоните полный регрессионный набор в ландшафте проекта до go-live, на маскированных данных продуктивного уровня.

Второй ландшафт стоит денег, но и go-live, на котором никто не может сказать, какое изменение сломало фактурирование, тоже. Где циклы регрессии стоят рядом с интеграционным и приёмочным тестированием, показывает моя стратегия тестирования S/4HANA.

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

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

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

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

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

Как часто SAP Cloud ERP public edition нужно регрессионное тестирование?

Не реже двух раз в год, потому что SAP обновляет public edition в феврале и августе. SAP сначала обновляет тестовую систему, а продуктивную через несколько недель, поэтому прогон регрессии должен закончиться в этом промежутке. Транспортам между релизами нужны собственные, меньшие прогоны.

Кто проводит регрессионное тестирование при обновлении RISE with SAP private edition?

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

Какие инструменты помогают определить объём регрессионного тестирования SAP?

Инструменты анализа влияния сравнивают то, что изменилось, с тем, чем вы пользуетесь. Распространённые варианты: Business Process Change Analyzer и Scope and Effort Analyzer в SAP Solution Manager и инструмент Release Assessment and Scope Dependency для public edition. Tricentis LiveCompare и Panaya решают ту же задачу, а SAP Cloud ALM управляет планами регрессионного тестирования и выполнением.

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

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

Как проводить регрессионное тестирование во время программы SAP, поддерживая живую систему?

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