BÀI VIẾT
QA Skills thực hành, phần 4: Mobile, tiếp cận, bản địa hóa và giao diện
Thiết kế ma trận trải nghiệm theo người dùng, kết hợp thiết bị thật, bàn phím, ngôn ngữ và ảnh so sánh để tìm lỗi giao diện có ý nghĩa.
Trong bài viết
Một chức năng có thể đúng ở kích thước cửa sổ quen thuộc nhưng khó dùng khi bàn phím điện thoại xuất hiện, khi chữ được phóng lớn hoặc khi nhãn được dịch dài hơn. Để tìm các lỗi này, QA cần kiểm tra cùng một mục tiêu của người dùng trong nhiều điều kiện sử dụng. Chỉ đổi chiều rộng màn hình rồi chụp ảnh sẽ bỏ sót nhiều trạng thái quan trọng.
Phần bốn trong loạt QA Skills thực hành dùng hành trình tìm và lưu sách làm ví dụ. Các tình huống dưới đây được biên soạn cho việc học, không phải kết quả đánh giá một website hoặc chứng nhận khả năng tiếp cận. Bạn có thể áp dụng phương pháp cho ứng dụng có quyền kiểm tra, với ma trận thiết bị và ngôn ngữ phù hợp người dùng của dự án.
Chọn ma trận từ rủi ro sử dụng
Mobile Tester trong bản tài liệu này tập trung nhiều vào mobile web, responsive và PWA. Nội dung đào tạo đi kèm còn bàn về ứng dụng native và vòng đời ứng dụng. Cần xác định rõ loại sản phẩm trước khi chọn kiểm tra; tình huống cài đặt bản build native khác với việc mở trang responsive trong trình duyệt.
Tạo ma trận có thiết bị hoặc môi trường mô phỏng, hệ điều hành, trình duyệt, hướng màn hình, điều kiện mạng và nhu cầu tiếp cận. Chọn dựa trên người dùng thực tế khi có dữ liệu được phép dùng. Với bài tập chưa có analytics, ghi các cấu hình là giả định đại diện. Không lấy bảng thị phần hoặc danh sách máy trong tài liệu cũ để gọi là thiết bị phổ biến nhất hiện nay.
Ưu tiên giao điểm có rủi ro: màn hình hẹp và nhãn dài; biểu mẫu đang báo lỗi và bàn phím mở; phóng chữ và menu mở. Không cần nhân mọi chiều thành toàn bộ tổ hợp ngay từ đầu. Ghi lý do chọn để nhóm hiểu phần nào đã được bao phủ và phần nào còn trống.
Mô phỏng giúp phát hiện sớm, thiết bị thật bổ sung bằng chứng
Mô phỏng trình duyệt hữu ích để rà breakpoint, tràn ngang, ảnh responsive và thứ tự bố cục. Ghi cấu hình viewport và mức phóng khi chụp bằng chứng. Kiểm tra cả chiều ngang, thanh điều hướng trình duyệt thay đổi kích thước và nội dung khi bàn phím che một phần vùng nhìn thấy, nếu môi trường hỗ trợ.
Trên thiết bị thật, quan sát thao tác chạm, bàn phím, cuộn, điều hướng quay lại, quyền hệ thống và việc ứng dụng bị gián đoạn. Với native app, thêm các trạng thái chuyển nền, trở lại, khởi động và xử lý dữ liệu đang dở theo yêu cầu. Mô phỏng viewport không tự chứng minh trải nghiệm phần cứng hay mọi cử chỉ đã đúng.
Nếu có PWA, kiểm tra hành vi manifest, service worker, cache và offline theo thiết kế đã công bố. Người dùng cần hiểu dữ liệu nào còn xem được và thao tác nào phải chờ mạng. Trạng thái lỗi nên cung cấp cách phục hồi; đừng coi việc trang vẫn hiện một khung giao diện khi mất mạng là đủ.
Kiểm tra khả năng tiếp cận theo một nhiệm vụ hoàn chỉnh
Accessibility Tester kết hợp quét tự động với kiểm tra thủ công. Quét từng trạng thái quan trọng: trang mới tải, kết quả rỗng, thông báo lỗi và hộp thoại đang mở. Kết quả không có cảnh báo từ một lần quét vẫn để lại các câu hỏi về thứ tự tương tác và ý nghĩa nội dung.
Thực hiện hành trình chỉ bằng bàn phím: đến ô tìm kiếm, nhập từ khóa, mở sách, lưu và quay lại. Focus cần nhìn thấy được và đi theo thứ tự hợp lý. Nếu có hộp thoại, kiểm tra tên, điểm focus ban đầu, cách đóng và vị trí trả focus. Tránh dùng chuột xen vào để hoàn tất rồi kết luận hành trình bàn phím đã đạt.
Với trình đọc màn hình trong phạm vi có thể kiểm tra, nghe tên, vai trò và trạng thái của nút. “Lưu” và “Đã lưu” phải được truyền đạt theo thiết kế, bao gồm phản hồi động khi cần. Kiểm tra nhãn biểu mẫu, liên kết thông báo lỗi với trường nhập, heading và landmark. Alt ảnh cần phản ánh mục đích trong ngữ cảnh; ảnh trang trí có cách xử lý khác ảnh cung cấp thông tin.
Kiểm tra phóng chữ, zoom, tương phản và những dấu hiệu đang chỉ dùng màu. Các phép đo cần công cụ và đơn vị đúng với nền tảng. Trên mobile native, point, dp và CSS pixel không thể tùy ý xem như một đơn vị. Báo cáo nên nêu tác động đến nhiệm vụ và bằng chứng thực tế, tránh tuyên bố tuân thủ toàn diện chỉ dựa trên một công cụ quét.
Bản địa hóa bao gồm cả ngữ nghĩa và dữ liệu
Localization Tester đề cập khóa dịch, placeholder, bố cục, Unicode và định dạng theo locale. Với ví dụ tiếng Việt được biên soạn cho bài này, hãy kiểm tra dấu, chữ hoa, cách xưng hô, thuật ngữ nhất quán và nội dung trên nút. Một chuỗi đã được dịch không bảo đảm người đọc hiểu đúng việc sắp xảy ra.
Khi chuỗi có biến như tên sách hoặc số mục đã lưu, kiểm tra biến còn nguyên và được thay đúng. Thử tên dài, ký tự có dấu, khoảng trắng và dữ liệu rỗng theo hợp đồng của sản phẩm. Nếu có nhiều ngôn ngữ, xem cả menu, biểu mẫu lỗi và trạng thái đang tải; những phần ít xuất hiện thường dễ bị bỏ sót.
Ngày giờ, số và tiền tệ cần được kiểm tra với locale, múi giờ và dữ liệu đầu vào cố định. Cùng một thời điểm có thể hiển thị ngày khác nhau ở các múi giờ. Ghi rõ quy tắc sản phẩm muốn áp dụng trước khi dùng một chuỗi hiển thị làm đáp án chuẩn. Với ngôn ngữ viết từ phải sang trái, kiểm tra luồng trang và từng biểu tượng theo ý nghĩa thay vì lật toàn bộ một cách máy móc.
So sánh hình ảnh cần baseline được xem xét
Visual Tester mô tả baseline, ảnh hiện tại và ảnh khác biệt. Chọn ảnh theo trang, component và trạng thái: nút đang focus, menu mở, kết quả rỗng hoặc thông báo lỗi. Giữ môi trường chụp ổn định về trình duyệt, viewport, font và dữ liệu; xử lý nội dung động theo cách không che đi vùng đang cần kiểm tra.
Mỗi khác biệt cần được xem cùng yêu cầu thiết kế. Font hiển thị khác do môi trường, nội dung mới hợp lệ và nút bị che đều có thể tạo diff nhưng có ý nghĩa khác nhau. Việc cập nhật baseline cần người xem và lý do; tự chấp nhận mọi ảnh mới sẽ làm mất tác dụng phát hiện hồi quy.
Ảnh giống nhau cũng chưa chứng minh nút có thể được kích hoạt, tên truy cập đúng hay API xử lý thành công. Ghép ảnh so sánh với các kiểm tra hành vi đã thiết kế ở phần trước để có bằng chứng đầy đủ hơn.
Đầu ra của bài thực hành
Tạo ma trận nhỏ cho một hành trình, ghi cả trạng thái giao diện và điều kiện sử dụng. Thực hiện phần bạn có công cụ, lưu ảnh hoặc ghi chép đã làm sạch, và nêu rõ phần còn cần thiết bị thật hoặc người biết ngôn ngữ đánh giá. Mỗi lỗi nên có môi trường, bước tái hiện, ảnh hưởng và kết quả mong đợi xuất phát từ yêu cầu.
Chủ đề tham khảo từ bộ AI Tester Skills. Nội dung được biên soạn lại thành hướng dẫn thực hành cho người đọc.
Thảo luận
Bình luận được duyệt trước khi công khai. Email của bạn được giữ riêng tư.