Usability Testing & Heuristic Evaluation — Software Testing Fundamentals

Mở đầu — vì sao bài này quan trọng

Hãy hình dung tình huống này: bạn là tester của một ứng dụng đặt vé xe khách. Bạn viết test case, chạy qua hết, mọi thứ "pass" — người dùng nhập điểm đi, điểm đến, chọn ghế, thanh toán, nhận vé. Đúng spec 100%. Nhưng khi app ra thị trường, tỷ lệ bỏ giỏ hàng (abandonment) ở bước chọn ghế lên tới 40%. Người dùng không hoàn thành được, không phải vì app "sai", mà vì app "khó dùng". Họ không hiểu ghế nào đã bị đặt, nút "Tiếp tục" nằm ở đâu, tại sao màn hình cứ đứng im mấy giây mà không báo gì.

Đây chính là ranh giới mà bài học hôm nay muốn bạn nhìn thấy rõ: "đúng spec" (correctness) khác hoàn toàn với "dễ dùng" (usability). Một chức năng có thể chạy đúng logic nhưng vẫn khiến người dùng bực bội, lạc lối, hoặc bỏ cuộc. Là một QA chuyên nghiệp, bạn không chỉ bảo vệ tính đúng đắn của phần mềm — bạn còn là người đại diện cho tiếng nói của người dùng.

Trong bài này chúng ta sẽ học hai công cụ cốt lõi: Usability Testing (kiểm thử khả dụng, quan sát người dùng thật tương tác) và Heuristic Evaluation (đánh giá theo bộ nguyên tắc chuyên gia, đặc biệt là 10 heuristic kinh điển của Jakob Nielsen). Hai công cụ này bổ trợ cho nhau và không đòi hỏi bạn phải là chuyên gia UX mới làm được. Với vài kỹ thuật đúng đắn, ngay cả tester junior cũng có thể phát hiện ra những vấn đề khả dụng nghiêm trọng mà đội thiết kế bỏ sót.

Khái niệm cốt lõi

Usability là gì và đo bằng cái gì

Theo tiêu chuẩn ISO 9241-11, usability là "mức độ mà một sản phẩm có thể được người dùng cụ thể sử dụng để đạt mục tiêu cụ thể một cách hiệu quả (effectiveness), hiệu suất (efficiency) và hài lòng (satisfaction) trong một bối cảnh sử dụng nhất định".

Ba trục đo này rất thực dụng cho QA:

Effectiveness: Người dùng có hoàn thành được nhiệm vụ không? Đo bằng task success rate (tỷ lệ hoàn thành).
Efficiency: Họ mất bao nhiêu công sức? Đo bằng time on task (thời gian), số bước, số lần click, số lỗi (error rate).
Satisfaction: Họ cảm thấy thế nào? Đo bằng khảo sát như SUS (System Usability Scale) hoặc thang điểm chủ quan.

Điểm khác biệt với kiểm thử chức năng: usability testing không hỏi "app có làm đúng không" mà hỏi "con người có dùng được app một cách suôn sẻ không".

Usability Testing — quan sát người dùng thật

Usability testing là phương pháp mời người dùng đại diện thực hiện các nhiệm vụ thực tế trên sản phẩm, trong khi bạn quan sát họ. Nguyên tắc vàng: đừng hỏi ý kiến, hãy quan sát hành vi. Người dùng thường nói một đằng làm một nẻo. Một người có thể khen giao diện "đẹp và dễ" nhưng lại loay hoay 2 phút không tìm được nút thanh toán.

Có hai dạng phổ biến:

Moderated (có người điều phối): Một facilitator ngồi cùng (hoặc gọi online), giao nhiệm vụ, quan sát, hỏi thăm dò. Kỹ thuật quan trọng nhất là think-aloud — yêu cầu người dùng nói to suy nghĩ trong khi thao tác ("Giờ tôi đang tìm chỗ đăng nhập... à không thấy, chắc ở góc trên này...").
Unmoderated (không điều phối): Người dùng tự làm bài test qua công cụ như Maze, UserTesting, ghi lại màn hình để bạn xem sau. Rẻ, nhanh, quy mô lớn, nhưng không hỏi sâu được.

Một phát hiện kinh điển từ nghiên cứu của Nielsen: chỉ cần 5 người dùng trong một buổi test là đã tìm ra khoảng 85% vấn đề khả dụng. Bạn không cần mẫu lớn để bắt đầu — điều này cực kỳ có lợi cho các đội QA ở startup Việt Nam ngân sách hạn hẹp.

Heuristic Evaluation — đánh giá theo nguyên tắc chuyên gia

