Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Chủ đề 8 · Thiết kế Test Case & UAT — Dựng kịch bản UAT theo góc nhìn người dùng

Bài 5 — Dựng kịch bản UAT theo góc nhìn người dùng

Vấn đề: test case kỹ thuật ≠ kịch bản UAT

Test case của QA thường rời rạc theo chức năng. Nhưng UAT là để người dùng nghiệp vụ xác nhận hệ thống làm được việc thật của họ, nên phải viết theo luồng công việc end-to-end, bằng ngôn ngữ nghiệp vụ, không phải thuật ngữ kỹ thuật. Một khách hàng không quan tâm "kiểm tra API trả 200", họ quan tâm "tôi có tạo được đơn hàng và xuất hóa đơn không".

Viết kịch bản UAT mượt, dễ hiểu, đúng ngữ cảnh người dùng cuối là việc tốn công. AI giúp bạn chuyển từ test case kỹ thuật sang kịch bản kể chuyện theo persona.

AI giúp gì ở bước UAT?

  • Nhóm các test case rời thành luồng nghiệp vụ liền mạch.
  • Viết lại bằng ngôn ngữ người dùng, theo persona (kế toán, thủ kho, quản lý).
  • Sinh kịch bản end-to-end "một ngày làm việc" của người dùng.
  • Tạo tiêu chí chấp nhận rõ ràng để khách hàng ký nghiệm thu.

Ví dụ cụ thể

Hệ thống bán hàng: bạn muốn kịch bản UAT cho persona "Nhân viên bán hàng Lan" thực hiện trọn vẹn quy trình từ tạo đơn đến in hóa đơn, gồm cả tình huống khách đổi ý giữa chừng.

Prompt mẫu dựng kịch bản UAT

Vai trò: chuyên gia UAT. Viết kịch bản UAT theo góc nhìn người dùng nghiệp vụ.
Bối cảnh persona:
  • Tên: Lan, Nhân viên bán hàng, không rành công nghệ.
  • Mục tiêu: tạo đơn, áp khuyến mãi, thu tiền, in hóa đơn.
Các chức năng đã có test case: [liệt kê ngắn]. Yêu cầu:
  • Viết 3-5 kịch bản UAT end-to-end, mỗi kịch bản gồm:
Tên kịch bản | Persona | Mục tiêu nghiệp vụ | Các bước (ngôn ngữ đời thường, đánh số) | Kết quả người dùng mong đợi | Tiêu chí chấp nhận (pass/fail).
  • Bao gồm ít nhất 1 kịch bản có tình huống ngoại lệ (khách hủy giữa chừng,
hết hàng, mất mạng tạm thời).
  • Dùng ngôn ngữ nghiệp vụ, TRÁNH thuật ngữ kỹ thuật (API, database).
  • Đánh dấu điểm cần người dùng xác nhận bằng mắt (giao diện, số tiền, hóa đơn).

Các bước thực hiện

  • Xác định persona chính và mục tiêu nghiệp vụ của họ.
  • Gom các test case liên quan thành luồng công việc thực tế.
  • Chạy prompt để AI viết kịch bản theo persona.
  • Đọc to kịch bản như thể bạn là người dùng — chỗ nào khó hiểu thì yêu cầu AI diễn đạt lại đơn giản hơn.
  • Thêm tiêu chí chấp nhận đo được (số tiền đúng, hóa đơn có đủ trường bắt buộc).
  • Gửi bản nháp cho 1 người dùng thật đọc thử trước buổi UAT.

Bí quyết: viết tiêu chí chấp nhận "đo được"

Tiêu chí mơ hồ như "hệ thống chạy ổn" gây tranh cãi khi ký nghiệm thu. Yêu cầu AI viết tiêu chí đo được: "Hóa đơn in ra hiển thị đúng tổng tiền = 450.000đ, có mã số thuế công ty, thời gian in trong vòng 5 giây." Rõ ràng thì dễ ký, dễ bảo vệ.

Template kịch bản UAT tái sử dụng

Kịch bản UAT #: ...
Persona: [Vai trò, đặc điểm]
Mục tiêu nghiệp vụ: ...
Tiền điều kiện: [tài khoản, dữ liệu sẵn có]
Các bước (ngôn ngữ người dùng):
  1. ...
  2. ...
Kết quả người dùng mong đợi: ...
Tiêu chí chấp nhận (đo được):
  - [ ] ...
  - [ ] ...
Tình huống ngoại lệ cần thử: ...
Người thực hiện: ____  Ngày: ____  Kết quả: Pass/Fail  Ghi chú: ____

Sai lầm thường gặp

  • Ảo giác quy trình: AI có thể bịa bước nghiệp vụ không tồn tại trong hệ thống của bạn (ví dụ "chọn kho xuất hàng" trong khi hệ thống không có tính năng đó). Đối chiếu từng bước với luồng thực tế.
  • Rò rỉ dữ liệu: Persona và kịch bản đôi khi được lấy từ khách hàng thật. Đừng đưa tên khách, số hợp đồng, thông tin dự án bí mật lên AI công cộng.
  • Phụ thuộc quá mức: Giao trọn UAT cho kịch bản AI mà không cho người dùng thật kiểm tra. AI không cảm nhận được sự "khó dùng" hay kỳ vọng ngầm của người dùng nội bộ. Kịch bản chỉ là bản nháp cần con người tinh chỉnh.
Kết bài: Kịch bản UAT đã sẵn sàng. Bài 6 sẽ biến toàn bộ điều này thành checklist nghiệm thu chuyên nghiệp để khách hàng ký duyệt.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi