Расскажи про свой прошлый проект

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

UAT — это мой责任 как BA. Я не просто должен быть присутствующим, я должен actively facilitate и ensure что все требования validated. Расскажу как я это делал.

Структура UAT которую я устанавливал

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

Я:

1. Собирал right stakeholders (которые заказали требования)
2. Готовил test scenarios
3. Готовил test data (реальные примеры from production)
4. Подготавливал dev/staging environment
5. Писал UAT инструкции (how to test, где найти функцию)

Пример тест сценария:

Scenario: Freelancer finds and applies для project

Preconditions:
- Freelancer logged in
- 5 projects visible

Steps:
1. Open projects page
2. Filter by "web development"
3. Expected: only web projects shown
4. Click на first project
5. Expected: project details open
6. Click "Apply" button
7. Enter cover letter
8. Click "Submit"
9. Expected: success message

Acceptance criteria:
- Application submitted
- Email sent to freelancer
- Project owner sees new application

Шаг 2: Kickoff meeting (день 1)

Я провожу intro session:

• Что такое UAT и почему это важно
• Что ищем (баги vs missing features)
• Как report issues (create ticket в Jira)
• Timeline (обычно 3-5 дней)
• Q&A

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

Пока stakeholders тестируют:

• Я доступен для вопросов (в Slack или in-person)
• Я наблюдаю (не sit silent)
• Я задаю уточняющие вопросы: "А что если...?"
• Я записываю issues (что пошло не так)

Пример моего participation:

Stakeholder: "Это не работает как я ожидал"
Я: "Расскажи что ты пытался сделать?"
Stakeholder: "Я нажал кнопку Apply, но nothing happened"
Я: "Это был button в правом углу?"
Stakeholder: "Да"
Я: "Он был enabled (не grayed out)?"
Stakeholder: "Да"
Я: "A может быть это требует что-то что я missed. Давай вместе check требования"

Роль BA в UAT

1. Я translator между users и техническими людьми

Иногда user говорит: "Это не интуитивно" Я спрашиваю: "Что ты ожидал?" Я документирую это как либо bug либо UX improvement.

2. Я validator требований

Я check:

• Работает ли это как я specified?
• Есть ли edge cases которые я missed?
• Этого достаточно или нужно больше?

3. Я decision maker

Если issue найден:

• Critical: fix immediately
• High: fix before go-live
• Medium: can wait для v1.1
• Low: backlog

Я classify issues и explain логику stakeholder.

Примеры UAT которые я провел

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

Узер жалуется: "Поиск медленный, результаты загружаются 5 секунд"

Мое требование было: "Results load within 2 seconds"

Я спросил разработчика: "Почему 5 секунд?" Он ответил: "Ищу по БД с миллион записей без индексов"

Мое решение:

• Classify как HIGH
• Fix перед go-live: add database indexes
• New timeline: +3 дня работы
• Stakeholder согласился

Пример 2: Payment flow edge case

Stakeholder: "Что если я вернусь на payment page через back button после платежа?" Я: "Good question, давай try"

Результат: Amount doubled! (Платеж went через twice)

Это был critical bug которого я бы не caught в normal testing. Мы fixed это (add idempotency).

Пример 3: Multilingual требование

Stakeholder (German): "Почему text не translated на German?"

Я: "Это был requirement? Давай check"

Текст требования: "Support English and Spanish" Немецкий не был included.

Мое решение:

• Это user expectation которого не было в требованиях
• Classify как Medium (nice-to-have)
• Add в backlog для v1.1

Stakeholder согласился потому что я showed requirement.

Как я capture issues в UAT

Для каждого issue я record:

Bug/Issue Report:

Title: Payment button not responsive
Severity: HIGH
Steps to reproduce:
1. Open payment page
2. Click payment button
3. Wait 10 seconds
4. Nothing happens

Expected: Payment processed, confirmation shown
Actual: No response

Possible cause: Timeout или API down
Business impact: Users cannot complete purchases

Requirement reference: "System shall process payment within 5 seconds"

Decision: FIX BEFORE LAUNCH

Challenging situations в UAT

Situation 1: Stakeholder wants something not in requirements

Stakeholder: "Это не имеет смысл. Нужна кнопка здесь" Я: "Это новое требование? Давай check исходные requirements"

Исходные: не было requirements для этой кнопки.

Мое решение:

• Объяснить что это out of scope
• Add в backlog для next release
• Show trade-off: if add это, timeline shifts

Badly stakeholder согласился и мы moved forward.

Situation 2: Разработчик спорит что это не bug

Разработчик: "Это expected behavior" Я: "Show мне requirement где говорится так" Разработчик: "В requirement не описано edge case" Я: "Exactly, это gap in my requirements. Давай decide: fix код или fix requirement?"

Обычно это приводит к обсуждению и решению.

Situation 3: UAT finds major problem

У нас 2 дня до launch и найдена critical bug которая требует 1 неделю fix.

Мой actions:

1. Escalate немедленно
2. Собрать все stakeholders
3. Present options:
   • Delay launch на неделю (fix bug)
   • Launch without this feature
   • Launch with known bug + hotfix план
4. Let stakeholders decide

Онижелопо: delay launch. Это было right decision потому что launch broken product worse.

Metrics которые я track в UAT

После UAT

Когда все issues resolved и stakeholders approved:

1. Я документирую UAT results:

   • Что тестировали
   • Сколько issues found
   • Все resolved
   • Sign-off from stakeholders

2. Я create launch checklist:

   • Все requirements covered
   • All critical tests passed
   • Performance acceptable
   • Security reviewed
   • Ready for production

3. Я communicate то team:

   • We are GO for production
   • Known limitations (if any)
   • Support plan

Вывод

Мой опыт в UAT это:

• Быть активным participant, не просто наблюдатель
• Understand что required vs что nice-to-have
• Make tough decisions about what to fix before launch
• Communicate clearly with all parties
• Document everything

Best UAT sessions которые я провел: ни criticals bugs не ходил in production, no surprises, happy users, happy team.

Worst: UAT пропущена, production issues, angry customers, emergency fixes.

Это prove: quality UAT это ROI investment.