Không phải lúc nào cũng có thời gian và tiền để mời người dùng thật. Heuristic Evaluation là phương pháp "đánh giá theo kinh nghiệm": một nhóm nhỏ chuyên gia (2–5 người, có thể là QA, designer, PO) rà soát giao diện dựa trên một bộ nguyên tắc chuẩn để phát hiện vấn đề. Bộ nguyên tắc phổ biến nhất là 10 Usability Heuristics của Jakob Nielsen (1994).

Dưới đây là 10 heuristic, được diễn giải theo góc nhìn tester với ví dụ Việt Nam:

Visibility of system status (Hiển thị trạng thái hệ thống) — Hệ thống luôn phải cho người dùng biết chuyện gì đang diễn ra qua phản hồi kịp thời. Thiếu spinner khi tải, không có progress bar khi upload, bấm nút mà không có gì thay đổi → vi phạm. Ví dụ: bấm "Thanh toán MoMo" mà màn hình đứng im 5 giây, người dùng bấm lại → tạo đơn trùng.

Match between system and the real world (Khớp với thế giới thực) — Dùng ngôn ngữ, khái niệm quen thuộc với người dùng, không dùng thuật ngữ kỹ thuật. Ví dụ: hiện lỗi "Error 500: Internal Server Exception" thay vì "Hệ thống đang bận, vui lòng thử lại sau".

User control and freedom (Người dùng kiểm soát và tự do) — Luôn có "lối thoát khẩn cấp": nút Hủy, Quay lại, Undo. Ví dụ: lỡ tay xóa một địa chỉ giao hàng mà không có xác nhận và không undo được → vi phạm.

Consistency and standards (Nhất quán và theo chuẩn) — Cùng một thứ phải gọi cùng một tên, đặt cùng một chỗ. Màn hình A gọi "Giỏ hàng", màn hình B gọi "Túi đồ" cho cùng chức năng → gây rối.

Error prevention (Ngăn ngừa lỗi) — Tốt hơn cả thông báo lỗi là thiết kế để lỗi không xảy ra. Ví dụ: disable nút "Đặt hàng" cho tới khi người dùng điền đủ thông tin bắt buộc, thay vì để họ bấm rồi mới báo thiếu.

Recognition rather than recall (Nhận ra thay vì phải nhớ) — Đừng bắt người dùng ghi nhớ thông tin giữa các màn hình. Ví dụ: gợi ý địa chỉ đã lưu thay vì bắt gõ lại từ đầu; hiển thị lại tóm tắt đơn hàng ở bước thanh toán.

Flexibility and efficiency of use (Linh hoạt và hiệu quả) — Cung cấp lối tắt cho người dùng thành thạo mà vẫn dễ cho người mới. Ví dụ: "mua lại đơn cũ" chỉ với một cú chạm.

Aesthetic and minimalist design (Thiết kế tối giản, thẩm mỹ) — Chỉ hiển thị thông tin cần thiết; mỗi thông tin thừa cạnh tranh sự chú ý với thông tin quan trọng. Màn hình nhồi nhét 12 banner khuyến mãi che mất nút chính → vi phạm.

Help users recognize, diagnose, and recover from errors (Giúp người dùng nhận ra và khắc phục lỗi) — Thông báo lỗi phải bằng ngôn ngữ dễ hiểu, chỉ rõ vấn đề và gợi ý cách sửa. "Số điện thoại không hợp lệ" tốt hơn "Invalid input", nhưng "Số điện thoại phải có 10 chữ số, bắt đầu bằng 0" thì tốt nhất.

Help and documentation (Trợ giúp và tài liệu) — Dù lý tưởng là app dùng được không cần hướng dẫn, vẫn nên có trợ giúp dễ tìm, dễ tra cứu khi cần.

Cách chấm mức độ nghiêm trọng

Với mỗi vấn đề phát hiện, chuyên gia chấm severity rating theo thang 0–4 của Nielsen: 0 = không phải vấn đề; 1 = lỗi thẩm mỹ nhỏ (cosmetic); 2 = vấn đề nhỏ; 3 = vấn đề nghiêm trọng, cần ưu tiên sửa; 4 = thảm họa khả dụng, buộc phải sửa trước khi phát hành. Cách chấm này giúp đội ưu tiên đúng — tương tự cách QA phân loại severity của bug (bạn sẽ học sâu ở Bài 27).

Tình huống thực tế

Ví dụ 1 — Sàn thương mại điện tử và cái nút "biến mất" trên mobile

Một sàn TMĐT giả định tên ShopViet ra mắt tính năng thanh toán mới. Đội QA đã test chức năng đầy đủ trên desktop, tất cả đều pass. Nhưng sau khi mời 5 người dùng thật (3 nữ nội trợ, 2 sinh viên) làm usability test trên điện thoại Android màn hình nhỏ, họ phát hiện: nút "Đặt hàng" nằm dưới một danh sách sản phẩm dài, và trên màn hình 5.5 inch nó bị đẩy xuống dưới đường gấp (below the fold). 4/5 người dùng cuộn lên cuộn xuống, có người kết luận "chắc app lỗi, không đặt được".

