User Acceptance Testing

User Acceptance Testing, trong Agile, thường được coi là session để Product Owner/ BA review cái mà Development team làm ra trước khi release sản phẩm. Tuy nhiên, UAT gặp khá nhiều khó khăn và bất cập, lý do chính là vì chúng ta không thể hiện được ‘tình huống thật’, dẫn đến những đánh giá của chúng ta mất đi tính khách quan cần có. Thực ra là, để có được 1 UAT session hiệu quả, bạn phải chuẩn bị rất nhiều việc trước đó, từ khâu chọn người đến thiết lập môi trường và việc đánh giá kết quả. Bài viết này sẽ nói về một số công việc cần chuẩn bị, cả về document lẫn mindset để có một buổi UAT hiệu quả.

Một dòng ngắn gọn để định nghĩa nó:

A process of verifying that a solution works for the user

Đơn giản là UAT được làm ra để trả lời những câu hỏi:

• “Cái mình làm ra có phải là cái User muốn không?”
• “User có cảm thấy nội dung ghi trong website là cái họ đang tìm?”
• “User có thấy dễ catch up khi lần đầu vào website của mình không? Hoặc là sau 1 tháng không vào website với nhiều thay đổi?”
• “User có thấy benefit website mang lại xứng đáng so với công sức, tiền bạc, thời gian và cả thông tin mà họ cung cấp cho mình không?”
• “User có dễ dàng hiểu và xử lý vấn đề khi gặp lỗi không?”
• “User có cảm thấy UI hợp với ý họ, giúp họ tập trung vào content và công việc cần làm?”
• “Bạn có đang giúp User tiết kiệm các bước làm việc khi họ đã quen với system?”

Nói tóm lại, UAT session tất cả là về End User, bạn cố gắng tìm hiểu xem End User sẽ nghĩ gì về cái mình mới làm ra.

Tuy nhiên, trên thực tế thì có rất nhiều ngộ nhân về UAT

Không phải tất cả problem đều cần phải fix: 1 thói quen xấu của Development team. Khi được PO hay BA nói về 1 bug, họ đều mặc định là cần phải fix nhưng nó không phải như vậy, đặc biệt là với UX bug. Bạn cần phải hiểu rõ loại User nào có thể gặp problem này? Đó có phải là target user của mình? Có cách nào cho User work around không? User có biết cách này?…

Tất cả bug còn sót lại đều nên được capture trong UAT: Không! UAT chỉ nên tập trung vào những flow chính mà system mang lại benefit cho End User. Điều đó đồng nghĩa với việc sẽ có rất nhiều flow bị bỏ qua. Hơn thế nữa, để đảm bảo rằng buổi UAT hiệu quả. Developer team phải chắc chắn rằng cái mà mình đem đi test là đúng y chang cái mình muốn làm ra rồi. UAT sẽ nói cho bạn biết rằng cái bạn muốn làm ra có phải là cái End User muốn không? Nếu khi test UAT mà bạn tìm ra 1 bug mà bạn từ đầu đã không muốn có, thì tức là khâu development đang có vấn đề. Bạn cần phải improve sau này.

Product Owner, BA, hoặc QA nên là người làm UAT: Một sai lầm khác, UAT cần end user để có thể nói cho bạn biết được cái mà bạn muốn làm có thật sự tốt không. Việc bạn kêu PO, BA vào test chẳng khác nào nói với họ “Bạn tự tìm lỗi sai của mình đi!”. Đôi khi sẽ có hiệu quả, yes, nhưng nhìn chung là mất đi tính khách quan rất nhiều. Còn QA? Cho dù bạn có minset tốt thế nào đi nữa, bạn vẫn biết quá nhiều về dự án, quá nhiều về technical, quá nhiều về cách hoặt động của hệ thống mà không End User nào nên biết về những chuyện này! Ngược lại, bạn khó có thể nào có background của 1 End User bình thường, ví dụ như là 1 tổng giám đốc của 1 công ty. Điều đó làm cho kết quả UAT trở nên thiếu khách quan và vô dụng. Với những sai lầm về mặt đánh giá UAT như vậy, kết quả UAT thường bị xem là ‘không rõ ràng’, ‘vô căn cứ’ và thường bị lờ đi, nếu là PO hay BA trực tiếp yêu cầu thì mới fix.

