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

Приёмочное тестирование (UAT — User Acceptance Testing) — последний уровень тестирования перед выпуском ПО в продакшен. Оно отвечает на принципиально иной вопрос, чем все остальные уровни. В то время как модульные, интеграционные, системные и E2E тесты спрашивают «ПО работает правильно?», UAT спрашивает «ПО делает то, что бизнесу действительно нужно?»

Это различие критично. Система может пройти все технические тесты — каждая функция работает, каждый API отвечает корректно — и всё равно провалить UAT, потому что не решает проблему, которую бизнес хотел решить.

Представьте компанию, которая заказала генератор отчётов. Команда разработки строит его идеально по спецификации: вытягивает данные из БД, применяет фильтры, генерирует PDF. Все тесты проходят. Но на UAT финансовый менеджер говорит: «Мне нужен экспорт в Excel, не в PDF. И данные по кварталам, не по месяцам.» Система работает корректно, но не отвечает реальной потребности бизнеса.

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

Кто проводит UAT?

UAT проводят бизнес-пользователи — люди, которые реально будут работать с ПО:

  • Product owners, определившие требования
  • Бизнес-аналитики, переведшие потребности бизнеса в спецификации
  • Конечные пользователи или их представители
  • Доменные эксперты, понимающие бизнес-правила
  • Специалисты по комплаенсу в регулируемых отраслях

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

Типы приёмочного тестирования

Альфа-тестирование

Проводится внутри организации людьми, не входящими в команду разработки.

Кто: Внутренние сотрудники, стейкхолдеры, бизнес-аналитики Где: Внутреннее тестовое окружение (не продакшен) Когда: До бета-тестирования, после системного Цель: Обнаружить серьёзные проблемы до передачи внешним пользователям

Бета-тестирование

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

Кто: Внешние пользователи, ранние последователи, выбранные клиенты Где: Реальные окружения (устройства и сети пользователей) Когда: После альфа-тестирования, до общего релиза Цель: Обнаружить проблемы, возникающие только в разнообразных реальных условиях

Контрактное приёмочное тестирование

Проверяет соответствие ПО контрактным обязательствам, определённым в формальном соглашении.

Кто: Представители заказчика и исполнителя Что: Тестирование против конкретных контрактных критериев Когда: До оплаты/подписания акта приёмки Цель: Юридическая верификация выполнения всех контрактных требований

Регуляторное приёмочное тестирование

Проверяет соответствие ПО отраслевым регуляциям, юридическим требованиям и стандартам.

Кто: Специалисты по комплаенсу, аудиторы, регуляторы Что: Тестирование против конкретных регуляций (HIPAA, GDPR, 152-ФЗ, PCI-DSS) Когда: До развёртывания в регулируемых окружениях Цель: Обеспечение юридического и регуляторного соответствия

Планирование UAT

1. Определение объёма

Что будет тестироваться? Какие функции, потоки и бизнес-процессы?

2. Написание критериев приёмки

Каждое требование должно иметь чёткие, измеримые критерии:

  • Конкретные: «Пользователь может сгенерировать квартальный отчёт о доходах»
  • Измеримые: «Отчёт генерируется менее чем за 10 секунд»
  • Тестируемые: Чёткие условия прохождения/провала

3. Подготовка сценариев

Бизнес-пользователи тестируют по реалистичным сценариям из повседневной работы:

  • «Обработать стандартный заказ от котировки до счёта»
  • «Применить скидку 15% к оптовому заказу свыше $10,000»
  • «Сгенерировать отчёт финансовой сверки на конец месяца»

4. Подготовка окружения

  • Данные, похожие на продакшен (анонимизированные при необходимости)
  • Все интеграции подключены
  • Учётные записи с правильными ролями и разрешениями

5. Обучение участников UAT

Бизнес-пользователи — не профессиональные тестировщики. Им нужны:

  • Инструкции по отчётности о проблемах
  • Понимание объёма тестирования
  • Доступ к поддержке от QA/dev команды

6. Определение критериев подписания

Когда UAT завершён? Типичные критерии:

  • Все критические сценарии проходят
  • Нет блокирующих дефектов
  • Стейкхолдеры формально одобряют
  • Документированные свидетельства тестирования

Процесс подписания (Sign-Off)

graph LR EXEC[Выполнение UAT] --> REVIEW[Обзор результатов] REVIEW --> DEFECTS{Критические дефекты?} DEFECTS -->|Да| FIX[Исправить и перепроверить] FIX --> EXEC DEFECTS -->|Нет| ACCEPT{Критерии выполнены?} ACCEPT -->|Нет| NEGOTIATE[Переговоры со стейкхолдерами] NEGOTIATE --> EXEC ACCEPT -->|Да| SIGNOFF[Формальное подписание] SIGNOFF --> RELEASE[Выпуск в продакшен]

