Расскажи про свой опыт участия в процессе UAT

Расскажи про свой опыт участия в процессе UAT

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

Что такое UAT

Разница между QA и UAT

QA (Quality Assurance):

• Тестирует, что система работает как написано в требованиях
• "Требование говорит: поле ввода принимает минимум 2 символа. Проверю."
• Technician тест

UAT (User Acceptance Testing):

• Тестирует, что система решает бизнес-проблему пользователя
• "Требование говорит одно, но пользователь хочет по-другому. Почему?"
• Business-ориентированный тест
• Это мойе гада как BA

Процесс UAT в моей практике

Этап 1: Подготовка (за неделю до UAT)

Я готовлю:

a) Тестовое окружение

• Получаю от DevOps staging/UAT сервер
• Проверяю, что тестовые данные загружены
• Заверяю, что система работает

b) Сценарии тестирования

Я пишу не QA-тесты (что систем правильна), а бизнес-сценарии (что система полезна).

СЦЕНАРИЙ 1: Новый рестопран загружает меню

1. Администратор ресторана входит в систему
2. Нажимает "Upload Menu"
3. Выбирает файл Excel с товарами
4. Система загружает
5. Администратор видит список всех товаров
6. Может редактировать цены
7. Сохраняет

ЭТО ДОЛЖНО РАБОТАТЬ:
- Загрузка < 30 сек
- Все товары отображаются
- Цены правильно скопированы
- Изменения сохраняются

ЧТО ПОЛЬЗОВАТЕЛЬ ДОЛЖЕН ЧУВСТВОВАТЬ:
- Это просто (мог бы мой assistenta сделать)
- Быстро (не раздражающе медленно)
- Понятно (нет ошибок, которые не понимаю)

c) Приглашаю пользователей

• Обычно 5-10 реальных пользователей (не инженеры)
• Разные навыки (tech-savvy и не очень)
• Разные роли (админ ресторана, кассир, менеджер)

d) Готовлю материалы

• Инструкция: "Попробуй загрузить меню"
• Тестовые данные: пример файла Excel
• Форма для feedback (что понравилось, что нет)

Этап 2: День UAT

Утро: встреча с пользователями

"Привет, спасибо что пришли. Мы делаем новую систему для загрузки меню. Хотели бы услышать, удобная ли она. Это не тест вашей компетентности, это тест нашего продукта. OK? Поехали!"

Основное тестирование: 2-3 часа

Пользователь 1 (админ ресторана):

• Открыл систему
• "Где загрузить меню? О, вон там кнопка!"
• Кликнул, выбрал файл
• "Загружается... погодите... готово!"
• "Всё товары видны? Да. А вот это цена неправильная — $10 вместо $100. Баг?"

Я наблюдаю и пишу:

• Пользователь сразу нашёл кнопку (UI ясная) ✅
• Загрузка работает ✅
• Но есть проблема с импортом цен (баг в коде или требование неполно?) ❌

У пользователя 2 (кассир, не tech-savvy):

• Открыл систему
• Заблудился в menu
• "Это очень сложно. Мне нужна кнопка ВВЕРХУ"
• Я перемещаю кнопку в мокете

У пользователя 3:

• Пытается загрузить файл в неправильном формате (TXT вместо Excel)
• Система показывает ошибку: "File format not supported"
• Пользователь: "Не понял что сделал не так. Нужна подсказка!"
• Я добавляю требование: "Если неправильный формат, показать: 'Please upload Excel file (*.xlsx)'"

Вечер: интервью с пользователями

Я спрашиваю:

"Это было легко или сложно?" "Ты бы использовал эту систему в реальной работе?" "Что не понравилось?" "Что может быть лучше?"

Пользователь 1: "Легко. Но цена неправильная, это критично." Пользователь 2: "Сложновато. Но если кнопка вверху — будет OK." Пользователь 3: "Хорошо, но нужны подсказки для новичков."

Этап 3: Анализ результатов

Основные findings:

CRITICAL (нужно исправить перед выпуском):
[ ] Импорт цен работает неправильно
[ ] Обработка ошибок неясна (нужны подсказки)

MEDIUM (улучшение, можно после выпуска):
[ ] Кнопка должна быть вверху (UX)
[ ] Нужна help text для новичков

LOW (nice-to-have):
[ ] Показать прогресс-бар при загрузке (психологически)
[ ] Сохранить историю загрузок

Этап 4: Обсуждение с разработчиками

Я собираю встречу: разработчик + я + PM

