Một nhóm đã từng cung cấp một hệ thống chi phí vượt qua mọi bài kiểm tra kỹ thuật. Vào ngày đầu tiên, nhóm tài chính phát hiện ra rằng họ không thể xử lý các yêu cầu bồi thường bằng nhiều loại tiền tệ, vốn chiếm phần lớn công việc của họ. Không có gì bị “hỏng”, nhưng nó không thể sử dụng được. Thử nghiệm chấp nhận của người dùng tồn tại để nắm bắt chính xác loại khoảng trống đó trước khi ra mắt.

Hướng dẫn này trình bày UAT khác với các thử nghiệm khác như thế nào, cách chạy từng bước và cách quyết định khi nào bạn sẵn sàng phát hành. Tình huống trên và các ví dụ dưới đây chỉ mang tính minh họa và quy trình này phải được điều chỉnh theo tỷ lệ cho phù hợp với dự án của bạn.

UAT là gì?

UAT thường là giai đoạn thử nghiệm cuối cùng trước khi phát hành, trong đó người dùng dự định xác nhận rằng phần mềm có thể thực hiện công việc của họ trong điều kiện thực tế. Nó còn được gọi là thử nghiệm người dùng cuối hoặc thử nghiệm chấp nhận. Nó xuất hiện sau quá trình phát triển và thử nghiệm hệ thống, khi sản phẩm được kỳ vọng sẽ ổn định.

Mục đích của nó không phải là tìm ra mọi lỗi. Đến giai đoạn này, hầu hết những thứ đó đã biến mất. Mục đích là xác nhận: chúng ta đã xây dựng đúng thứ chưa? Người kiểm tra xác minh rằng sản phẩm phù hợp với đặc điểm kỹ thuật. UAT xác nhận rằng đặc điểm kỹ thuật và sản phẩm thực sự đáp ứng được nhu cầu.

Kiểm tra UAT và QA

UAT không thay thế các thử nghiệm khác. Nếu người dùng tiếp tục gặp phải các lỗi cơ bản thì bản dựng chưa sẵn sàng và bạn đang lãng phí thời gian có hạn của họ. Những vấn đề đó thuộc về các cấp độ kiểm tra trước đó và thử nghiệm hồi quy.

Ai điều hành UAT?

Chọn những người thử nghiệm thực sự làm việc ngay hôm nay. Người xử lý khiếu nại có kinh nghiệm sẽ phát hiện ra các vấn đề mà người quản lý hoặc người được ủy quyền không bao giờ gặp phải. Bao gồm nhiều kinh nghiệm, bởi vì một nhân viên mới thường tiết lộ những bước khó hiểu mà một chuyên gia làm việc mà không để ý. Và hãy đảm bảo rằng người quản lý của họ dành thời gian cho việc này, vì UAT không thể thành công khi khối lượng công việc đầy ắp.

Các loại UAT

Quy trình UAT bảy bước

1. Xác định phạm vi và mục tiêu

Quyết định những gì đang được chấp nhận, những gì nằm ngoài phạm vi và những kết quả kinh doanh nào là quan trọng. Ví dụ: “Nhân viên tài chính có thể gửi, phê duyệt và thanh toán yêu cầu chi phí bằng bất kỳ loại tiền tệ nào được hỗ trợ.”

2. Thống nhất tiêu chí chấp nhận

Viết ra bằng ngôn ngữ đơn giản về thành công trông như thế nào, lý tưởng nhất là vào thời điểm bắt đầu dự án thay vì một tuần trước khi khởi động. Tiêu chí mơ hồ dẫn đến tranh luận sau này.

3. Chọn và tóm tắt người thử nghiệm

Chọn người dùng thực sự, giải thích mục đích, chỉ cho họ cách ghi lại phản hồi và nói rõ rằng họ đang thử nghiệm phần mềm chứ không phải tự mình thử nghiệm. Nhiều người lo lắng về việc có điều gì đó không ổn.

4. Chuẩn bị môi trường và dữ liệu

Môi trường UAT phải giống với môi trường sản xuất nhất có thể trong thực tế. Sử dụng dữ liệu thực tế, thiết lập vai trò người dùng chính xác và kiểm tra các tiện ích tích hợp như email. Nếu bạn sao chép dữ liệu sản xuất, trước tiên hãy che giấu thông tin cá nhân. Chạy thử nghiệm khói nhanh chóng để người kiểm tra không đến và phát hiện bản dựng bị hỏng.

5. Viết kịch bản

Dựa trên những quy trình công việc thực tế hơn là các nút riêng lẻ. Họ nên đọc như công việc chứ không phải như phần mềm. Hướng dẫn của chúng tôi về trường hợp kiểm thử và kịch bản kiểm thử giải thích mức độ chi tiết bạn cần.

6. Chạy thử nghiệm và thu thập phản hồi

Chạy các phiên với người sẵn sàng trợ giúp. Thu thập các vấn đề ở một nơi bằng ảnh chụp màn hình. Hãy dành chút thời gian để khám phá miễn phí vì mọi người sẽ thử những thứ mà kịch bản không bao giờ lường trước được. Thử nghiệm thăm dò cung cấp các kỹ thuật hữu ích cho việc này.

7. Sửa lỗi, kiểm tra lại và ký duyệt

Phân loại phản hồi, khắc phục những vấn đề quan trọng và yêu cầu những người dùng tương tự xác nhận các bản sửa lỗi. Sau đó ghi lại một quyết định chính thức.

