UAT - User Acceptance Test

Đây là bước nghiệm thu tiêu chuẩn mà dự án phần mềm nào cũng có. Tuy nhiên cách tiến hành thường sơ sài và tùy theo hiểu biết của từng PM, thậm chí của từng tester. Bài viết này tổng kết những điểm cốt yếu để có một UAT hiệu quả và cách xử lý kết quả nghiệm thu.

Mục tiêu của UAT

Đây là phép test giúp công ty hoặc khách hàng xác nhận rằng sản phẩm, dịch vụ chạy được cho người sử dụng, cụ thể là:

• Xác nhận sản phẩm, dịch vụ, quy trình tạo ra chạy đúng như mong đợi trong môi trường thật.
• Liệt kê những vấn đề còn tồn đọng cần xử lý để xác nhận dự án hoàn thành.

UAT phải giả lập các điều kiện thực tế, nên khi một tính năng đã hoạt động thì mọi người tự tin hơn về việc sản phẩm sẽ chạy ổn khi go live. Nó cho phép đội dự án thu thập thông tin chi tiết hơn về cách người dùng tương tác với sản phẩm, và giúp trả lời những câu hỏi ngoài phần thiết kế tính năng, như:

• User có nhận ra tính năng và dùng chúng không?
• Họ tương tác với tính năng như thế nào?
• User mất bao nhiêu thời gian để thao tác?
• Họ có nắm bắt hết tính năng không?
• Sản phẩm có tiếp cận được tất cả mọi người không?

UAT còn dùng để thu thập trải nghiệm của user với sản phẩm, qua đó đội dự án nắm được những cảm xúc sản phẩm tạo ra, thông điệp nó truyền tải và diện mạo nó đang thể hiện…

Phương thức làm UAT tốt nhất

Để đạt các mục tiêu trên, UAT phải được tiến hành cẩn trọng, chu đáo. Các thực hành sau sẽ giúp bạn thực hiện một UAT hiệu quả.

Định nghĩa và ghi lại Acceptance Criteria

AC là những tiêu chuẩn hay yêu cầu đặt ra trước cho sản phẩm. Hãy ghi lại các yêu cầu này cho những mục bạn muốn test.

Ví dụ, nếu dự án có tính năng tạo sổ tay nhân viên thì tiêu chuẩn nghiệm thu là sổ tay phải là file PDF, truy cập được bằng điện thoại hay máy tính.

Tạo test case cho mỗi mục cần test

Một test case là một chuỗi các bước kèm kết quả mong đợi sau từng bước. Nó thường gồm một loạt thao tác user có thể làm để xác nhận sản phẩm hoạt động đúng như kỳ vọng.

Cũng theo ví dụ trên, sẽ có một test case: user bấm vào sổ tay thì truy cập được mà không gặp lỗi nào.

Lựa chọn user cẩn thận

Phải là những người sau này thực sự dùng sản phẩm.

Viết kịch bản UAT dựa trên user story

Kịch bản này được giao cho user trong khi test. User story là một lời giải thích không chính thức, chung chung cho một tính năng, viết theo góc nhìn của user. Cũng ở ví dụ trên, một user story là: là một nhân viên mới, tôi muốn dùng sổ tay để dễ dàng tìm chính sách nghỉ phép và chia sẻ cho mọi người qua mail.

Trao đổi với user trước và cho họ biết cần trông đợi gì

Nếu bạn có cơ hội làm việc với user từ trước thì chắc chắn sẽ bớt câu hỏi, vấn đề hay sự trì trệ trong quá trình UAT.

Chuẩn bị trước môi trường test cho UAT

Phải test thử môi trường này trước và cung cấp đầy đủ thông tin, quyền truy cập cho user.

Cung cấp hướng dẫn từng bước để giúp user đi qua quá trình test

Hướng dẫn rõ ràng, dễ theo giúp user tập trung chú ý vào đúng chỗ cần thiết. Bạn có thể soạn hướng dẫn này và gửi mọi người từ trước.

Ghi lại các thông tin phát sinh và thu thập mọi issue được phát hiện

Dùng Excel hay gì cũng được, nhưng giờ thường dùng các hệ thống bug tracking hơn. Quan trọng là nó phân loại được issue nằm ở đâu, kèm ý kiến của user về mức độ ưu tiên. Điều này giúp đội dự án sắp xếp xử lý cái nào trước, cái nào sau.

Quản lý kết quả UAT

User cung cấp phản hồi khi thực hiện UAT, nói chung rất đa dạng, từ tích cực tới tiêu cực, có cả đúng lẫn sai, gồm comment, bug report, change request… Cho nên đội dự án cần phân tích liên tục và quản lý danh sách, chỉ giữ lại hai thứ:

• Bug/Issue: có thể là vấn đề kỹ thuật hay vấn đề khác, bạn theo dõi trên hệ thống và xếp ưu tiên cao để xử lý.
• Change request: là các ý tưởng, đề xuất cải tiến xuất hiện sau khi sử dụng tính năng. Bạn cũng cần quản lý và xếp ưu tiên cho chúng. Việc này có thể cần phê duyệt từ stakeholder và có thể phải điều chỉnh project timeline để hoàn thành.

Lời cuối

UAT là công cụ đắc lực để đảm bảo đầu ra của dự án đúng yêu cầu và thành công. PM nhớ dành thời gian cho UAT và cả thời gian để giải quyết phát sinh.