Стратегия тестирования S/4HANA: циклы, критерии и роли

Стратегия тестирования S/4HANA определяет, какие циклы тестирования вы проводите, в каком порядке, кто отвечает за каждый и какие доказательства позволяют перейти от одного к следующему. В моих программах она охватывает системное интеграционное тестирование (SIT) циклами, приёмочное тестирование (UAT) циклами и регрессионное тестирование, каждое с письменными критериями входа и выхода и названным подписантом.

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

Сами виды тестирования описаны в моём руководстве тестирование SAP простыми словами. Эта статья про уровень стратегии: циклы, критерии, роли и структура документа.

SAP Activate помещает большую часть тестирования в Realize. Собственные материалы SAP по стратегии тестирования для S/4HANA Cloud Private Edition считают модульные тесты и тесты цепочек неформальными. Полные тесты бизнес-процессов, интеграции, миграции данных и приёмки формальные и должны документироваться.

Вот последовательность, которую я планирую в программе S/4HANA:

Циклы тестирования S/4HANA

1. 01

   Модульные тесты и тесты цепочек

   Консультанты тестируют каждую настроенную функцию и короткие цепочки по ходу разработки.

2. 02

   Циклы SIT

   Полные цепочки процессов через модули, интерфейсы и мигрированные данные.

3. 03

   Циклы UAT

   Бизнес-пользователи доказывают, цикл за циклом, что система выполняет их процессы.

4. 04

   Регрессия

   Повторная проверка уже пройденного после исправлений, транспортов и релизов.

5. 05

   Пробные конверсии и репетиция

   Переход проводится так, как он пройдёт в ту самую ночь, по чек-листу.

6. 06

   Go-live

   Go только тогда, когда согласованный чек-лист перехода выполнен.

Модульные тесты и тесты цепочек

Консультанты и разработчики тестируют каждый объект настройки и каждую разработку по мере создания. Тесты цепочек (string tests) соединяют несколько шагов, например заказ клиента до поставки.

В терминах SAP они неформальные, но не необязательные.

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

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

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

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

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

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

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

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

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

Пробные конверсии и репетиция перехода

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

Последняя репетиция должна пройти как настоящая ночь перехода: та же последовательность, те же люди, тот же чек-лист. Где эти прогоны стоят в плане, показывают мои сроки миграции на S/4HANA и план проекта.

Самое важное решение об ответственности: приёмочное тестирование принадлежит бизнесу. Не системному интегратору и не ИТ.

Интегратор может подготовить сценарии и исправить дефекты. Подтвердить, что процессы работают, могут только люди, которые ведут ваше закрытие периода, процесс «от заказа до оплаты» или завод.

Собственные рекомендации SAP указывают туда же. Эксперты партнёра по настройке создают тестовые сценарии, а эксперты клиента из бизнес-подразделений выполняют UAT и фиксируют результаты.

Вот как я бы распределил ответственность по циклам:

Цикл	Ответственный	Выполняет	Подписывает
Модульные тесты и тесты цепочек	Руководитель команды разработки	Консультанты и разработчики	Функциональные и технические руководители
Циклы SIT	Менеджер по тестированию	Консультанты, в поздних циклах вместе с ключевыми пользователями	Менеджер по тестированию и владельцы процессов
Циклы UAT	Бизнес, через названных владельцев процессов	Ключевые пользователи и бизнес-тестировщики	Владельцы процессов, затем спонсор
Регрессия	Менеджер по тестированию	Команда тестирования, с автоматизацией там, где её оправдывает объём	Менеджер по тестированию и совет по изменениям
Пробные конверсии и репетиция	Руководитель перехода	Технические команды, команды данных и функциональные команды	Руководитель перехода, руководитель по данным и спонсор

Вписывайте в стратегию имена, а не роли. «Владелец финансового процесса» это роль; названный человек, который согласился подписать, это ответственный.

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

Напишите и те и другие до начала Realize, пока никто не работает под давлением сроков. Как эти критерии превращаются в формальные контрольные точки с ответственным, который может сказать «не готово», объясняет моё руководство по quality gates в SAP.

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

Цикл	Критерии входа	Критерии выхода
Модульные тесты и тесты цепочек	Проект решения подписан; настройка и разработка завершены для тестируемых объектов	Все объекты протестированы и задокументированы; дефекты исправлены или зарегистрированы на SIT
Цикл SIT	Модульное тестирование завершено для процессов в объёме; тестовая среда построена, интерфейсы подключены; тестовые данные загружены; сценарии проверены	Согласованная доля сценариев выполнена и пройдена; нет открытых критичных дефектов; у каждого открытого менее серьёзного дефекта есть ответственный и дата исправления
Цикл UAT	Критерии выхода SIT выполнены; бизнес-тестировщики названы и освобождены от основной работы; сценарии проверены владельцами процессов; обучение на тестовой системе проведено	Каждый процесс в объёме выполнен бизнес-пользователями; нет открытых критичных дефектов; владельцы процессов подписали свои процессы
Регрессия	Изменение, пакет исправлений или релиз готовы к переносу; регрессионный пакет для затронутых процессов согласован	Регрессионный пакет пройден; любой сбой исправлен и перепроверен до дальнейшего переноса изменения
Пробная конверсия или репетиция	Копия продуктивной системы доступна; чек-лист перехода и регламент (run book) подготовлены в черновике; правила сверки согласованы	Конверсия или загрузка завершены в запланированном окне; сверка подписана руководителем по данным; чек-лист обновлён с учётом уроков
Go-live	Все предыдущие критерии выхода выполнены; чек-лист перехода согласован заранее	Каждый пункт чек-листа выполнен и подписан; решение go или no-go зафиксировано спонсором

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

