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

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

Приемочное тестирование (User Acceptance Testing, UAT) — это финальный этап тестирования, при котором реальные пользователи или их представители (бизнес) проверяют, что система соответствует их требованиям и готова к production использованию.

Суть UAT

Это не тестирование на наличие багов (это уже делал QA), а проверка:

• Соответствует ли система бизнес-требованиям
• Работает ли она так, как бизнес ожидает
• Готова ли система к production
• Сможет ли её использовать конечный пользователь

Отличие от системного тестирования

System Testing (QA):

• Фокус на технические требования
• Ищет баги и неполадки
• Проверяет все функции по спецификации
• Выполняют QA инженеры
• Может быть автоматизировано

UAT (Бизнес/Пользователи):

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

Участники UAT

Тестеры UAT:

• Конечные пользователи
• Бизнес-аналитики
• Product Manager
• Представители клиента

Поддержка:

• QA Team (помощь с инструментами)
• Разработчики (исправление критичных багов)
• DevOps (управление окружением)

Сценарий UAT

Пример 1: E-commerce сайт

UAT сценарий: "Пользователь делает покупку"

1. Открыть сайт
2. Найти товар через поиск
3. Добавить в корзину
4. Перейти в checkout
5. Ввести адрес доставки
6. Выбрать способ оплаты
7. Оплатить
8. Получить подтверждение на email
9. Увидеть статус заказа в личном кабинете
10. Получить товар

Я не проверяю код или SQL, я проверяю: "Это работает так, как я ожидаю?"

Пример 2: CRM для компании

UAT сценарий: "Менеджер создаёт сделку"

1. Зайти в CRM
2. Создать нового клиента
3. Создать сделку для клиента
4. Добавить товары в сделку
5. Отправить счёт клиенту
6. Получить оплату
7. Отметить сделку как закрытую
8. Менеджер видит отчёт по закрытым сделкам

Процесс UAT

Фаза 1: Подготовка (1 неделя)

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

Фаза 2: Исполнение (1-2 недели)

• Тестеры выполняют сценарии
• Фиксируют нарушения в чек-листе
• Сообщают о проблемах
• QA помогает с инструментами и воспроизведением

Фаза 3: Анализ (3-5 дней)

• Анализ найденных проблем
• Классификация по severity
• Critical баги исправляются немедленно
• Major баги могут отложить релиз
• Minor баги могут быть исправлены после релиза

Фаза 4: Знак-off (1 день)

• Если все critical и major баги исправлены
• Бизнес дает "sign-off" (согласие на production)
• Готово к deployment

Типы багов при UAT

Critical (блокирует релиз):

• Функция вообще не работает
• Данные теряются
• Невозможно завершить основной сценарий

Major (может отложить релиз):

• Функция работает, но не соответствует ожиданиям
• Performance проблемы
• Usability проблемы

Minor (может быть исправлено позже):

• Косметические проблемы
• Опечатки
• Улучшения

Критерии успеха UAT

✓ Все основные сценарии работают
✓ Нет критичных багов
✓ Нет data loss
✓ Интерфейс интуитивен
✓ Производительность приемлема
✓ Бизнес согласен использовать
✓ Sign-off получен

Типичные проблемы в UAT

Проблема 1: Требования были неясными

• Бизнес ожидал одного
• Разработка реализовала другое
• UAT вывела это на поверхность
• Нужно исправление (обычно дорогое)

Решение: четкие requirements и reviews на ранних стадиях

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

• Планировали 1 неделю, нужно 3
• Тестеры спешат
• Баги не найдены
• Проблемы обнаруживаются в production

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

Проблема 3: Тестеры не знают систему

• Не обучили пользователей
• Они не знают, как её использовать
• UAT результаты неверны

Решение: хорошее обучение перед UAT

Инструменты для UAT

• Google Forms: сбор feedback
• Jira: отслеживание проблем
• TestRail: управление тестами
• UserTesting: remote UAT
• Zoom: демонстрация и обсуждение

Мой опыт с UAT

На одном проекте был month-long UAT с 50 реальными пользователями. Результаты:

• Нашли 200+ issues
• 15 critical багов
• 40 major проблем
• Остальное minor improvements

Bуз UAT мы бы запустили в production с критичными ошибками.

UAT vs Production

Даже если UAT perfect:

• Всё равно будут проблемы в production
• Real users могут использовать по-другому
• Load может быть выше
• Edge cases, которые не протестировали

Но UAT существенно снижает вероятность disaster.

Совет QA

Даже если тебе не дали присутствовать на UAT:

1. Убедись, что UAT сценарии покрывают все требования
2. Приготовь инструменты для быстрого воспроизведения багов
3. Помоги тестерам документировать проблемы
4. Помоги разработчикам разобраться в issues
5. Убедись, что всё исправилось перед релизом

UAT — это последняя линия защиты перед production. Относись серьёзно.