"Вот что нашли пользователи. Это серьёзно?"

По критичному багу с ценами: Разработчик: "Ах, я не правильно спарсил. Это 30 мин работы." Я: "Спасибо, что быстро. Когда готово?" Разработчик: "Завтра утром."

По UX (кнопка вверху): Разработчик: "Технически просто, 5 мин. Но нужно спросить дизайнера про макет." Дизайнер: "Окей, поменяю в макете." Разработчик: "Переделаю после дизайна."

По подсказкам: Я: "Добавим error messages? Вместо 'File format not supported' показать 'Please upload Excel file (*.xlsx)'." Разработчик: "Легко." Я добавляю требование в Jira.

Этап 5: Re-UAT (через 2 дня)

После исправлений разработчик повторно загружает на UAT.

Я звоню тому же пользователю: "Эй, я исправил то, что ты говорил. Можешь быстро проверить?"

Пользователь 1:

• Загружает меню заново
• Цены правильные ✅
• "Отлично, теперь работает!"

Этап 6: Sign-off

Пользователь официально подписывает: "Система готова к production".

Этого достаточно для выпуска.

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

Проблема 1: Пользователей неправильно выбрал

❌ Пригласил только tech-savvy пользователя → системе понравилось, но обычный пользователь потом жалуется ✅ Пригласил mix: tech-savvy и обычные люди

Проблема 2: Я подсказывал пользователю

❌ Пользователь заблудился, я сказал "кликни сюда" → он нашёл, но это не значит, что UI ясна ✅ Я наблюдаю, не помогаю. Если пользователь заблудился — это UX проблема

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

❌ UAT 1 час → пользователи торопятся, не все сценарии проверили ✅ UAT 2-3 часа → неспешное тестирование, пользователь может поэкспериментировать

Проблема 4: Я не прислушался к feedback

❌ Пользователь сказал "это сложно", я ответил "ты просто не научился" → пользователь недоволен ✅ Я слушаю, принимаю feedback, даже если я не согласен. "Спасибо за feedback, подумаю как улучшить"

Проблема 5: Забыл про пользователей на выпуске

❌ Выпустили в production, пользователи говорят "я этого не ожидал" → проблема ✅ На выпуске обязательно email пользователей: "Вот новая система, помните про UAT? Она готова!"

Реальный пример: CRM система

Фичу: Импорт контактов из CSV

Кто участвовал в UAT:

• Администратор компании (tech-savvy)
• Секретарь (не очень tech)
• Sales Manager (среднее)

Что пользователи нашли:

Пользователь 1 (админ):

• "Хорошо работает, но нужен mapping (выбрать какое поле в CSV это имя, какое email)"
• Я добавил требование: mapping wizard перед импортом

Пользователь 2 (секретарь):

• "Это очень сложно. Можно ли просто загрузить файл?"
• Я добавил требование: простой mode без mapping (используй умные defaults)

Пользователь 3 (менеджер):

• "Нужна возможность не перезаписывать существующие контакты, а добавлять новые"
• Я добавил требование: toggle "Duplicate handling" (skip, update, или add)

Результат: Разработчик переделал импорт. Теперь есть:

• Simple mode (одна кнопка)
• Advanced mode (с mapping)
• Опции для дубликатов

Все три пользователя довольны, система работает для всех.

Мой процесс подготовки к UAT (чек-лист)

[ ] Я выбрал 5-10 реальных пользователей (не инженеры)
[ ] Я пригласил их заранее (за неделю)
[ ] Я подготовил тестовые сценарии (бизнес-ориентированные, не технические)
[ ] Я подготовил тестовые данные (пример файла, пример заказа)
[ ] Я проверил UAT окружение (работает?)
[ ] Я подготовил форму feedback (что понравилось, что нет, баги)
[ ] Я на UAT дне наблюдаю, не подсказываю
[ ] Я пишу все баги в Jira
[ ] Я спрашиваю пользователей про боль (не только про функции)
[ ] Я даю разработчикам feedback и приоритеты (critical vs nice-to-have)
[ ] Я делаю re-UAT после исправлений
[ ] Я получаю sign-off перед production

Вывод

UAT — это не просто еще один тест. Это возможность услышать от РЕАЛЬНОГО пользователя, работает ли система для них.

Часто я думаю, что требование правильное, но пользователь говорит "нет, мне это не подходит". И это ценный feedback.

Хороший BA участвует в UAT, слушает пользователей и использует этот feedback для улучшения продукта перед production выпуском.