Если цикл не выполнил критерии выхода, а бизнес всё равно хочет двигаться дальше, оформите это письменным решением. Назовите человека, который принял риск, и дефекты, перенесённые дальше.

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

Вот разделы, которые я ожидаю увидеть:

1. Объём и цели. Какие процессы, юридические лица, интерфейсы и отчёты тестируются и какие явно исключены.
2. Виды и циклы тестирования. Модульные тесты, тесты цепочек, циклы SIT, циклы UAT, регрессия, нагрузочное тестирование, тестирование миграции данных и пробные конверсии, с числом циклов и обоснованием.
3. График и трудозатраты. Даты каждого цикла внутри плана SAP Activate, минимум от 6 до 8 недель на UAT и трудозатраты, заложенные в бюджет исходя из доли тестирования примерно в 35 процентов.
4. Роли и ответственность. Таблица ответственности выше, с именами.
5. Критерии входа и выхода. Один набор на цикл, с подписантом для каждого.
6. Среды. Какие системы используются для какого цикла, как они обновляются и как изменения проекта отделены от изменений сопровождения.
7. Тестовые данные. Откуда берутся данные, как они маскируются и как обновляются между циклами. Подробно это описано в моём руководстве по управлению тестовыми данными SAP.
8. Управление дефектами. Определения серьёзности, ритм разбора, кто решает приоритет и целевое время исправления для каждой серьёзности.
9. Инструменты. Где хранятся тестовые сценарии, результаты, дефекты и подписания, с одной учётной системой.
10. Подход к автоматизации. Какие тесты автоматизируются, какие остаются ручными и почему.
11. Отчётность. Что показывает еженедельный отчёт о тестировании и кто его получает.
12. Критерии перехода и go-live. Чек-лист перехода, репетиции, которые его подтверждают, и кто принимает решение go или no-go.
13. Риски и допущения. Доступность тестировщиков, даты сред, готовность данных и зависимости от третьих сторон.

Что касается инструментов, SAP Cloud ALM по умолчанию используется в новых программах. SAP указывает, что отдельной лицензии на SAP Cloud ALM нет: он входит в Enterprise Support, а его приложения управления тестированием хранят формальные тестовые сценарии, прогоны и результаты.

SAP Solution Manager 7.2 всё ещё используется во многих программах, но его основная поддержка заканчивается в конце 2027 года. Для автоматизации SAP продаёт SAP Test Automation by Tricentis, который работает с Cloud ALM; более широкий выбор описан в моём сравнении инструментов тестирования SAP.

Самая частая ошибка тестирования, которую я вижу: недостаточно тестирования в UAT и SIT.

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

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

1. SIT начинается до завершения модульного тестирования. Первый цикл SIT превращается в цикл модульного тестирования. Соблюдайте критерии входа.
2. На UAT планируют две или три недели. За это время бизнес-пользователи не могут как следует тестировать параллельно с основной работой. Планируйте минимум от 6 до 8 недель и освобождайте тестировщиков.
3. Интегратор проводит UAT за бизнес. Сценарии проходят, а бизнес находит пробелы после go-live. Оставьте ответственность за UAT у владельцев процессов.
4. Тестирование заложено в бюджет как мелкая статья. При доле около 35 процентов трудозатрат тестирование, на которое выделили малую часть этого, урезают первым.
5. Критерии выхода пишут во время цикла. В итоге они совпадают с тем, чего команда успела добиться. Пишите их до Realize.
6. Решение о go-live принимают по ощущениям, а не по чек-листу. Никто не может показать, о чём договорились, поэтому никто не может сказать, чего не хватает.

На последнем пункте я настаиваю. Мой критерий go-live: подробный чек-лист перехода, заранее согласованный с бизнесом, ИТ и интегратором.

Он охватывает технические шаги, загрузки данных, сверки, бизнес-проверки, переключение интерфейсов, доступ пользователей и точки решения go или no-go. Если пункт не выполнен и не подписан, программа не готова, какая бы дата ни стояла.

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

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

Что такое стратегия тестирования S/4HANA?

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

Какую долю программы S/4HANA занимает тестирование?

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

Сколько должно длиться UAT в проекте S/4HANA?

Минимум от 6 до 8 недель. Бизнес-тестировщики проводят UAT параллельно с основной работой, и им нужно время больше чем на один цикл, чтобы исправления первого цикла были перепроверены.

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

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

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

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

Что должен включать чек-лист go-live для S/4HANA?

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