Фаза 7 з 9
UAT — користувацьке приймальне тестування
Прогнати наскрізні сценарії з реальними користувачами на копії продакшну. Виявити блокери до Go-live.
Передумови
- Завершена кастомізація і інтеграція (фази 4-5)
- Натреновані ключові користувачі (фаза 6, мінімум перший тиждень)
- UAT-середовище з production-like даними (виділений сервер)
- Defect tracker (Jira, Linear, або хоча б Trello)
Покрокові завдання 22
- UAT environment з production-like даними (повний обсяг, замасковані PII)
- Призначення UAT-тестерів: бухгалтер + майстер + продажі + закупки + керівник
Кожен тестер віддає UAT половину робочого часу — це багато. Sponsor це підтверджує.
- Сценарій 1: повна закупівля (RFQ → PO → М-4 → отримання ПН → зачитка)
- Сценарій 2: повний виробничий цикл (BoM → MO → M-11 → акт виробництва)
- Сценарій 3: реалізація з виставленням ПН (quotation → SO → видаткова → ПН → ЄРПН)
- Сценарій 4: повернення товару від покупця з РК
- Сценарій 5: експорт (0% ПДВ, ВМД, валютна оплата)
- Сценарій 6: defense-постачання (Прозоро.МО → SO → М-4 → акт відвантаження → ПН-09)
- Сценарій 7: закриття місяця (списання, ЗВВ, собівартість, trial balance)
- Сценарій 8: інвентаризація (інв-3, лишки/нестачі, проведення)
- Сценарій 9: декларація з ПДВ за повний місяць (з ПН, РК, компенсуючими)
- Сценарій 10: брак (виявлення → акт браку → списання → коригування собівартості)
- Виконання усіх 30+ сценаріїв тестерами, фіксація результатів
- Defect tracking: severity 1 (блокер) / 2 (критичний) / 3 (важливий) / 4 (косметика)
- Daily standups: 15 хв щоранку про прогрес і блокери
- Виправлення severity-1 і 2 розробником, повторне тестування
- Regression тестування після кожного фіксу — підмножина сценаріїв
- Performance testing: 1000+ операцій за годину, час відгуку <2 сек
Особлива увага: масові імпорти, місячне закриття, генерація ПН пачкою.
- Security review: права доступу, OWASP top-10, audit log
- Defense: окремий security review модуля ДСК
- Signoff від бізнес-власників кожного процесу: підписують, що приймають
- Go/No-go meeting з sponsor'ом: рішення, дата cutover, відповідальні на cutover
No-go — не кінець світу. Краще зачекати, ніж стартувати на блокерах.
Контекст: чому ця фаза критична
UAT — останній момент, коли провал ще можна спіймати, поки він не став катастрофою. Будь-яка помилка, що прослизне крізь UAT, потрапляє у production і коштує мінімум удесятеро дорожче. Тому UAT — не «формальність», а структурована, задокументована й відтворювана перевірка.
Тижні 1-2: написання сценаріїв і перше виконання
Сценарії пишуть бізнес-власники процесів — не розробники. Бо саме бізнес знає, як насправді минає робочий день бухгалтера чи майстра. Розробник напише «закупка → М-4 → ПН», але пропустить «о, а ще ми завжди звіряємось із випискою з ЄРПН перед оплатою».
Тиждень 3: defect fixing і регресія
Severity-1 і 2 — виправляються одразу. Severity-3 — у плані до Go-live. Severity-4 — можуть піти в hypercare. Після кожного фіксу — regression test з підмножини найкритичніших сценаріїв.
Тиждень 4: performance, security, signoff
Performance — критичний для місячного закриття і генерації пачки ПН. Security — для аудиту. Signoff — юридичний документ.
Пастка: не починайте UAT, поки не закрили severity-1 з попередньої кастомізації. Інакше тестери знайдуть ті ж баги вдруге, і ваша статистика стане непрозорою.
Пастка: рішення Go/No-go не ухвалює консультант або PM. Його ухвалює sponsor. Sponsor може сказати «йдемо з блокером» — це його право, але й рішення це його, з підписом.
Пастка для defense: оборонні сценарії тестуйте на людях з допуском. Якщо тестер без допуску — він не побачить половини полів, і ваш тест буде неповним.
Результати фази (deliverables)
- UAT-сценарії (мінімум 30) з кроками і очікуваними результатами
- Defect log з severity і статусом виправлення
- Regression test pack для повторного запуску після фіксів
- Performance test report
- Go/No-go decision document з підписами