Đây là vi phạm heuristic số 1 (trạng thái không rõ) và số 8 (thiếu tối giản, danh sách quá dài). Diễn giải: chức năng đúng, nhưng bố cục khiến hành động chính bị ẩn. Bài học: usability testing trên đúng thiết bị thật của thị trường mục tiêu (người Việt dùng rất nhiều máy Android tầm trung màn hình nhỏ) phát hiện điều mà test chức năng trên desktop không bao giờ thấy. Đội đã "ghim" (sticky) nút Đặt hàng ở đáy màn hình, tỷ lệ hoàn thành đơn tăng từ 61% lên 88% trong lần test lại.

Ví dụ 2 — Heuristic Evaluation phát hiện "bẫy" trước khi tốn tiền test người dùng

Một fintech tên PayNhanh chuẩn bị ra tính năng chuyển tiền. Trước khi tổ chức buổi test người dùng tốn kém, đội QA làm một buổi Heuristic Evaluation nhanh với 3 người: 1 QA, 1 designer, 1 PO. Mỗi người tự rà soát độc lập theo 10 heuristic của Nielsen, sau đó tổng hợp.

Họ phát hiện một loạt vấn đề: (a) sau khi bấm "Chuyển tiền" không có spinner, chỉ đứng im 3–4 giây — vi phạm heuristic 1; (b) màn hình xác nhận không hiển thị lại số tiền và người nhận, buộc người dùng phải nhớ — vi phạm heuristic 6; (c) thông báo lỗi khi số dư không đủ chỉ ghi "Transaction failed" — vi phạm heuristic 9. Vấn đề (a) và (c) được chấm severity 4 (thảm họa, vì đây là chuyển tiền — người dùng bấm lại có thể chuyển hai lần).

Diễn giải: chỉ trong 2 tiếng, không cần một người dùng thật nào, đội đã bắt được ba lỗi nghiêm trọng. Bài học: Heuristic Evaluation là "lưới lọc thô" cực rẻ, nên làm SỚM trong chu trình. Nó không thay thế usability testing (vì chuyên gia không phản ứng đúng như người dùng thật), nhưng lọc bớt lỗi hiển nhiên để buổi test người dùng tập trung vào vấn đề tinh vi hơn.

Ví dụ 3 — Think-aloud lật tẩy khoảng cách giữa "nói" và "làm"

Một ứng dụng học tiếng Anh khu vực Đông Nam Á muốn kiểm tra luồng đăng ký gói premium. Khi khảo sát bằng bảng hỏi, 80% người dùng nói giao diện "rõ ràng, dễ hiểu". Nhưng khi làm usability test theo phương pháp think-aloud với 6 người, thực tế phũ phàng hơn: 4 người dừng lại ở bước chọn gói, lẩm bẩm "gói này gói kia khác gì nhau nhỉ", "sao cái nút này màu xám, bấm được không". Có người tưởng gói đang được highlight là gói đã chọn sẵn nên bấm "Tiếp tục" mà không hề chủ ý mua gói đó.

Diễn giải: dữ liệu khảo sát (nói) mâu thuẫn hoàn toàn với hành vi quan sát (làm). Vi phạm heuristic 4 (nút disabled trông giống nút bấm được) và 8 (thông tin so sánh gói không rõ). Bài học: đừng bao giờ tin lời khen suông. Think-aloud là công cụ mạnh nhất để nghe được suy nghĩ thật của người dùng ngay tại thời điểm họ bối rối.

Hướng dẫn từng bước

Cách chạy một buổi Usability Test cơ bản:

Xác định mục tiêu và người dùng đại diện. Chọn 5–6 người khớp chân dung người dùng thật (đúng độ tuổi, thiết bị, mức độ rành công nghệ). Với sản phẩm Việt Nam, nhớ chọn cả người ít rành công nghệ.
Viết kịch bản nhiệm vụ (task scenario), không phải hướng dẫn. Đúng: "Bạn muốn mua vé xe từ Sài Gòn về Cần Thơ ngày mai, hãy đặt vé." Sai: "Hãy bấm vào nút Tìm chuyến rồi chọn ngày." Đừng chỉ đường, vì mục tiêu là xem họ có tự tìm được không.
Chuẩn bị đo lường. Quyết định trước sẽ ghi: task success (đạt/không), time on task, số lỗi, chỗ nào người dùng lưỡng lự.
Chạy buổi test. Nhắc người dùng think-aloud. Bạn chỉ quan sát và ghi chép, tuyệt đối không gợi ý, không giải cứu khi họ bí — sự bí đó chính là dữ liệu vàng.
Tổng hợp và phân loại. Gom các vấn đề, gắn với heuristic bị vi phạm, chấm severity 0–4, chuyển thành báo cáo có ưu tiên cho đội dev/design.

