Пользовательское тестирование UAT для CRM/ERP: сценарии и приемка

Что решает UAT при внедрении CRM/ERP

UAT (пользовательское тестирование) отвечает на один вопрос: система готова к реальной работе или нет. Это не проверка качества кода и не набор технических тестов. Здесь бизнес подтверждает, что процессы выполняются так, как принято в компании, и результат можно безопасно отдавать пользователям.

Разница в фокусе простая. ИТ обычно смотрит на стабильность, ошибки, интеграции и скорость. Бизнес смотрит на смысл: можно ли выписать счет, провести заказ, закрыть обращение, сформировать отчет и при этом не нарушить правила работы отдела.

UAT закрывает риски, которые часто всплывают уже после запуска:

• критичные шаги процесса не совпадают с реальной практикой
• данные заполняются, но дальше не используются (или попадают не туда)
• права доступа настроены так, что работа стопорится
• отчеты не совпадают с тем, как руководители видят картину
• пользователи находят обходные пути и возвращаются в Excel

Результат UAT - не «список багов», а управленческое решение: принять, принять с оговорками (с известными ограничениями) или отправить на доработку. Это решение должно опираться на заранее согласованные критерии приемки.

Без критериев приемки тестирование быстро превращается в спор. Один говорит: «работает, кнопку нажимаешь - статус меняется». Другой: «не работает, потому что статус не тот и не в тот момент». Например, в CRM менеджер должен видеть этап «Согласование» только после прикрепления КП и проверки лимита. Если правило не записано как критерий, каждый будет трактовать «готово» по-своему.

Участники UAT и распределение ответственности

UAT работает только тогда, когда ясно, кто принимает решение, а кто помогает. Бизнес принимает систему. Команда внедрения обеспечивает условия, объясняет настройки и устраняет проблемы, но не «сдает экзамен за бизнес».

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

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

Команда внедрения (включая аналитика) помогает:

• превратить рабочие ситуации в понятные сценарии и тестовые данные
• объяснить, как должно работать по настройкам и регламентам
• быстро разбирать дефекты и вопросы
• держать дисциплину фиксации результатов

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

Финальную подпись ставит назначенный бизнес-спонсор (часто владелец процесса или руководитель направления). Основание - выполненные сценарии, достижение критериев приемки и список известных ограничений, которые бизнес согласен принять сейчас. Если вы работаете с системным интегратором, закрепите это правило письменно: кто принимает, кто исправляет, кто подтверждает исправление.

Определяем охват: что проверяем, а что оставляем за рамками

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

Начните со списка процессов, которые обязаны пройти UAT, потому что по ним будут работать в первый день после запуска. Обычно это:

• продажи: лид - сделка - счет/договор - закрытие
• закупки и склад (для ERP): заявка - заказ - приемка - списание
• финансы: документы, оплаты, сверка статусов
• сервис: обращение - назначение - выполнение - закрытие
• управление доступами: ключевые роли и типовые права

Дальше решите, какие интеграции и отчеты входят в проверку. Правило простое: включайте то, что влияет на решение пользователя здесь и сейчас. Например, интеграция с почтой и телефонией для продаж, обмен с бухгалтерией для счетов, выгрузка в BI - только для 2-3 ключевых витрин.

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

Чтобы сценарии не расползались, держите правило: один сценарий - один проверяемый ожидаемый результат. Пример: «Менеджер создает сделку и выставляет счет» - а в ожидаемом результате ровно один факт: «счет получил статус “Отправлен” и появился в реестре счетов».

Как собрать сценарии UAT без лишней бюрократии

Сценарии проще собирать не «с нуля», а из того, чем бизнес живет каждый день. Проведите 2-3 короткие встречи по 45 минут с ключевыми пользователями: продажи, сервис, финансы, склад (если есть). Обсуждайте ежедневные действия, частые боли и отчеты, которые нужны к концу дня или месяца.

Источники сценариев обычно на поверхности: регламенты и инструкции, текущие отчеты и выгрузки, список частых обращений в поддержку, требования из проекта. Полезный прием: попросите пользователей назвать 5 ситуаций, из-за которых они сейчас теряют время или деньги. Это и есть ядро UAT.

Чтобы не разрастаться, используйте один простой шаблон сценария:

• цель
• шаги (5-10 действий без лишних деталей)
• тестовые данные (какие поля и значения нужны)
• ожидаемый результат
• примечания (ограничения, роли, «подводные камни»)

Тестовые данные лучше готовить совместно: бизнес дает реалистичные примеры (клиенты, номенклатура, типовые суммы), команда внедрения помогает загрузить их в тестовый контур. Храните данные в одном месте и по правилам: один владелец набора данных, понятные названия, запрет на персональные данные, если это не согласовано.

Не забывайте про исключения. Помимо «идеального» процесса, добавьте по 1-2 проверки на сценарий: отмена заказа, возврат, дубль клиента, неполные данные, смена ответственного.

Минимальный набор, который почти всегда дает пользу:

• сквозные цепочки от начала до конца (лид -> сделка -> документ -> оплата)
• 2-3 критических отчета (день, неделя, месяц)
• права доступа по ролям
• интеграции, без которых процесс не работает
• один сценарий на «ошибку пользователя» (пропущено поле, неверная сумма)

Так вы проверите главное без толстых папок и сотен тест-кейсов, которые никто не успеет пройти.

Назначаем бизнес-ответственных: как выбрать и закрепить роль

Бизнес-ответственный в UAT - человек, который говорит от имени процесса: «да, так мы работаем» или «нет, так нельзя». Без этой роли тест быстро превращается в набор разрозненных замечаний, где никто не принимает решение.

Выбирать стоит не «самого активного», а того, кто действительно управляет ежедневной работой и имеет право финального слова. Часто это руководитель группы, старший специалист или владелец процесса (например, руководитель продаж для воронки и сделок).

Признаки, что кандидат подходит:

• знает процесс и исключения, а не только «идеальный путь»
• умеет принимать решения и фиксировать компромиссы
• доступен в период UAT (время выделено заранее)
• формулирует ожидания простыми словами, не уходит в детали разработки
• готов отвечать за результат, а не только «просить доработку»

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

Полномочия лучше закрепить письменно: приказ/распоряжение по проекту, письмо со списком процессов и сроков или протокол стартовой встречи UAT.

Пошаговый план UAT: от старта до решения о приемке

Чтобы UAT не превратилось в хаос, важнее всего зафиксировать порядок работы и не менять правила по ходу. Тестирование лучше проводить на отдельной среде, с понятными доступами и «замороженной» версией системы на весь период проверки.

Рабочий план:

• подготовить среду и учетные записи (роли, права, тестовые данные); версию на время UAT не обновлять без согласования
• провести короткий инструктаж (20-30 минут): где сценарии, как фиксировать шаги, что считать дефектом, а что запросом на улучшение
• выполнять сценарии и ставить единые статусы: «пройдено», «не пройдено», «блокировано»
• делать ежедневную сверку (10-15 минут): что пройдено, что блокирует, кто и к какому сроку снимает блокер
• после исправлений повторять проверку: сначала «упавший» сценарий, затем затронутые соседние процессы (контроль регрессии)

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

Финальный шаг - итоговый протокол. В него обычно входят: процент пройденных сценариев, список открытых дефектов (критичность и сроки), что принято с оговорками, и четкое решение: принимаем, принимаем после исправлений или переносим запуск.

Критерии приемки: как формулировать, согласовать и измерять

Критерии приемки - договоренность, по которой вы решаете: система готова к запуску или нет. Они защищают от расплывчатого «вроде работает» и помогают быстро закрывать спорные моменты.

Хороший критерий всегда проверяемый. Он отвечает на три вопроса: что делаем, на каких данных, какой результат считаем правильным и как это измеряем. Формулировки «удобно», «быстро», «корректно» без примеров почти всегда приводят к конфликтам.

Как формулировать критерии, чтобы их можно было подписать

Удобный формат: действие + условия + ожидаемый результат + допуск.

• функция: «Менеджер создает сделку с обязательными полями; без ИИН клиента сделка не сохраняется; система показывает понятную ошибку»
• данные: «После миграции 100% активных клиентов имеют уникальный ИИН; дублей по ИИН нет; 10 выборочных карточек совпадают с источником по ключевым полям»
• расчеты: «Сумма счета = сумма строк - скидка + НДС; на тестовом наборе из 5 примеров расхождение 0»
• интеграции: «Счет из CRM появляется в учетной системе в течение 5 минут; статус оплаты возвращается; ошибки пишутся в журнал»
• ограничения: «Одновременная работа 30 пользователей в течение 1 часа без падений; открытие карточки клиента - до 3 секунд»