Vậy làm thế nào để có 1 session UAT hiệu quả?

Nghe có vẻ phức tạp và không khả thi. Bạn không thể lúc nào cũng kêu End User tới để review sản phẩm của bạn được. Vậy giải pháp là gì?

• Nên nhớ, bạn chỉ cần 1 group 5 user cho 1 buổi UX testing sessions, nó sẽ giúp bạn tìm được khoảng 80% vấn đề về UX. Vậy, hãy thử mời member của công ty nhưng không phải thuộc team của bạn, hay là người quen của bạn, hay chỉ đơn giản là 1 vài end user thân thiết mà bạn biết?

• Cho dù những end user trên có thể không có background của end user thật, nhưng ít nhất họ vẫn có tính khách quan rất lớn, và họ cũng không có kiến thức quá nhiều về sản phẩm của bạn. Nói tóm lại, họ là better end user so với bạn và member của bạn.

• Đôi khi, có những feature là sự tương tác giữa nhiều User. Nếu bạn không có một bộ test User vừa đủ, một mình “phân thân” ra để test chỉ đưa ra những đánh giá sai lầm

Đây chính là lúc mà chúng ta cần PO, BA và cả QC như là assistant. Trong 1 buổi UX session, chúng ta cần observers để:

• Giới thiệu sơ lược về product cho experiment users.

• Quan sát hành vi của End User. Hãy tập trung vào những “Aha!” hay “Fuck it!” moment. Đó là lúc end user đáng giá về sản phẩm nổi bật nhất. Bạn sẽ thấy, cái User nói đôi khi sẽ chẳng phải là cái User làm. Quan sát họ tương tác trong môi trường tự nhiên sẽ là cách tốt nhất để hiểu về end user.

• Người để giúp đỡ end user kịp thời trong trường hợp có bug không mong muốn xảy ra, hoặc họ bị stuck quá nhiều vào 1 vấn đề. Bạn có thể cung cấp lời khuyên để họ tạm thoát ra khỏi vòng lặp ấy, nhưng đừng quá chi tiết, nó có thể sẽ làm hỏng sự khách quan và tính tự tìm hiểu của end user.

Hãy cố gắng đảm bảo những điều sau đây:

• Bug free từ góc độ của team: như đã nói, sẽ là rất rất khó chịu cho một người muốn đưa cho bạn feedback về sản phẩm khi mà họ gặp những bug blocker hoặc obvious. Mỗi một lần như vậy sẽ làm giảm độ hứng thú và sự tập trung của người test. Những bug thông thường sẽ làm nhiễu đánh giá của User về sản phẩm

Đương nhiên, mình không quá khắt khe trong việc free bug. Nếu bạn có một vài bug không quá critical, hãy note nó lại cho những người running buổi UAT, để họ có thể kịp thời thông báo cho end user và có những chỉ dẫn phù hợp.

• Setup một số data test: Ví dụ, bạn có một trang web mua hàng. Bạn đương nhiên là không muốn User phải vào trang web mà không thấy có món hàng nào để mua đúng không?

• Một trường hợp khác, bạn là một trang web mua vé máy bay. Yes, lúc đầu bạn sẽ muốn User tương tác khi họ chưa có chiếc vé nào cả, để xem User sẽ làm thế nào để tìm ra cách book vé? Tuy nhiên, sau đó bạn sẽ muốn User gặp trường hợp họ đã book 100 vé, và họ sẽ cảm thấy giao diện như thế nào đúng không? Bạn, hay là test User sẽ chẳng muốn ngồi tạo từng đấy ticket để test case này. Đây chính là lúc test data vào cuộc. Một câu SQL, hay 1 account có sẵn data sẽ giúp test User tiến hành case này nhanh chóng.

Nói tóm lại, tạo ra nhiều bộ test data sẽ giúp bạn và end User chủ động hơn trong việc focus vào feature cần test, thay vì phải làm những bước phụ, những feature mà bạn không muốn tập trung vào trong đợt release này

