Product Management
Đăng nhập
ESC

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

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

UAT Coordination

Delivery

Lên kế hoạch và điều phối User Acceptance Testing để feature ship đúng yêu cầu business.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Delivery cho PM/PO — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Delivery, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

UAT là bước kiểm thử cuối do NGƯỜI DÙNG NGHIỆP VỤ làm, để xác nhận sản phẩm dùng được trong công việc thật — không phải để kiểm tra nó khớp spec (đó là việc của QA). Hai thứ này bị nhầm liên tục, và hậu quả là UAT biến thành một vòng QA thứ hai.

Khi đã làm được

Chạy được một đợt UAT không rơi vào tranh cãi vô tận: tiêu chí pass/fail viết trước, chọn người kiểm theo luồng công việc chứ không theo ai rảnh, dữ liệu staging giống thật, và phân loại lỗi rõ ràng để biết cái nào chặn go-live.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/15 mục · còn khoảng 5 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

UAT Coordination là gì?

UAT (User Acceptance Testing) là bước kiểm thử cuối cùng do người dùng nghiệp vụ — hoặc người đại diện họ — thực hiện trước khi go-live.

Câu hỏi UAT trả lời không phải “có đúng spec không” mà “dùng được trong công việc thật không”. Spec có thể đúng và sản phẩm vẫn không dùng được.

Khi nào bạn gặp chuyện này

Tình huốngBạn làm gìNếu không
Đến ngày UAT, người được cử đi kiểm là người đang rảnh nhất phòng.Chọn theo LUỒNG: mỗi luồng công việc cần một người thật sự làm luồng đó hằng ngày.Họ bấm qua màn hình, ký chấp nhận, và lỗi thật xuất hiện trong tuần đầu go-live.
UAT phát hiện 40 lỗi, hai bên cãi nhau cái nào chặn go-live.Tiêu chí pass/fail và thang S1–S4 phải viết TRƯỚC khi bắt đầu kiểm.Tranh cãi kéo hai tuần, và quyết định cuối cùng phụ thuộc ai chịu áp lực nhiều hơn.
Staging dùng dữ liệu giả, mọi thứ chạy mượt.Nạp dữ liệu giống thật — khách hàng thật đã ẩn danh, đơn hàng có lịch sử.Lỗi chỉ xuất hiện với dữ liệu thật lọt thẳng ra production.

Khi nào cần UAT

  • Project enterprise có contract — UAT sign-off là milestone thanh toán.
  • Workflow phức tạp đa department (vd: HR system rollout).
  • Regulatory feature (vd: tax, accounting).

UAT vs QA

QAUAT
Mục tiêuVerify specValidate fit-for-purpose
TesterQA engineerBusiness user / proxy
Test caseDetailed, technicalWorkflow-based, business scenario
Khi nàoTrong sprintSau staging deploy, trước go-live

UAT artifact

  1. UAT plan — scope, schedule, criteria pass/fail, resource.
  2. Test scenarios — workflow-level (không test page-level).
  3. UAT environment — staging với data realistic.
  4. Defect log — track issue, severity (S1–S4), status.
  5. Sign-off document — business user xác nhận accept.

Lộ trình điều phối

  1. Recruit 5–8 business user → train trên platform 1 buổi.
  2. Demo + walkthrough scenario.
  3. 1 tuần execution — daily standup 15p để clear blocker.
  4. Triage defect: S1/S2 block go-live, S3/S4 fix post-launch.
  5. Sign-off → go-live plan.

Tiêu chí pass/fail — chốt trước khi bắt đầu

MứcNghĩa làChặn go-live?
S1Không hoàn thành được luồng công việc chínhCó
S2Hoàn thành được nhưng sai dữ liệu hoặc mất dữ liệuCó
S3Có cách đi vòng chấp nhận đượcKhông — sửa sau go-live
S4Khó chịu, không chặn việc gìKhông

Sai lầm thường gặp

Sai lầmVì sao hỏngLàm thay bằng
Chọn người kiểm theo độ rảnhHọ không biết luồng thật nên không phát hiện được gì.Chọn theo luồng công việc.
Không có tiêu chí pass/failMọi lỗi thành chủ đề tranh cãi.Viết tiêu chí và thang mức trước.
Dữ liệu staging giảLỗi chỉ xuất hiện với dữ liệu thật.Dữ liệu thật đã ẩn danh.
Coi UAT là vòng QA thứ haiBạn kiểm lại spec thay vì kiểm tính dùng được.Kịch bản theo luồng công việc, không theo màn hình.

Vì sao vai trò của bạn cần cái này

Vai tròBạn dùng nó để
Business AnalystBạn thường là người viết kịch bản và điều phối cả đợt — đây là kỹ năng trung tâm.
Product OwnerBạn ký chấp nhận, nên tiêu chí phải là của bạn.
Product ManagerVới hợp đồng doanh nghiệp, sign-off UAT là mốc thanh toán — nó là việc thương mại, không chỉ kỹ thuật.
QABạn chuẩn bị môi trường và dữ liệu; kịch bản thì không.

Definition of done — dấu hiệu bạn đã đạt

  • Tiêu chí pass/fail viết trước khi bắt đầu kiểm.
  • Mỗi luồng công việc có một người thật sự làm luồng đó tham gia.
  • Dữ liệu staging giống thật.
  • Mỗi lỗi có mức S1–S4 và luật chặn go-live rõ ràng.

UAT thất bại ở đâu — và nó hiếm khi là lỗi của người kiểm