Пример для продаж: критерий - не «счет формируется», а «счет формируется по шаблону N, реквизиты подтягиваются из справочника, сумма считается по правилам, файл открывается без ошибок».

Порог приемки: что блокирует запуск

Заранее договоритесь, какие дефекты считаются критическими. Обычно критично то, что ломает ключевой процесс, портит данные или мешает закрывать период.

• критический: нельзя провести заказ или счет, теряются данные, неверные суммы, не работает обязательная интеграция
• некритический: опечатка, неидеальная форма, улучшение отчета

Зафиксируйте критерии в одном документе и подпишите владельцами процессов. Тогда итог UAT измеряется фактами: выполнено или нет, плюс понятный список исключений и сроков.

Фиксация результатов: журнал тестов, дефекты и запросы на изменения

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

Минимальный набор полей для журнала:

• сценарий и шаг
• ожидаемый и фактический результат
• доказательства (скрин, выгрузка, номер документа)
• ответственный за проверку (бизнес) и за исправление (команда внедрения)
• статус и дата (Найдено, В работе, Готово к ретесту, Принято)

Дальше договоритесь о простой классификации дефектов, чтобы не спорить о приоритетах на каждом кейсе:

• критично: процесс останавливается
• важно: процесс возможен, но с потерями (ошибки в расчетах, неверные права, сбои интеграции)
• косметика: не влияет на результат

Чтобы UAT не растянулся, задайте правила по срокам и подтверждению: когда исправляют, когда назначается ретест и кто ставит финальное «принято». Например: критичные - исправление за 1-2 дня и ретест в тот же день; важные - в ближайший спринт; косметика - в бэклог.

Отдельная ловушка - путать дефект и запрос на изменение. Дефект - система не делает то, что согласовано в требованиях и критериях приемки. Запрос на изменение - «давайте теперь по-другому». Такие запросы лучше сразу помечать как change request и оценивать отдельно.

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

Частые ошибки в UAT и как их избежать

Самая частая причина провала UAT - не баги, а организация. Цель тестирования - подтвердить, что процессы работают на реальных данных и в реальных ролях, а не просто что экран открывается.

1. Слишком общие сценарии. Если написано «создать клиента» без входных данных и ожидаемого результата, участники тестируют каждый свое. Нужны роль, конкретные данные (например, ИИН, тип договора, скидка) и четкий результат (создана карточка, статус изменился, документ сформирован).

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

3. Размытые решения. Если бизнес-ответственные не назначены, каждый комментарий превращается в обсуждение. Нужен владелец на каждый процесс с правом финального слова.

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

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

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

Короткий чеклист перед запуском UAT

Перед стартом убедитесь, что вы готовы не только «погонять систему», а принять решение о выпуске в работу.

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

Минимальная проверка перед запуском:

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

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

Пример сценария: UAT для внедрения CRM в продажах и сервисе

Контекст: компания продает оборудование и сопровождает клиентов после покупки. В UAT участвуют отдел продаж, сервисная служба, бухгалтерия и руководитель направления (он подтверждает, что процесс «работает как надо»). Проверяют не «красоту интерфейса», а то, что ключевые операции выполняются без обходных путей.

Критические сценарии удобно формулировать как короткие истории с понятным результатом:

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

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

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

Итог UAT - список сценариев со статусами «принято/не принято», перечень принятых ограничений (что временно делаем вручную) и план доработок после запуска с владельцами и сроками.

Что делать после UAT: запуск, контроль и поддержка

После UAT важно собрать понятный пакет приемки: протокол решения, список дефектов с их статусом и известные ограничения (что пока работает «как есть» и почему это допустимо). Это снижает споры в первые дни запуска.

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

Чтобы контроль был честным, выберите 3-4 метрики на первые 2-3 недели. Они должны показывать работоспособность процесса: сколько критичных ошибок, сколько обращений в поддержку, сколько времени занимает ключевая операция (оформление заказа или закрытие заявки), сколько операций уходит в обходной путь.

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

Если в проекте параллельно стоит задача по инфраструктуре (серверы, рабочие места, поддержка 24/7), это удобно закрывать одним партнером. Например, GSE.kz как производитель и системный интегратор может взять на себя часть работ по инфраструктуре и сопровождению, чтобы команда проекта не разрывалась между UAT, запуском и поддержкой пользователей.