UAT — Kế hoạch & kết quả — <PROJECT / Đợt phát hành>
|
|
| Version |
1.0 |
| Date |
YYYY-MM-DD |
| Author |
(skill ba-4-delivery-support) |
| Status |
🟡 Kế hoạch / 🟠 Đang chạy / ✅ Hoàn thành |
| Approved by |
PO: — |
| Phạm vi |
US-011, US-012, US-013 |
PHẦN A — KẾ HOẠCH (hoàn thành trước ngày UAT ít nhất 1 tuần)
A1. Tiêu chí pass — chốt TRƯỚC khi bắt đầu
🔴 Chốt sau khi đã thấy kết quả thì không còn là tiêu chí. Mục này phải có chữ ký của PO
trước buổi UAT đầu tiên.
| # |
Tiêu chí |
Ngưỡng |
| 1 |
Kịch bản mức Must pass |
100% |
| 2 |
Kịch bản mức Should pass |
≥ 90% |
| 3 |
Defect Critical/High còn mở |
0 |
| 4 |
Defect Medium còn mở |
Có kế hoạch xử lý + ticket |
| 5 |
|
|
|
|
| PO xác nhận tiêu chí |
☐ — ngày… |
A2. Người tham gia
| Vai trò |
Tên |
Là người dùng thật? |
Kịch bản phụ trách |
Đã có tài khoản |
|
|
✅/❌ |
S1, S2 |
☐ |
🔴 Phải là người sẽ dùng thật, không phải người đại diện. Người đại diện pass rồi người
dùng thật từ chối là kịch bản hỏng dự án ở phút chót.
A3. Môi trường
|
|
| Môi trường |
|
| Đường dẫn |
|
| Phiên bản triển khai |
|
| Truy cập từ đâu (VPN? máy nội bộ?) |
|
| Hệ thống ngoài: thật hay giả lập |
|
| Ai hỗ trợ kỹ thuật tại chỗ |
|
Tài khoản:
| Tài khoản |
Vai trò |
Phạm vi dữ liệu |
Đã cấp |
Đã đăng nhập thử |
|
|
|
☐ |
☐ |
Chưa đăng nhập thử trước ngày UAT là lý do phổ biến khiến buổi UAT mất một tiếng đầu.
A4. Dữ liệu chuẩn bị
| Loại dữ liệu |
Số lượng |
Đặc điểm |
Đã chuẩn bị |
| Bản ghi bình thường |
|
|
☐ |
| Bản ghi ở giá trị biên |
|
Dài nhất, ngắn nhất, số lớn nhất |
☐ |
| Bản ghi ca ngoại lệ |
|
Theo bảng A5 của PROCESS |
☐ |
| Bản ghi cũ |
|
Tạo trước khi có tính năng này, thiếu trường mới |
☐ |
| Dữ liệu bẩn |
|
Thiếu trường, sai định dạng, trùng |
☐ |
🔴 Dữ liệu quá sạch ⇒ UAT pass, chạy thật thì lỗi. Dữ liệu thật luôn có bản ghi thiếu
trường, trùng, sai định dạng, tạo từ nhiều năm trước. Không đưa chúng vào UAT thì UAT không
chứng minh được gì.
A5. Kịch bản
Viết theo luồng công việc thật, không theo màn hình. Kịch bản viết theo màn hình thì
người dùng không nhận ra công việc của mình trong đó.
S1 — <Tên công việc theo cách người dùng gọi>
|
|
| Mức |
Must / Should / Could |
| Vai trò thực hiện |
|
| AC liên quan |
AC-01, AC-03 |
| Dữ liệu cần |
|
| Thời gian dự kiến |
|
| # |
Bước |
Người dùng làm gì |
Kết quả mong đợi |
| 1 |
|
|
|
| 2 |
|
|
|
Coi là pass khi: …
PHẦN B — KẾT QUẢ
B1. Tổng hợp kịch bản
| Kịch bản |
Mức |
Người chạy |
Ngày |
Kết quả |
Phát hiện |
| S1 |
Must |
|
|
✅ Pass / ❌ Fail / ⏭ Chưa chạy |
P-001 |
|
|
| Must: pass … / … (…%) |
|
| Should: pass … / … (…%) |
|
B2. Phát hiện
| ID |
Kịch bản |
Bước |
Mong đợi |
Thực tế |
Ảnh |
Phân loại |
Mức |
Trạng thái |
| P-001 |
S1 |
3 |
|
|
|
Defect |
High |
Mở |
| P-002 |
S2 |
1 |
|
|
|
Hiểu nhầm cách dùng |
— |
→ đào tạo |
Ba loại phát hiện — phân loại đúng ngay tại chỗ:
| Loại |
Nghĩa |
Xử lý |
| Defect |
Sản phẩm không đúng SRS đã ký |
Dev sửa |
| Change Request |
Sản phẩm đúng SRS, khách muốn khác |
→ phiếu CR-nnn |
| Hiểu nhầm cách dùng |
Sản phẩm đúng, người dùng không tìm ra/hiểu sai |
→ đào tạo hoặc cải thiện thiết kế |
🔴 Loại thứ ba thường bị ghi nhầm thành defect. Nó là tín hiệu quý về đào tạo hoặc về thiết
kế chưa rõ — ghi riêng và xử lý ở GĐ5, đừng để lẫn vào danh sách bug.
Mức defect:
| Mức |
Định nghĩa |
| Critical |
Chặn hoàn toàn nghiệp vụ, hoặc sai lệch dữ liệu/tiền |
| High |
Nghiệp vụ chính không hoàn thành được, có cách vòng nhưng tốn kém |
| Medium |
Gây bất tiện, có cách vòng chấp nhận được |
| Low |
Thẩm mỹ, chính tả, không ảnh hưởng nghiệp vụ |
B3. Quan sát trong lúc UAT
BA là người quan sát và ghi chép, không phải người hướng dẫn thao tác. Chỗ người dùng
loay hoay là thông tin quý nhất của buổi UAT — đừng cứu họ quá sớm.
| # |
Quan sát |
Ở đâu |
Ý nghĩa |
Đề xuất |
| 1 |
Người dùng tìm nút Lưu mất ~20 giây |
SCR-03 |
Vị trí nút không theo thói quen |
Xem lại bố cục |
B4. Defect chấp nhận tạm
| ID |
Mức |
Vì sao chấp nhận |
Ticket theo dõi |
Hạn xử lý |
Ai chịu trách nhiệm |
|
|
|
🔴 bắt buộc có |
|
|
🔴 Defect "chấp nhận tạm" mà không có ticket sẽ biến mất, và quay lại sau sáu tháng dưới
dạng khiếu nại của người dùng. Không có ticket ⇒ không được chấp nhận tạm.
B5. Change Request phát sinh
| CR |
Tóm tắt |
Quyết định |
Ảnh hưởng phát hành này |
B6. Kết luận Go / No-go
| Tiêu chí (từ A1) |
Ngưỡng |
Thực tế |
☐/✅ |
| Kịch bản Must pass |
100% |
|
|
| Defect Critical/High mở |
0 |
|
|
|
|
| Kết luận |
✅ GO / 🔴 NO-GO / 🟠 GO có điều kiện |
| Điều kiện kèm theo |
|
| Người quyết |
PO — |
| Ngày |
|
| Chữ ký nghiệm thu |
|
"Không ai phản đối" không phải nghiệm thu. Nghiệm thu cần chữ ký và tiêu chí đã thoả thuận
trước ở §A1.
B7. Bàn giao sang GĐ5
| # |
Việc |
Ai |
Trạng thái |
| 1 |
Danh sách defect còn mở + ticket |
BA |
☐ |
| 2 |
Danh sách "hiểu nhầm cách dùng" → nội dung đào tạo |
BA |
☐ |
| 3 |
Baseline KPI trước go-live (để GĐ5 so sánh) |
BA |
☐ |
| 4 |
Chốt ngày đo hiệu quả |
BA + PO |
☐ |