Một trường hợp thử nghiệm UAT

Trường hợp thử nghiệm UAT phải dễ dàng cho những người không có chuyên môn về kỹ thuật theo dõi. Dưới đây là một ví dụ về hệ thống chi phí:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Lưu ý rằng nó mô tả một nhiệm vụ thực tế chứ không phải các chi tiết kỹ thuật và có chỗ cho các nhận xét. Những nhận xét đó thường trở thành phần có giá trị nhất, chẳng hạn như “cái này hoạt động được, nhưng tôi sẽ không bao giờ tìm thấy nút đó”.

Tiêu chí vào và ra

Những điều này phù hợp với vòng đời kiểm thử phần mềm rộng hơn. Đặt trước các con số với các bên liên quan của bạn. “Chúng tôi sẽ quyết định khi nào thấy phù hợp” có xu hướng dẫn đến sự đồng ý vội vàng do bị thúc đẩy bởi thời hạn.

Xử lý phản hồi

Phản hồi UAT là sự kết hợp của nhiều thứ và không phải tất cả đều là lỗi. Sắp xếp nó thành các loại:

Sử dụng các quy tắc rõ ràng về những gì ngăn chặn một bản phát hành, như được mô tả trong mức độ nghiêm trọng so với mức độ ưu tiên. Và trả lời mọi mục, kể cả những mục bạn từ chối. Mọi người ngừng đưa ra phản hồi nếu nó dường như biến mất. Hướng dẫn của chúng tôi về cách viết báo cáo lỗi có thể giúp người kiểm tra mô tả vấn đề một cách rõ ràng.

Danh sách kiểm tra UAT

Trước UAT

• Phạm vi và tiêu chí chấp nhận được thỏa thuận bằng văn bản
• Kiểm tra hệ thống và hồi quy đã hoàn tất
• Người thử nghiệm được lựa chọn, thông báo ngắn gọn và cho thời gian
• Môi trường, tài khoản và dữ liệu thực tế đã sẵn sàng
• Dữ liệu cá nhân trong các bản sao đã bị che giấu
• Các kịch bản được doanh nghiệp xem xét
• Một nơi để ghi lại các vấn đề được thiết lập
• Chủ sở hữu đăng xuất được đặt tên

Trong UAT

• Một liên hệ hỗ trợ có sẵn
• Các vấn đề được xử lý mỗi ngày
• Tiến độ được chia sẻ với các bên liên quan
• Các bản sửa lỗi được triển khai và kiểm tra lại một cách có kiểm soát

Sau UAT

• Tiêu chí thoát đã được kiểm tra
• Các vấn đề đã biết được ghi lại, với chủ sở hữu
• Việc phê duyệt chính thức được ghi lại
• Ghi chú đào tạo và phát hành được cập nhật
• Một cuộc hồi tưởng ngắn đã được tổ chức

UAT trong nhóm Agile

UAT truyền thống xuất hiện như một giai đoạn lớn ở cuối, nơi gây bất ngờ sẽ tốn kém. Các đội linh hoạt rút ngắn vòng lặp đó. Chủ sở hữu sản phẩm xem xét từng câu chuyện theo tiêu chí chấp nhận của nó trong giai đoạn chạy nước rút và người dùng sẽ thấy phần mềm đang hoạt động trong các buổi đánh giá chạy nước rút. Nhiều nhóm vẫn chạy UAT tập trung trước khi phát hành chính, đặc biệt khi một số tính năng kết hợp thành một quy trình làm việc.

Với các bản phát hành thường xuyên, các kỹ thuật như cờ tính năng và triển khai canary cho phép người dùng thực sự thử tác phẩm mới dần dần. Lưu ý rằng những thử nghiệm chấp nhận này bổ sung nhưng chúng không tự động thay thế nó, đặc biệt là trong các ngành được quản lý cần hồ sơ chính thức.

Những lỗi thường gặp

• Coi nó như một hình thức. Việc đăng xuất mà không có mục đích sử dụng thực sự sẽ bảo vệ không ai.
• Sử dụng sai người kiểm tra. Nhà phát triển và QA có quá nhiều kiến ​​thức về hệ thống để đại diện cho người dùng.
• Bắt đầu với bản dựng không ổn định. Người thử nghiệm nhanh chóng mất niềm tin và sự quan tâm.
• Hãy để nó đến phút cuối cùng. Khi đó sẽ không có thời gian để sửa những gì bạn đã học.
• Sử dụng dữ liệu không thực tế. Dữ liệu thử nghiệm hiếm khi có những trường hợp lộn xộn như công việc thực tế.
• Để phạm vi phát triển. Hãy coi những ý tưởng mới như những yêu cầu thay đổi, trừ khi chúng thực sự là những trở ngại.

Lời kết

UAT là cơ hội cuối cùng để bạn tìm hiểu, trước khi phát hành, liệu phần mềm có thực sự giúp ích cho những người sẽ sử dụng nó hay không. Lập kế hoạch ngay từ khi bắt đầu dự án, tuyển dụng người dùng thực và thống nhất về mức độ thành công. Đối với bản phát hành tiếp theo của bạn, hãy thử một thay đổi đơn giản: ngồi cùng một người dùng trong một tình huống thực tế và không nói gì trong khi họ làm việc.

Câu hỏi thường gặp

Tiếp tục học hỏi