Cách chạy một buổi Heuristic Evaluation:

Chọn 3–5 người đánh giá (theo Nielsen, 3–5 người bắt được ~75% vấn đề).
Mỗi người rà soát độc lập ít nhất hai lượt qua toàn bộ giao diện, đối chiếu từng màn hình với 10 heuristic.
Ghi lại mỗi vấn đề: mô tả, heuristic vi phạm, vị trí, severity.
Họp tổng hợp, gộp trùng, thống nhất severity, sắp xếp ưu tiên.

Lỗi thường gặp & mẹo

Nhầm usability testing với functional testing. Bạn không đi bắt bug logic ở đây; bạn đi tìm chỗ người dùng bối rối, lạc lối, bỏ cuộc. Hai mục tiêu khác nhau.
Facilitator "giải cứu" người dùng. Khi thấy họ bí, bản năng ta muốn chỉ đường. Đừng. Mỗi lần bạn cứu là bạn giết một phát hiện.
Dẫn dắt câu hỏi (leading question). Hỏi "Bạn thấy nút này dễ tìm chứ?" sẽ nhận câu trả lời chiều lòng bạn. Hãy hỏi mở: "Bây giờ bạn sẽ làm gì tiếp?".
Chỉ test trên thiết bị của lập trình viên. Người Việt dùng vô số máy Android tầm trung, mạng chập chờn, màn hình nhỏ. Test trên iPhone đời mới của dev sẽ bỏ sót rất nhiều vấn đề khả dụng thực tế.
Tin khảo sát hơn quan sát. Lời nói dễ khen; hành vi mới nói thật.
Mẹo phối hợp: Làm Heuristic Evaluation TRƯỚC (rẻ, nhanh, lọc lỗi thô), rồi mới Usability Testing (đắt hơn, tìm lỗi tinh vi). Hai cái bổ trợ chứ không thay thế nhau.
Mẹo báo cáo: Luôn kèm severity và một clip/ảnh chụp khoảnh khắc người dùng bối rối. Một đoạn video 10 giây người dùng loay hoay thuyết phục đội dev mạnh hơn mười trang mô tả.

Bài tập thực hành

Rà soát heuristic: Mở một app bạn hay dùng (ví dụ app ngân hàng hoặc app đặt đồ ăn Việt Nam). Chọn luồng "thanh toán" hoặc "đặt hàng", rà soát theo 10 heuristic của Nielsen, ghi ra ít nhất 5 vi phạm, mỗi vi phạm gắn số heuristic và chấm severity 0–4.

Viết task scenario: Với một app đặt vé xe khách, hãy viết 3 kịch bản nhiệm vụ đúng chuẩn (mô tả mục tiêu, không chỉ đường) để dùng trong buổi usability test.

Phân tích think-aloud: Cho câu người dùng nói khi test: "Ơ, tôi bấm Thanh toán rồi mà sao không thấy gì, để tôi bấm lại... à h nó nhảy hai đơn rồi." Hãy xác định heuristic nào bị vi phạm, mức severity, và đề xuất một cách sửa cụ thể.

Thiết kế buổi test mini: Nhờ 2 người thân làm một nhiệm vụ trên một website bất kỳ, yêu cầu họ think-aloud, và bạn chỉ quan sát (không gợi ý). Ghi lại 3 điểm họ lưỡng lự và ánh xạ sang heuristic.

Tóm tắt

Usability đo mức độ dễ dùng, khác hẳn correctness (đúng spec). Một app đúng spec vẫn có thể thất bại vì khó dùng.
Ba trục đo: effectiveness (hoàn thành được không), efficiency (tốn bao nhiêu công), satisfaction (hài lòng ra sao).
Usability Testing = quan sát người dùng thật làm nhiệm vụ thật; nguyên tắc vàng là quan sát hành vi, không nghe lời khen. Chỉ 5 người là tìm ra ~85% vấn đề. Think-aloud là kỹ thuật cốt lõi.
Heuristic Evaluation = chuyên gia rà soát theo 10 heuristic của Nielsen; rẻ, nhanh, nên làm sớm. Mỗi vấn đề gắn heuristic và chấm severity 0–4.
Hai phương pháp bổ trợ nhau: heuristic lọc lỗi thô, usability test bắt lỗi tinh vi.
Là QA, bạn là tiếng nói của người dùng. Test trên thiết bị và bối cảnh thật của người Việt (Android tầm trung, mạng yếu, người ít rành công nghệ) mới thấy hết vấn đề.