Cách hỏngBiểu hiệnNguyên nhân gốc
Người kiểm không biết kiểm gì"Anh chị dùng thử xem có gì lạ không"Không có kịch bản; UAT không phải dùng thử tự do
Chỉ kiểm đường thuậnLỗi ca ngoại lệ ra tới môi trường thậtKịch bản viết theo mô tả tính năng, không theo công việc thật
Kiểm vào tuần cuốiTìm ra lỗi lớn khi không còn thời gian sửaUAT bị coi là khâu nghiệm thu, không phải khâu phát hiện
Người kiểm không phải người dùng thậtQuản lý kiểm thay nhân viênQuản lý biết quy trình trên giấy; nhân viên biết quy trình thật
Dữ liệu kiểm quá sạchChạy tốt lúc UAT, hỏng với dữ liệu thậtDữ liệu mẫu do đội tự tạo

Dòng thứ tư là dòng gây hậu quả nặng nhất. Quản lý ký nghiệm thu cho một quy trình mà họ không trực tiếp làm — và nhân viên phát hiện vấn đề vào ngày đầu tiên chạy thật, khi đã không còn đường lùi.

Chuẩn bị UAT — bốn việc trước khi mời ai đó vào kiểm

  • Viết kịch bản theo CÔNG VIỆC, không theo tính năng. Không phải "kiểm màn hình tạo đơn"; mà "anh/chị hãy tạo đơn cho khách hàng gọi điện đặt 3 mặt hàng, trong đó một mặt hàng đã hết tồn kho".
  • Gồm ca ngoại lệ trong kịch bản — huỷ giữa chừng, dữ liệu thiếu, người dùng không có quyền. Đây là nơi phần lớn lỗi thật nằm.
  • Dùng dữ liệu thật đã ẩn danh, không dùng dữ liệu mẫu do đội tạo. Dữ liệu thật có tên dài, ký tự lạ, giá trị bất thường.
  • Chọn đúng người: người làm việc đó hằng ngày. Ít nhất một người mới vào nghề và một người lâu năm — họ tìm ra hai loại lỗi khác nhau.

Về thời điểm: UAT nên bắt đầu khi còn đủ thời gian sửa, không phải khi đã sẵn sàng phát hành. Một quy tắc thực tế: dành ít nhất một phần ba thời gian còn lại cho việc sửa sau UAT.

Trong buổi UAT — cách quan sát

Đừng làmHãy làmVì sao
Hướng dẫn khi họ lúng túngIm lặng và ghi lại chỗ lúng túngSự lúng túng chính là dữ liệu bạn đến để lấy
Hỏi "có dễ dùng không"Hỏi "anh/chị đang mong chuyện gì xảy ra"Câu đầu chỉ nhận về lời lịch sự
Ghi "người dùng không hiểu"Ghi đúng điều họ nói và điều họ làmDiễn giải sớm làm mất thông tin gốc
Sửa ngay tại chỗGhi lại, xử lý theo nhóm sauSửa vội trong lúc UAT tạo ra lỗi mới không ai kiểm

Phân loại lỗi tìm được thành ba nhóm trước khi bàn: chặn phát hành, sửa trước khi ra mắt, và ghi nhận để sau. Không phân loại thì mọi lỗi đều trở thành khẩn cấp và không ai quyết được gì.

Vì sao vai trò của bạn cần cái này

Vai tròBạn dùng nó để
Business AnalystKịch bản UAT theo công việc thật là sản phẩm của bạn
Product OwnerBạn bảo vệ thời gian sửa sau UAT, và bạn phân loại lỗi
QAUAT bổ sung cho kiểm thử của bạn, không thay thế nó
Team LeadBạn đảm bảo dữ liệu kiểm là dữ liệu thật đã ẩn danh
Người dùng nghiệp vụBạn là người duy nhất biết quy trình thật khác quy trình trên giấy ra sao

Definition of done

  • Kịch bản viết theo công việc thật, không theo danh sách tính năng.
  • Có ca ngoại lệ trong kịch bản.
  • Dữ liệu kiểm là dữ liệu thật đã ẩn danh.
  • Người kiểm là người làm việc đó hằng ngày, không phải quản lý của họ.
  • UAT bắt đầu khi còn ít nhất một phần ba thời gian để sửa.
  • Lỗi được phân loại ba nhóm trước khi bàn cách xử lý.

Tự kiểm 3 câu

Đọc xong rồi thì thử xem — đúng cả ba là đạt.
1. Phòng nghiệp vụ cử trưởng phòng đi kiểm UAT thay cho nhân viên vì nhân viên đang bận. Rủi ro là gì?
2. UAT tìm ra 40 lỗi và hai bên tranh cãi lỗi nào chặn go-live. Lẽ ra phải làm gì để tránh việc này?
3. Trong buổi UAT, người kiểm lúng túng ở một màn hình. Bạn nên làm gì?

Khóa học liên quan (3)

Quality Assurance
Software Testing Fundamentals
Quality Assurance
Test Strategy and QA Leadership
Chuyển đổi nghề nghiệp
Từ QA/Tester sang BA: Lộ Trình Chuyển Đổi

Sử dụng trong vai trò

Business Analyst Entry Product Owner Mid

Thảo luận & tài liệu thêm 0

Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.

Hãy là người đầu tiên chia sẻ kinh nghiệm cho kỹ năng này.

Kiểm tra kỹ năng này

Bài kiểm tra của các khóa dạy kỹ năng này
1 Quiz

Kiểm tra: QA/Tester sang BA

Bài kiểm tra của một khóa dạy kỹ năng này.

1 người đã làm
Làm bài này
2 Quiz

QA Fundamentals Quiz

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này
3 Quiz

QA Leadership Quiz

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này

Học kỹ năng này ở đâu?

Có 3 khóa dạy đúng phần này, miễn phí và bằng tiếng Việt.

Bắt đầu học