Почему UAT важен для бизнес-аналитика?

UAT (User Acceptance Testing): почему это критично для BA

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

Что такое UAT и почему это не просто QA

QA (Quality Assurance) проверяет:

• Баги и ошибки
• Соответствие техническим требованиям
• Производительность и нагрузку
• Безопасность

Пример QA issue: "Кнопка Submit не работает на мобильном"

UAT проверяет:

• Решает ли система реальную бизнес-проблему
• Удовлетворены ли end-users функциональностью
• Работают ли процессы так, как ожидается
• Не забыли ли мы что-то важное

Пример UAT issue: "Мы никогда не экспортировали отчёты в Excel, а это нужно нам каждый день"

Почему UAT важен для BA

1. Валидация требований

Я потратил 2 месяца на документирование требований. UAT — это момент, когда заказчик говорит: "да, это именно то, что нам нужно" или "стоп, мы имели в виду совсем другое".

Примеры из реальных проектов:

Проект 1: CRM система

Требование: "Пользователь должен видеть историю звонков"
В UAT обнаружилось: "Нам нужно видеть не просто историю, но и 
анализировать: сколько звонков в день, средняя длительность, 
когда больше всего звонков. А ещё нам нужен отчёт по agentам."

Результат: я добавил 5 новых требований, которые изначально прошли мимо.

Проект 2: Платёжная система

Требование: "Возврат платежа должен быть обработан за 24 часа"
В UAT обнаружилось: "Это не работает, когда платёж идёт на карту 
другого банка. Там обработка 3-5 дней. Нужно отправлять SMS и email 
с информацией о статусе возврата."

Результат: интегрировал SMS сервис, добавил систему уведомлений.

2. Поймание недоработок на ранней стадии

Лучше найти проблему в UAT (стоит дни работы), чем в production (стоит потерю доверия и дорогостоящие исправления).

Мой опыт: в 30% UAT тестов находим issues, которые QA пропустили.

3. Снижение риска переделок после launch

• Post-launch fix = расстроенные пользователи
• Post-launch fix = переключение разработчиков с новых фич
• Post-launch fix = потеря momentum проекта

УАТ как "quality gate" до того, как товар выходит.

4. Документирование того, как действительно работает система

Я пишу требования, я предполагаю, как система будет работать. Но разработчик реализует это немного по-другому (потому что есть технические ограничения, или он нашёл лучший способ).

UAT — это момент, когда я проверяю: работает ли это так, как я представлял? Если нет, это либо bug, либо я неправильно написал требование.

5. Обучение пользователей и приёмка системы

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

"А можно ли фильтровать по датам?" "А что если я случайно нажму Delete?" "А как я выгружу данные для начальника?"

Получив ответы, пользователи более готовы к запуску.

Мой процесс UAT

Шаг 1: Подготовка (за 2 недели до UAT)

• Готовлю тестовые данные (реальные, которые заказчик использует)
• Создаю UAT план — конкретные сценарии для проверки
• Согласовываю, кого привлечь (key users, managers, stakeholders)

Шаг 2: Вводный сеанс (день 1)

1. Демонстрирую систему
2. Объясняю процесс: что проверяем, как репортить баги
3. Отвечаю на вопросы
4. Даю доступ и рабочие сценарии

Шаг 3: Тестирование (3-5 дней)

• Пользователи работают с системой самостоятельно
• Я доступен для вопросов
• Собираю feedback и issues

Шаг 4: Анализ результатов

• Классифицирую issues:
  • Critical — система не работает (блокер для launch)
  • High — функция работает неправильно (нужно фиксить)
  • Medium — неудобно, но работает (может быть в v2)
  • Low — пожелание улучшения (backlog)

Шаг 5: Итерация

• Critical и High issues идут в разработку
• Проводим повторный round UAT
• После одобрения пользователей — ready for production

Примеры issues, найденных в UAT

Критичные (блокеры):

• Экспорт данных теряет символы (кодировка UTF-8 не работала)
• Система не сохраняет данные при быстром клике (race condition)
• Отчёт показывает неправильные числа (калькуляция ошибочна)

Высокие (нужно фиксить):

• Фильтр по дате работает неправильно в январе (смещение на 1 день)
• API возвращает 500 ошибку при определённых параметрах
• UI элемент перекрывает другой на мобильном

Medium (может быть позже):

• "Было бы удобнее, если кнопка была слева, а не справа"
• "Можно добавить сортировку по новым полям?"
• "Было бы хорошо, если при сохранении было уведомление"

Частые проблемы в UAT

❌ Проблема: ЛЯ заказчика не явился на UAT

Результат: систему запустили, потом выясняется, что это не то.
Решение: договориться о UAT за месяц, напомнить за 2 недели, за 3 дня.

❌ Проблема: UAT проводится с неправильными пользователями

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

❌ Проблема: Недостаточно времени на UAT

На UAT выделили 1 день.
Результат: пользователи не успели протестировать все сценарии.
Решение: минимум 3 дня полного доступа, чтобы пользователи могли работать в своем темпе.

❌ Проблема: Issues не фиксятся, а система запускается

Заказчик спешит, говорит: "Выпустим, потом отфиксим".
Результат: production issues, потеря доверия пользователей.
Мой подход: я фильтрую issues, отделяю critical от nice-to-have.
Critical issues ДОЛЖНЫ быть фиксены перед launch.

Как BA использует UAT результаты

1. Документирование reality

• Если система работает не так, как в требованиях, я обновляю спецификацию
• Это становится source of truth для будущих разработок

2. Обновление acceptance criteria

• Если AC были неправильные, я их уточняю
• Это помогает QA в будущих версиях

3. Feedback для архитектора

• "Операция X занимает 30 секунд, это слишком медленно"
• Может быть нужна оптимизация на уровне базы данных

4. Планирование v2

• "Это работает, но было бы хорошо добавить Y"
• Идет в backlog как новое требование

Метрики UAT

Мой опыт

В худшем проекте (финтех) я пропустил требование про audit logs. UAT нашёл это, я добавил функцию, потом из-за этого нашли серьёзный баг в безопасности.

Если бы не UAT, это вышло бы в production и стало security issue.

Вывод

UAT важен для BA, потому что:

1. Это последняя возможность поймать ошибку в требованиях
2. Это валидация того, что я правильно понял заказчика
3. Это protection от post-launch проблем
4. Это engagement пользователей перед launch
5. Это opportunity собрать feedback на v2

Если я пропущу UAT или отнесусь к нему неответственно, то увеличу риск неудачного проекта.

UAT — это не обязанность QA, это ответственность BA. Я за это отвечаю.