Роль QA в UAT

QA не проводит UAT, но играет ключевую поддерживающую роль:

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

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

После UAT: Координация исправлений, повторная проверка, составление отчёта, содействие процессу подписания.

Упражнение: Создайте план UAT с критериями приёмки

Вы — QA Lead нового портала самообслуживания HR. Портал позволяет сотрудникам:

  1. Просматривать и обновлять личную информацию
  2. Подавать заявки на отпуск (ежегодный, больничный, личные дни)
  3. Просматривать расчётные листки и налоговые документы
  4. Регистрироваться в программах льгот

Создайте план UAT:

  • 3 UAT-сценария для заявок на отпуск
  • Критерии приёмки для каждого сценария
  • Кто должен выполнять каждый сценарий
  • Критерии подписания для всего UAT
ПодсказкаПодумайте о рабочем процессе с перспективы сотрудника. Каковы happy paths? Какие правила должны соблюдаться (доступный баланс, одобрение руководителя, закрытые даты)?
Решение

Сценарий 1: Стандартная заявка на отпуск

  • Актор: Обычный сотрудник (Мария, отдел маркетинга)
  • Шаги: Вход → Раздел «Отпуска» → Новая заявка → Выбрать «Ежегодный отпуск» → Выбрать даты (5 рабочих дней) → Проверить баланс → Отправить
  • Критерии приёмки:
    • Расчёт баланса точный
    • Уведомление руководителю в течение 5 минут
    • Заявка отображается как «Ожидает одобрения»
    • Календарь показывает даты как «Ожидающие»

Сценарий 2: Больничный с недостаточным балансом

  • Актор: Сотрудник с 2 оставшимися днями (Алексей, инженерия)
  • Шаги: Запросить 3 дня больничного
  • Критерии приёмки:
    • Предупреждение: «Запрошено: 3 дня, Доступно: 2 дня»
    • Система позволяет отправку, но помечает «Превышает баланс»
    • Уведомление руководителю включает предупреждение
    • HR автоматически уведомлён

Сценарий 3: Процесс одобрения руководителем

  • Актор: Руководитель (Иван, директор по маркетингу)
  • Предусловие: Заявка Марии из сценария 1 отправлена
  • Шаги: Вход как руководитель → Уведомление → Просмотр заявки → Календарь команды → Одобрить
  • Критерии приёмки:
    • Руководитель видит полные детали
    • Календарь команды показывает конфликты
    • Одобрение/Отклонение требует указать причину
    • Сотрудник уведомлён в течение 5 минут
    • Система HR обновлена сразу после одобрения

Участники UAT: 5-10 сотрудников, 3-5 руководителей, 1 HR-администратор, 1 специалист по расчёту заработной платы

Критерии подписания:

  • Все 3 критических сценария проходят для всех групп
  • Нет блокирующих дефектов
  • Мелкие UI-проблемы задокументированы с графиком исправления
  • Формальное подписание HR-директором
  • Точность расчётов проверена минимум на 10 случаях

Типичные ошибки UAT

Ошибка 1: Использование UAT для поиска багов. Если бизнес-пользователи тратят время на отчёты о падениях, система не была готова к UAT.

Ошибка 2: Отсутствие чётких критериев приёмки. Без измеримых критериев UAT становится субъективным упражнением.

Ошибка 3: Неправильные участники. Если разработчики или QA проводят UAT — это лишает его смысла.

Ошибка 4: Бесконечные циклы UAT. UAT должен иметь определённую длительность и чёткие критерии завершения.

Профессиональные советы

Совет 1: Планируйте UAT заранее. UAT часто выявляет недопонимания требований, требующие существенной переработки. Заложите время минимум на два цикла.

Совет 2: Предоставьте реалистичные данные. Бизнес-пользователи не могут проверить бизнес-логику на фейковых данных. Используйте анонимизированные данные из продакшена.

Совет 3: Документируйте всё. Подписание UAT — формальное бизнес-событие. Ведите записи о том, кто что тестировал, что прошло, что провалилось и кто одобрил.

Ключевые выводы

  • UAT подтверждает соответствие системы потребностям бизнеса, а не только техническим требованиям
  • Бизнес-пользователи проводят UAT — не QA и не разработчики
  • Четыре типа: альфа (внутреннее), бета (внешнее), контрактное (юридическое), регуляторное (комплаенс)
  • Чёткие критерии приёмки с измеримыми условиями обязательны
  • QA поддерживает UAT через планирование, настройку окружения и координацию дефектов
  • Процесс подписания формализует бизнес-одобрение для выпуска в продакшен