6.0 KiB
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.