Những lỗi đáng xấu hổ nhất mà tôi từng để lọt lên production đều có chung một điểm: bộ kiểm thử lúc đó báo xanh hết. Mã chạy đúng y như bản đặc tả, chỉ có điều bản đặc tả lại không khớp với thứ người dùng thực sự cần. UAT sinh ra để lấp đúng khoảng trống đó.

Vì sao tôi không thể tự kiểm thử tính năng của mình

#

Đến lúc một tính năng làm xong, tôi đã đi qua luồng thao tác suôn sẻ (happy path) của nó cả trăm lần. Tôi biết phải bấm nút nào, vì chính tay tôi làm ra cái nút đó. Chính sự quen thuộc ấy khiến tôi thành người kiểm thử tệ nhất có thể. Nó cũng là lý do QA chỉ giải quyết được một nửa vấn đề, vì QA vẫn kiểm thử dựa trên bản đặc tả. UAT là giai đoạn duy nhất mà câu hỏi đổi từ “có chạy đúng như thiết kế không?” sang “thiết kế như vậy đã đúng chưa?”

UAT, QA và kiểm thử beta không phải là một

#

Nhiều người dùng lẫn lộn ba khái niệm này, và điều đó gây ra không ít nhầm lẫn về chuyện ai phải làm việc gì.

UAT nằm giữa hai giai đoạn kia. Nếu QA vẫn còn tìm ra lỗi làm ứng dụng sập (crash) thì vẫn còn quá sớm để làm UAT. Người dùng sẽ mất cả vòng kiểm thử để vấp hết lỗi này đến lỗi khác, và chẳng bao giờ đi được tới câu hỏi mà bạn thực sự muốn có câu trả lời.

Trước khi bắt đầu một vòng UAT

#

Việc đầu tiên là lên kế hoạch: phạm vi, tiến độ, ai tham gia, và thế nào thì được tính là “đạt”. Tiêu chí thành công mà mơ hồ thì vòng UAT sẽ cứ kéo dài hết tuần này sang tuần khác.

Tôi cũng đặt ra tiêu chí đầu vào (entry criteria). Tên nghe thì to tát, nhưng thực ra chỉ là một danh sách kiểm tra ngắn. QA đã đạt và không còn lỗi nghiêm trọng nào đang mở. Môi trường staging có dữ liệu trông giống thật, chứ không phải mấy tài khoản kiểu “test test 123”. Những người tham gia đã dành riêng thời gian trong lịch cho việc này, chứ không phải “lúc nào rảnh thì làm”. Điều cuối cùng là quan trọng nhất. UAT mà bị nhét vào giữa công việc chính của ai đó thì chỉ nhận được chừng mười phút chú tâm thật sự.

Tiếp theo là chọn những người giống với người dùng thật của bạn. Đồng nghiệp không dính dáng gì đến quá trình làm ra tính năng là lựa chọn tốt; một nhóm nhỏ các bên liên quan (stakeholder) ở bên ngoài, sẵn lòng hợp tác và hiểu sản phẩm làm ra để giải quyết việc gì, thì còn tốt hơn nữa. Với phần lớn tính năng, năm đến tám người là quá đủ. Đông hơn thế thì chủ yếu bạn chỉ nhận lại những góp ý trùng lặp.

Viết kịch bản sao cho người ta làm theo được

#

Hãy viết kịch bản xoay quanh công việc hằng ngày thay vì các trường hợp biên (edge case), vì QA đã xử kỹ mấy trường hợp đó rồi. Một kịch bản UAT tốt đọc lên giống một ngày thứ Ba bình thường như bao ngày khác, chứ không phải một bài kiểm thử áp lực (stress test).

Mỗi kịch bản có một mục tiêu và một điểm xuất phát, và cố ý không ghi các bước thực hiện. Nếu bạn viết “bấm New Invoice, rồi bấm Add Client”, thì thứ bạn đang kiểm tra là người ta có biết làm theo hướng dẫn hay không, chứ không phải sản phẩm có dễ hiểu hay không. Với một tính năng lập hoá đơn, kịch bản có thể trông như thế này:

Kịch bản 4: Lập hoá đơn cho khách hàng mới theo một phần công việc

Bạn vừa làm xong nửa đầu phần thi công hoàn thiện nội thất cho một khách hàng mới là Harbour Café. Hãy lập hoá đơn cho 50% của khoản $12,000 đã thoả thuận, hạn thanh toán trong 14 ngày, rồi gửi đến email kế toán của họ.

Kết quả mong đợi: khách hàng nhận được hoá đơn $6,000 với đúng hạn thanh toán, và hoá đơn hiện trạng thái chưa thanh toán trên trang tổng quan (dashboard) của bạn.

Thường thì mười đến mười lăm kịch bản kiểu này là đủ bao quát một tính năng. Tôi ngồi dự vài buổi đầu, nói càng ít càng tốt, và quan sát xem người ta ngập ngừng ở đâu. Một khoảnh khắc ngập ngừng trước khi bấm nút cho bạn biết nhiều hơn bất cứ điều gì được viết trong phiếu góp ý.

Ghi nhận góp ý UAT

#

Trong suốt vòng kiểm thử, bất cứ điều gì không khớp với mong đợi của người dùng đều được ghi lại, kể cả những chỗ về mặt kỹ thuật là “chạy đúng như thiết kế”. Nếu ai đó mong đợi một đằng mà nhận được một nẻo, thì đó vẫn là thông tin đáng giá, bất kể bản đặc tả nói gì.

Việc ghi nhận không cần công cụ gì đặc biệt. Một bảng tính dùng chung, hoặc một board riêng trong công cụ quản lý issue mà bạn đang dùng, là đủ, miễn là mục nào cũng có cùng vài trường thông tin sau:

