99 lines
6.0 KiB
Markdown
99 lines
6.0 KiB
Markdown
# Ví dụ minh hoạ — `ba-4-delivery-support`
|
|
|
|
Tách khỏi `SKILL.md` để quy trình không lẫn ví dụ của một ngành cụ thể.
|
|
|
|
---
|
|
|
|
## Phần A · Bốn loại câu hỏi — phân loại rồi mới trả lời
|
|
|
|
| Dev/QA hỏi | Loại | Trả lời thế nào | Sửa tài liệu? |
|
|
|---|---|---|---|
|
|
| "Mã cửa hàng có phân biệt hoa thường không?" | 1 — spec đã nói | Trích `SRS_US011 §2.3.3 F01`: `^[A-Z0-9-]+$`, tự chuyển hoa khi nhập | ❌ |
|
|
| "AC-05 nói 'không cho lưu' — là chặn nút hay báo lỗi sau khi bấm?" | 2 — mơ hồ | Chốt: validate khi rời field, chặn nút khi form không hợp lệ | ✅ SRS v1.1 |
|
|
| "Bệnh nhân huỷ lịch trước 2 tiếng thì có hoàn phí không?" | 3 — spec không nói | Đi hỏi PO → `OQ-018` | ✅ sau khi có trả lời |
|
|
| "Spec nói giữ slot 10 phút nhưng nghiệp vụ bảo 5 phút" | 4 — spec sai | → `CR-004` | ✅ qua CR |
|
|
|
|
🔴 Ba loại sau đều phải sửa tài liệu. Trả lời cho một dev mà không sửa spec nghĩa là người
|
|
tiếp theo sẽ hỏi lại đúng câu đó.
|
|
|
|
### Một mục `QLOG` đủ tiêu chuẩn
|
|
|
|
```
|
|
Q-014 | 2026-09-03 | Dev A | Loại 2
|
|
Hỏi: "AC-05 nói 'không cho lưu' — chặn nút hay báo lỗi sau khi bấm?"
|
|
Trả lời: Validate khi rời field (blur). Nút Lưu disable khi còn field lỗi.
|
|
Bấm Lưu khi hợp lệ mà server từ chối ⇒ hiện lỗi, GIỮ NGUYÊN dữ liệu đã nhập.
|
|
Nguồn: Chốt với PO (chị Lan) 2026-09-03 → DEC-07
|
|
Hành động: ☐ SRS_US011 v1.0→v1.1 §2.3.4 ☐ Cập nhật RTM ☐ Báo Dev B, QA
|
|
```
|
|
|
|
Ba phần bắt buộc: **trích dẫn nguồn** · **câu trả lời dứt khoát** · **hành động kèm theo**.
|
|
|
|
---
|
|
|
|
## Phần B · Phép thử Defect / CR / Spec gap
|
|
|
|
Áp dụng **máy móc**, không theo cảm tính — cả hai bên đều có động cơ phân loại lệch.
|
|
|
|
| Tình huống | SRS nói gì | Kết luận | Ai chịu |
|
|
|---|---|---|---|
|
|
| Lưu thất bại thì form bị xoá trắng | `AC-09` nói rõ "giữ nguyên dữ liệu đã nhập" | **Defect** | Dev sửa, không tính phí |
|
|
| Khách muốn thêm cột "ngày cập nhật" vào bảng | §2.3.2 liệt kê 6 cột, không có cột này | **Change Request** | PO quyết |
|
|
| Hai người cùng sửa một bản ghi, người sau ghi đè người trước | 🔴 SRS **không nói gì** về đồng thời | **Spec gap** | BA — thiếu sót đặc tả |
|
|
| Job chạy lại tạo bút toán trùng | SRS không nói về idempotency | **Spec gap** | BA |
|
|
|
|
**Spec gap xử lý thẳng thắn:** ghi nhận là thiếu sót của đặc tả, đánh giá tác động như một
|
|
CR, nhưng nêu rõ nguyên nhân gốc trong `BENEFIT` ở GĐ5. Đừng đẩy sang khách như CR bình
|
|
thường, cũng đừng nhận là bug của dev.
|
|
|
|
Hai dòng cuối bảng là **cùng một lỗ hổng đặc tả** (không nghĩ tới đồng thời / chạy lại) ở hai
|
|
loại sản phẩm khác nhau — đó là kiểu bài học đáng ghi vào GĐ5.
|
|
|
|
---
|
|
|
|
## Phần B · Bước "làm rõ vấn đề gốc" cứu tiền
|
|
|
|
| Khách yêu cầu | Hỏi "để làm gì?" | Vấn đề gốc | Phương án rẻ hơn |
|
|
|---|---|---|---|
|
|
| "Thêm cột ngày cập nhật vào bảng" | Để tìm bản ghi mới sửa gần đây | Không lọc được theo thời gian | Thêm **bộ lọc** ngày, không thêm cột |
|
|
| "Cho xuất toàn bộ hồ sơ ra Excel" | Để gửi bác sĩ xem trước ca khám | Bác sĩ không truy cập được hệ thống lúc đi buồng | Cấp quyền xem trên mobile — và tránh được rủi ro lộ hồ sơ |
|
|
| "Chạy job đối soát mỗi giờ" | Vì sợ phát hiện lỗi muộn | Không có cảnh báo khi job đêm thất bại | Thêm **cảnh báo**, giữ nguyên lịch chạy đêm |
|
|
|
|
Cả ba: giải pháp đúng khác thứ khách yêu cầu, và rẻ hơn nhiều.
|
|
|
|
---
|
|
|
|
## Phần C · Bốn nhóm test case hay thiếu
|
|
|
|
| Nhóm | Câu hỏi kiểm tra | Ví dụ phát hiện thật |
|
|
|---|---|---|
|
|
| Phân quyền | Có test **gọi thẳng API** với token sai quyền không? | QA chỉ test ẩn nút trên UI; gọi thẳng API vẫn tạo được bản ghi |
|
|
| Lỗi hệ thống | Có test timeout và kiểm tra **dữ liệu đã nhập được giữ nguyên**? | Không ai test, và form xoá trắng lọt tới UAT |
|
|
| Đồng thời | Hai người sửa cùng bản ghi? Bản ghi bị xoá khi mình đang mở? | Không có test nào, và đây là spec gap phổ biến nhất |
|
|
| Dữ liệu cũ | Có test với bản ghi tạo **trước** khi có tính năng này? | Bản ghi cũ thiếu trường mới ⇒ màn hình chi tiết lỗi |
|
|
|
|
---
|
|
|
|
## Phần D · Kịch bản UAT viết theo công việc, không theo màn hình
|
|
|
|
| ❌ Theo màn hình | ✅ Theo công việc |
|
|
|---|---|
|
|
| "S1: Kiểm tra màn hình danh sách chênh lệch" | "S1: Đối soát doanh thu ngày hôm qua của 3 cửa hàng khu vực Hà Nội" |
|
|
| "S2: Kiểm tra form đặt lịch" | "S2: Bệnh nhân gọi điện xin đổi lịch khám sang buổi chiều cùng ngày" |
|
|
|
|
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 đó, và họ
|
|
sẽ thao tác theo hướng dẫn thay vì theo thói quen thật — làm mất giá trị của buổi UAT.
|
|
|
|
---
|
|
|
|
## Phần D · Ba loại phát hiện — loại thứ ba hay bị ghi nhầm
|
|
|
|
| Phát hiện tại UAT | Phân loại đúng | Xử lý |
|
|
|---|---|---|
|
|
| Bấm Lưu, mất kết nối, form trắng | **Defect** | Dev sửa |
|
|
| "Tôi muốn thấy cả tên cửa hàng, không chỉ mã" | **Change Request** | Phiếu CR, PO quyết |
|
|
| Người dùng tìm nút Lưu mất ~20 giây, cuối cùng phải hỏi | **Hiểu nhầm cách dùng** | → đào tạo **hoặc** xem lại vị trí nút |
|
|
|
|
Loại thứ ba thường bị ghi thành defect. Nó là tín hiệu quý về đào tạo hoặc thiết kế chưa rõ —
|
|
ghi riêng, và nó trở thành nguồn nội dung tốt nhất cho `MANUAL` ở GĐ5.
|