Bài viết được sự cho phép của tác giả Trần Ngọc Minh
Một số người nghĩ rằng tính tiện ích của sản phẩm là rất đắt đỏ và phức tạp và rằng việc kiểm thử người dùng nên chỉ được thực hiện trong các dự án thiết kế web hiếm hoi với ngân sách khổng lồ và lịch trình thời gian phong phú. Điều này không đúng. Các cuộc kiểm thử về tính tiện ích phức tạp chỉ là lãng phí tài nguyên. Kết quả tốt nhất đến từ việc kiểm thử không quá 5 người dùng và tiến hành nhiều cuộc kiểm thử nhỏ nhất có thể bạn có khả năng chi trả.
Trong nghiên cứu trước đó, Tom Landauer và tôi đã chỉ ra rằng số lượng vấn đề về tính tiện ích được phát hiện trong một cuộc kiểm thử với n người dùng là:
trong đó N là tổng số vấn đề về tính tiện ích trong thiết kế và L là tỷ lệ vấn đề về tính tiện ích được phát hiện khi kiểm thử một người dùng đơn lẻ. Giá trị thông thường của L là 31%, được tính trung bình trên một số lượng lớn các dự án chúng tôi đã nghiên cứu. Vẽ đồ thị cho L = 31% sẽ cho kết quả như sau:
Sự thật đáng chú ý nhất từ đường cong này là rằng không có người dùng nào thì cũng không có thông tin chi tiết nào được đưa ra.
Ngay khi bạn thu thập dữ liệu từ một người dùng thử nghiệm duy nhất, những hiểu biết của bạn sẽ tăng lên và bạn đã học được gần một phần ba của tất cả những gì bạn cần biết về tính tiện ích của thiết kế. Sự chênh lệch giữa việc không có dữ liệu và việc có ít nhất một chút dữ liệu là đáng kinh ngạc.
Khi bạn kiểm thử người dùng thứ hai, bạn sẽ phát hiện ra rằng người này thực hiện một số hành động giống như người dùng đầu tiên, vì vậy có một số điểm chung trong những gì bạn học được. Mỗi người dùng là duy nhất, vì vậy cũng sẽ có điều gì đó mới mẻ mà người dùng thứ hai thực hiện mà bạn không quan sát được ở người dùng đầu tiên. Do đó, người dùng thứ hai thêm vào một lượng thông tin mới, nhưng không nhiều như người dùng đầu tiên đã làm.
Người dùng thứ ba sẽ thực hiện nhiều hành động mà bạn đã quan sát được với người dùng đầu tiên hoặc với người dùng thứ hai và thậm chí một số hành động mà bạn đã thấy hai lần. Ngoài ra, tất nhiên, người dùng thứ ba sẽ tạo ra một lượng dữ liệu mới nhỏ, ngay cả khi không nhiều như người dùng đầu tiên và người dùng thứ hai đã làm.
Khi bạn thêm nhiều người dùng hơn và hơn, bạn học ít đi vì bạn sẽ tiếp tục thấy các điều giống nhau lần nữa và lần nữa. Không cần thiết phải tiếp tục quan sát cùng một điều nhiều lần, và bạn sẽ rất có động lực để quay lại vẽ lại thiết kế và loại bỏ các vấn đề về tính tiện ích.
Sau người dùng thứ năm, bạn đang lãng phí thời gian bằng cách quan sát các kết quả giống nhau một cách lặp đi lặp lại mà không học được nhiều điều mới.
Thiết kế Lặp đi lặp lại
Đường cong rõ ràng cho thấy bạn cần phải kiểm thử với ít nhất 15 người dùng để phát hiện tất cả các vấn đề về tính tiện ích trong thiết kế. Vậy tại sao tôi khuyên bạn nên kiểm thử với một số lượng người dùng nhỏ hơn?
Lý do chính là tốt hơn nếu bạn phân phối ngân sách của mình cho việc kiểm thử người dùng thông qua nhiều cuộc kiểm thử nhỏ hơn thay vì chi hết mọi thứ vào một nghiên cứu tổ chức lớn, phức tạp. Hãy nói rằng bạn có đủ kinh phí để tuyển chọn 15 khách hàng đại diện và cho họ kiểm thử thiết kế của bạn. Tuyệt vời. Hãy sử dụng ngân sách này cho 3 nghiên cứu với mỗi nghiên cứu có 5 người dùng!
Bạn muốn tiến hành nhiều cuộc kiểm thử vì mục tiêu thực sự của kỹ thuật tính tiện ích là để cải thiện thiết kế và không chỉ là để ghi chép điểm yếu của nó. Sau khi nghiên cứu đầu tiên với năm người tham gia đã phát hiện 85% vấn đề về tính tiện ích, bạn sẽ muốn sửa những vấn đề này trong quá trình thiết kế lại.
Sau khi tạo ra thiết kế mới, bạn cần phải kiểm thử lại. Mặc dù tôi đã nói rằng việc “sửa” các vấn đề được tìm thấy trong nghiên cứu đầu tiên, nhưng sự thật là bạn nghĩ rằng thiết kế mới đã vượt qua các vấn đề đó. Nhưng vì không ai có thể thiết kế giao diện người dùng hoàn hảo, không có đảm bảo rằng thiết kế mới thực sự đã sửa được các vấn đề. Một cuộc kiểm thử thứ hai sẽ phát hiện xem những sửa đổi có hoạt động hay không. Ngoài ra, khi giới thiệu một thiết kế mới, luôn có nguy cơ xuất hiện vấn đề về tính tiện ích mới, ngay cả khi vấn đề cũ đã được sửa chữa.
Xem thêm các vị trí tuyển Tester lương cao trên TopDev
Ngoài ra, cuộc nghiên cứu thứ hai với 5 người dùng sẽ phát hiện ra phần lớn 15% còn lại của các vấn đề về tính tiện ích ban đầu mà không được phát hiện trong vòng kiểm thử đầu tiên. (Vẫn sẽ còn 2% vấn đề gốc còn lại — chúng sẽ phải chờ đến cuộc kiểm thử thứ ba để được xác định.)
Cuối cùng, cuộc nghiên cứu thứ hai sẽ có thể đào sâu hơn vào tính tiện ích của cấu trúc cơ bản của trang web, đánh giá các vấn đề như kiến trúc thông tin, quy trình công việc và phù hợp với nhu cầu của người dùng. Những vấn đề quan trọng này thường bị che khuất trong các nghiên cứu ban đầu, nơi người dùng bị rối bời bởi các vấn đề tính tiện ích cấp độ bề mặt ngốc nghếch mà ngăn cản họ thực sự khám phá trang web.
Vì vậy, cuộc nghiên cứu thứ hai không chỉ phục vụ như một bản đảm bảo chất lượng của kết quả từ cuộc nghiên cứu đầu tiên mà còn giúp cung cấp cái nhìn sâu hơn. Cuộc nghiên cứu thứ hai sẽ luôn dẫn đến một danh sách vấn đề về tính tiện ích mới (mặc dù nhỏ hơn) để sửa trong quá trình thiết kế lại. Và cái nhìn này cũng áp dụng cho việc thiết kế lại: không phải tất cả các sửa đổi sẽ hoạt động; một số vấn đề sâu hơn sẽ được khám phá sau khi dọn sạch giao diện. Do đó, việc thực hiện một cuộc nghiên cứu thứ ba cũng là cần thiết. Trải nghiệm người dùng cuối cùng được cải thiện nhiều hơn thông qua 3 cuộc nghiên cứu với 5 người dùng mỗi cuộc hơn là thông qua một cuộc nghiên cứu “quái vật” với 15 người dùng.
Tại sao không kiểm thử với một người dùng duy nhất?
Bạn có thể nghĩ rằng 15 nghiên cứu với mỗi nghiên cứu chỉ có một người dùng sẽ tốt hơn thậm chí còn tốt hơn 3 nghiên cứu với 5 người dùng. Đường cong thực sự chỉ ra rằng chúng ta học được nhiều hơn từ người dùng đầu tiên so với bất kỳ người dùng nào sau đó, vậy tại sao cần tiếp tục?
Có hai lý do:
- Luôn có nguy cơ bị lạc hướng bởi hành vi ngẫu nhiên của một người duy nhất, người này có thể thực hiện các hành động cụ thể một cách tình cờ hoặc một cách không đại diện. Ngay cả 3 người dùng cũng đủ để có ý tưởng về sự đa dạng trong hành vi của người dùng và để hiểu rõ điều gì là độc đáo và điều gì có thể được tổng quát hóa.
- Phân tích chi phí lợi ích của việc kiểm thử người dùng cung cấp tỷ lệ tối ưu khoảng 3 hoặc 5 người dùng, tùy thuộc vào phong cách kiểm thử. Luôn có một chi phí cố định ban đầu liên quan đến việc lên kế hoạch và thực hiện nghiên cứu: tốt hơn là phân chia chi phí khởi đầu này qua các kết quả từ nhiều người dùng.
Khi Nào Nên Kiểm Thử Thêm Người Dùng
Bạn cần kiểm thử thêm người dùng khi một trang web có nhiều nhóm người dùng có đặc điểm riêng biệt. Công thức chỉ áp dụng cho những người dùng tương đối tương đồng, sẽ sử dụng trang web theo cách khá giống nhau.
Ví dụ, nếu bạn có một trang web sẽ được sử dụng bởi cả trẻ em và phụ huynh, thì hai nhóm người dùng này sẽ có hành vi đủ khác biệt đến mức cần thiết phải kiểm thử với người dùng từ cả hai nhóm. Tình hình tương tự cũng xảy ra với một hệ thống hướng đến việc kết nối các đại lý mua hàng với nhân viên bán hàng.
Ngay cả khi các nhóm người dùng rất khác biệt, vẫn sẽ có nhiều điểm tương đồng giữa các quan sát từ hai nhóm người dùng. Cuối cùng, tất cả người dùng đều là con người. Ngoài ra, nhiều vấn đề về tính tiện ích liên quan đến cách cơ bản mà người dùng tương tác với Web và ảnh hưởng từ các trang web khác đối với hành vi người dùng.
Trong việc kiểm thử nhiều nhóm người dùng không tương đồng, bạn không cần phải bao gồm nhiều thành viên từng nhóm như bạn sẽ làm trong một cuộc kiểm thử duy nhất của một nhóm người dùng. Sự trùng lặp giữa các quan sát sẽ đảm bảo kết quả tốt hơn từ việc kiểm thử một số lượng nhỏ người dùng trong mỗi nhóm. Tôi khuyên bạn nên:
- 3-4 người dùng từ mỗi nhóm nếu kiểm thử hai nhóm người dùng.
- 3 người dùng từ mỗi nhóm nếu kiểm thử ba hoặc nhiều nhóm người dùng (bạn luôn muốn ít nhất 3 người dùng để đảm bảo bạn đã bao quát được sự đa dạng trong hành vi trong nhóm).
Nguồn: Why You Only Need to Test with 5 Users
Bài viết gốc được đăng tải tại ngocminhtran.com
Xem thêm:
- Automation Test là gì? Tester cần kỹ năng gì để làm Automation Testing
- Thực thi kiểm thử tự động Selenium với Selenium-Grid
- NUnit – Thực thi kiểm thử tự động với mã từ Selenium IDE
Xem thêm các việc làm công nghệ hấp dẫn trên TopDev