“Điều tôi mong đợi” là trường quan trọng nhất. Thiếu nó, bạn sẽ nhận được những góp ý kiểu “màn hình hoá đơn khó hiểu quá”, mà chẳng ai biết phải làm gì với góp ý đó.

Phân loại góp ý

#

Cuối mỗi ngày, hoặc cuối mỗi vòng nếu vòng đó nhỏ, tôi cùng người phụ trách sản phẩm (product owner) rà lại toàn bộ nhật ký góp ý và xếp từng mục vào một trong bốn nhóm.

Lỗi (bug) là thứ bị hỏng, như tổng tiền tính sai hay một trang báo lỗi. Nếu nghiêm trọng thì phải sửa trước khi nghiệm thu, còn không thì xếp lịch sửa sau.

Yêu cầu thay đổi (change request) nghĩa là tính năng chạy đúng như đặc tả, nhưng bản đặc tả lại sai, giống như chuyện thiếu lựa chọn nhập theo phần trăm ở trên. Đây chính là loại góp ý mà UAT sinh ra để tìm, và cũng là loại khó xử lý nhất, vì sửa nó đồng nghĩa với việc mở rộng phạm vi. Người quyết định là product owner: sửa ngay, hay chấp nhận và xếp lịch làm sau.

Vấn đề về câu chữ hoặc hướng dẫn sử dụng nghĩa là tính năng không có gì sai, nhưng người dùng không hiểu nó. Nhiều khi chỉ cần sửa một nhãn, thêm một dòng gợi ý, hoặc một câu trong tài liệu hướng dẫn là xong. Rẻ, và đáng làm.

Không sửa (won’t fix) dành cho những ý tưởng nằm ngoài phạm vi, hoặc sở thích của một người đi ngược với tất cả những người còn lại. Hãy ghi lại lý do, và báo lại cho người đã nêu ý kiến. Người kiểm thử mà góp ý xong không bao giờ nhận được hồi âm thì sang vòng sau sẽ thôi góp ý.

Điều tôi cố tránh nhất là coi mục nào cũng là lỗi phải sửa trước khi ra mắt. Đó là cách một vòng kiểm thử hai tuần biến thành hai tháng. Mục tiêu của việc xử lý góp ý UAT không phải là đưa danh sách về con số không, mà là mục nào cũng đã có một quyết định đi kèm.

Nghiệm thu

#

Sau vòng kiểm thử, hãy sửa những gì cần sửa, và nếu thay đổi nhiều thì chạy thêm một vòng ngắn nữa, đừng mặc định là mọi thứ đã ổn. Sau đó lấy xác nhận nghiệm thu đàng hoàng, đối chiếu với các tiêu chí đã thống nhất từ đầu. Nghĩa là phải có một người cụ thể, có tên tuổi đàng hoàng, nói “Được, phát hành đi”, kèm danh sách các mục đã dời lại, chứ không phải một emoji giơ ngón cái trong nhóm chat.

Những sai lầm tôi từng mắc khi tổ chức UAT

#

Làm quá muộn. Nếu UAT bắt đầu hai ngày trước một ngày ra mắt đã chốt cứng, thì yêu cầu thay đổi nào cũng biến thành một cuộc tranh cãi xem có nên lùi ngày hay không, và câu trả lời lúc nào cũng là không. Hãy chừa thời gian để còn xử lý những gì mình phát hiện ra.

Kiểm thử với sai người. Nhân viên nội bộ đã quá quen sản phẩm sẽ hành xử y như đội phát triển. Họ biết thừa mọi thứ nằm ở đâu.

Coi im lặng là đồng ý. Nếu một người kiểm thử không ghi nhận gì cả, nhiều khả năng là họ chưa thực sự kiểm thử. Hãy hỏi han họ trước khi tính họ là “đạt”.

Và để UAT trở thành một ô cần tích cho xong ở cuối sprint. Tốt hơn hết là coi nó như cửa ải cuối cùng: khoảnh khắc cuối trước khi ra mắt, khi có một người không phải bạn thử dùng thứ bạn làm ra.

UAT mang lại cho bạn điều gì

#

Chủ yếu là bắt được vấn đề khi sửa vẫn còn rẻ: ngay trước khi ra mắt, thay vì phải tung bản vá kèm lời xin lỗi sau đó. Ngoài ra còn vài cái lợi ít ai để ý hơn. Việc đào tạo và hỗ trợ người dùng nhẹ nhàng hơn, vì các luồng thao tác đã khớp với cách mọi người thực sự làm việc. Và các bên liên quan từng tham gia kiểm thử sẽ xác nhận nghiệm thu nhanh hơn, vì đến lúc đó sản phẩm cũng phần nào là của họ. Những bản phát hành mà tôi thấy có một vòng UAT tử tế thường là những lần phát hành êm ả nhất.

Tóm lại

#

UAT là lúc người dùng thật kiểm tra xem phần mềm có làm đúng điều họ cần hay không, trước khi phát hành. Chỉ bắt đầu khi QA đã sạch lỗi. Mời năm đến tám người giống với người dùng của bạn, viết kịch bản dưới dạng mục tiêu hằng ngày thay vì từng bước thao tác, và ghi lại mọi khoảng vênh giữa điều họ mong đợi và điều thực tế xảy ra. Xếp từng góp ý vào một trong bốn nhóm: lỗi, yêu cầu thay đổi, vấn đề câu chữ, hoặc không sửa. Mục nào cũng phải có quyết định, và kết thúc bằng lời nghiệm thu của một người cụ thể.