Приёмочное тестирование SAP: кто за него отвечает и как его проводить

Приёмочное тестирование SAP (UAT) это этап, на котором бизнес-пользователи выполняют свои процессы в настроенной системе и формально принимают её до go-live. Владелец этапа бизнес, ИТ и партнёр по внедрению его поддерживают, и в программе S/4HANA я планирую на него минимум от 6 до 8 недель.

Самая частая ошибка тестирования, которую я вижу, проста: недостаточно тестирования в UAT и в системном интеграционном тестировании (SIT). Когда сроки сдвигаются, эти два этапа сжимают, и пробелы вместо этого всплывают после go-live.

Ниже: кто что делает, подготовка, сценарии, разбор дефектов и подписание, которое что-то значит. О том, где UAT стоит среди других видов тестирования, лучше начать с моего обзора тестирования SAP.

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

Причина в самом названии. Приёмка это бизнес-решение о том, может ли система вести бизнес, поэтому принять его могут только люди, которые ведут бизнес. Если UAT подписывает ИТ или партнёр, никто ничего не принял.

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

Работоспособное разделение работы выглядит так:

Роль	За что отвечает в UAT	За что не отвечает
Владельцы бизнес-процессов	Объём сценариев, критерии приёмки, итоговое подписание по своему процессу	Исправление настроек или кода
Ключевые пользователи и тестировщики	Выполнение сценариев, запись результатов и доказательств, регистрация находок	Единоличное решение, что дефект «не дефект»
Руководитель UAT (со стороны бизнеса)	Ежедневный план, прогресс, ведение разбора, отчёты о готовности спонсору	Технические исправления
Партнёр по внедрению	Черновики сценариев, готовность тестовой системы, исправление дефектов, поддержка повторных тестов	Приёмка
Внутренние ИТ	Среды, доступы, интерфейсы с другими системами, транспорты	Приёмка
Команда данных	Загрузка и обновление тестовых данных, поддержка сверки	Проектирование бизнес-сценариев

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

На UAT нужно минимум от 6 до 8 недель. Если меньше, бизнес один раз тестирует «счастливый путь», не успевает перепроверить исправления и так и не доходит до исключений, где живут настоящие проблемы.

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

До того как первый тестировщик войдёт в систему, должно быть готово следующее:

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

На пункте 5 UAT обычно тихо проваливается. Тестировщики, которых просят вписать UAT вокруг закрытия месяца, поставят закрытие месяца на первое место, и будут правы.

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

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

Покройте четыре вида сценариев:

1. Основные потоки. Ежедневные процессы, на которых держится бизнес, такие как «от заказа до оплаты», «от закупки до платежа» и «от учёта до отчётности».
2. Исключения. Возвраты, кредитные блокировки, частичные поставки, изменения цен, сторнирования и отклонённые согласования.
3. Закрытие периода. Шаги закрытия месяца и года, которые финансовая команда действительно выполняет, в том порядке, в котором она их выполняет.
4. Проверки ролей. Каждый тестировщик работает под той ролью, которая будет у него на go-live, чтобы пробелы в полномочиях проявились сейчас.

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

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

В программах, где для управления тестированием всё ещё работает SAP Solution Manager 7.2, учтите, что его основная поддержка заканчивается в конце 2027 года (SAP Support). Новые программы планируйте на Cloud ALM.

Не каждая находка UAT это дефект. Если считать дефектами всё, партнёр утонет, а если считать всё запросами на изменение, настоящие сбои будут скрыты.

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

Простая классификация покрывает большинство находок:

Тип находки	Что это значит	Кто действует	Влияние на подписание
Дефект	Система не делает того, что сказано в подписанном проекте	Партнёр исправляет, тестировщик перепроверяет	Критичные и высокие дефекты блокируют подписание
Запрос на изменение	Проект выполнен, но бизнес теперь хочет другого	Решает орган по проектным решениям, с учётом стоимости и сроков	Не блокирует, если только бизнес не заявляет, что без этого процесс работать не может
Проблема данных	Неверные или отсутствующие основные или транзакционные данные	Команда данных исправляет, тестировщик перепроверяет	Блокирует, если те же данные пойдут в продуктив
Проблема обучения или использования	Система работает, но тестировщик не знал, как ею пользоваться	Руководитель обучения обновляет материалы	Не блокирует, но учитывается в плане обучения
Проблема полномочий	В роли не хватает доступа или его слишком много	Команда безопасности корректирует роль	Блокирует для затронутой роли

Согласуйте определения серьёзности до начала UAT, в бизнес-терминах. Критичный дефект останавливает процесс без обходного пути. У высокого есть обходной путь, который бизнес не может поддерживать на реальных объёмах.

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

Обучение SAP по Activate указывает, что фаза Realize завершена, когда приёмочное тестирование завершено и подписано. Сделайте это подписание документом, а не цепочкой писем.

Каждый владелец бизнес-процесса подписывает свой процесс. В подписании должно быть зафиксировано:

1. Что тестировалось. Выполненные, пройденные и непройденные сценарии, с доказательствами в инструменте тестирования.
2. Что ещё открыто. Каждый открытый дефект с серьёзностью, ответственным и целевой датой.
3. Что принято с обходным путём. Каждый случай назван, с обходным путём, который бизнес согласился применять.
4. Кто подписал и когда. Названный человек по каждому процессу, а не комитет.

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

Подписание UAT это не решение о go-live. Оно лишь входит в него.

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

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

Длинный документ вам не нужен. Нужен один план, который каждый раз отвечает на одни и те же вопросы, написан до начала UAT и подписан бизнесом.

Простая структура покрывает всё:

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

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

Назовите руководителя UAT от бизнеса в этом месяце и попросите каждого владельца процесса выдвинуть тестировщиков с освобождённым временем. Затем внесите в план от 6 до 8 недель на UAT после SIT и отстаивайте их, когда сроки станут плотными.

Если ваше UAT проводит партнёр или его постоянно сжимают, я помогаю программам выстроить это правильно. Вы можете связаться со мной здесь.

Что такое приёмочное тестирование в SAP?

Это этап, на котором бизнес-пользователи тестируют настроенную систему SAP на своих реальных процессах и формально принимают её до go-live. В SAP Activate он проходит в фазе Realize, после интеграционного тестирования. Ключевые пользователи выполняют сценарии, записывают результаты и регистрируют находки, а владельцы процессов подписывают результат.

Кто отвечает за UAT в проекте SAP?

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

Сколько должно длиться UAT в SAP?

Планируйте в программе S/4HANA минимум от 6 до 8 недель. Это даёт время пройти основные потоки, исключения и шаги закрытия периода, а затем перепроверить исправления. Более короткое UAT обычно один раз тестирует «счастливый путь», а остальное находят после go-live.

В чём разница между SIT и UAT в SAP?

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

Что должно включать подписание UAT?

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

Можно ли использовать SAP Cloud ALM для UAT?

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