Thông thường, bạn sẽ release 1 feature mà không phải là toàn bộ product. Tức là product của bạn đã có sẵn những phần khác rồi. Một vấn đề đau đầu là test User vào trang web của bạn, nếu không được định hướng đúng thì họ sẽ tập trung vào những feature khác, mà không phải là cái feature mà bạn muốn họ cho ý kiến. Mình đã từng làm 1 buổi UX mà suốt cả buổi người ta chỉ loay hoay tìm ‘problem’ ở feature tạo chart, trong khi cái mình muốn là họ đưa ý kiến của mình về chart ở view mode nó như thế nào, có dễ hiểu không?

Với mục tiêu đó, cái bạn cần là set up ‘tình huống’. Bạn bắt đầu buổi UAT session bằng cách giới thiệu sơ qua về product. Sau đó, bạn đặt test User vào một tình huống nhất định, giả sử như là ‘Bạn vào page của sếp và đọc report’. Những benefit mang lại

• Bạn setup cho test User để họ hiểu được họ ‘nên là ai’.

• Bạn giúp user catch up một chút về feature. Again, đừng quá chi tiết, nó chỉ nên giống như là 1 video tutorial quảng cáo nhỏ của product thôi.

Nếu bạn có test data, như đã nói, bạn có thể giúp User focus ngay vào feature họ cần give feedback.

Khi User đang tương tác với hệ thống, và bạn là người quan sát và take note, chắc chắn bạn sẽ có một lượng lớn feedback data mà không thể giải mã ngay được. Hơn thế nữa, bạn cũng nên mang data đó discuss với team. Mình đã từng thấy JIRA team của Atlassian hay một số nơi khác, họ quay phim lại cận cảnh những hành động của test User. Đó sẽ la những tư liệu vô cùng quan trọng. Tuy nhiên, hãy chắc rằng việc quan sát và record của bạn không làm User mất tập trung

Trước khi kết thúc session, hãy tranh thủ hỏi user một vài câu hỏi. Đây là lúc mà trí nhớ User còn fresh về những vấn đề hay cái mà họ thích về feature. Một vài câu hỏi nhỏ sẽ giúp bạn có những feedback thú vị. Ví dụ như:

• “Lúc làm abc, mình thấy bạn có khó chịu. Bạn nghĩ feature đó nên thế nào?”

• “Nếu không có buổi test này, bạn có muốn dùng feature này?”

• “Nếu không có feature này, thường thì hồi trước bạn làm gì để có được xyz?”

• ….

Nói chung là câu hỏi cần customized cho từng User dựa vào hành vi của họ. Hãy nói chuyện thân thiện và lắng nghe ý kiến của họ.

Công việc cuối cùng là đánh giá.

Như đã nói ở trên, đây chính là lúc bạn đánh giá lại độ nghiêm trọng và ưu tiên của những vấn đề ( Priority and Severity). Hãy chắc chắn rằng bạn lưu lại những valid bug trong backlog, và ghi rõ evidence source (record chẳng hạn) hay tình huống của End User.

Bạn sẽ cảm thấy rất đau đầu khi đánh giá 1 feature có thành công hay thất bại.

Lý do là vì:

• Bạn phải suy nghĩ xem problem của User này có phải là problem chung của phần lớn User trong system?

• Bạn thắc mắc liệu bạn fix cái này theo một hướng nào đó, thì liệu nhìn chung người dùng có thích product hơn? Bạn nên nhớ, có khả năng là bạn fix cái này thì người dùng sẽ không thích 1 cái feature khác nữa và đâm ra ghét cả product chẳng hạn

• Liệu mình có phải tổ chức một buổi UAT nữa không?

Dưới đây là những step cơ bản mà mình đã thu thập được từ nhiều nguồn khác nhau để có một session UAT hiệu quả. Ở mỗi nơi, mỗi feature sẽ có đôi chút khác biệt. Tuy nhiên, những step kể trên dù ít hay nhiều sẽ là cần thiết để bạn có thể thu thập được User feedback một cách rõ ràng và hiệu quả nhất. Chúc các bạn thành công.