# UAT — Kế hoạch & kết quả — <PROJECT / Đợt phát hành>

| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <BA> (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 | ☐ |