Cross-device compatibility (tương thích đa thiết bị) nghĩa là website có thể hiển thị và sử dụng đúng các chức năng quan trọng trên những thiết bị và trình duyệt mà dự án cần hỗ trợ. Ví dụ, khách mở trang bằng điện thoại, tìm sản phẩm, bấm liên hệ và gửi thông tin thành công. Website hiển thị vừa màn hình chưa chắc đã hoạt động tốt trên mọi thiết bị.
Nếu bạn là chủ doanh nghiệp, chỉ cần nhớ: (1) Website phải đọc được, bấm được và hoàn thành được việc quan trọng trên điện thoại/máy tính; (2) phải thử biểu mẫu, đặt hàng hoặc đặt lịch trên thiết bị thật nếu chức năng đó thuộc hợp đồng; (3) khi nghiệm thu, yêu cầu danh sách thiết bị đã thử, bằng chứng lỗi đã sửa và người chịu trách nhiệm. Không cần kiểm thử mọi mẫu điện thoại trên thị trường.
Khách hàng cần kiểm tra gì khi nghiệm thu website đa thiết bị?
- Giao diện: Khách tự mở các trang chính, xem chữ, ảnh và menu có bị che hoặc cắt. Bằng chứng nhận: danh sách thiết bị/trình duyệt đã thử, lỗi còn tồn.
- Liên hệ: Khách thử nút gọi, Zalo và biểu mẫu. Bằng chứng: yêu cầu thử đến đúng người nhận; không chỉ là thông báo “đã gửi”.
- Mua hàng hoặc đặt lịch (nếu có trong hợp đồng): Thử từ bước chọn đến khi hệ thống ghi nhận. Bằng chứng: một kết quả kiểm thử trong hệ thống, không tạo giao dịch thật ngoài ý muốn.
- Thao tác: Thử menu, cuộn, xoay màn hình, phóng to và mở bàn phím. Bằng chứng: ảnh/video, mô tả lỗi và kết quả kiểm tra lại.
- Bàn giao: Đối chiếu phạm vi đã mua. Bằng chứng: hạng mục Đạt / Chưa đạt / Không áp dụng, người xử lý và thời hạn khắc phục.
Hãy chọn các chức năng thực sự mang khách hàng hoặc phục vụ vận hành. Nếu website không có thanh toán, đừng mặc định bắt bên thiết kế thử thanh toán. Phạm vi thiết bị, phiên bản trình duyệt và mức hỗ trợ cần được chốt trong báo giá hoặc hợp đồng.
Cross-device khác Responsive và tương thích trình duyệt ra sao?
- Responsive – hiển thị linh hoạt: Bố cục, hình ảnh và menu sắp xếp lại khi màn hình rộng hoặc hẹp. Đây mới là kiểm tra phần nhìn.
- Cross-browser – tương thích trình duyệt: Website chạy đúng trên Chrome, Safari, Firefox hoặc Edge thuộc phạm vi hỗ trợ. Đây là kiểm tra môi trường trình duyệt.
- Cross-device – tương thích đa thiết bị: Người dùng thật có thể nhìn, thao tác và hoàn thành việc quan trọng trên điện thoại, máy tính bảng hoặc máy tính. Đây là kiểm tra kết quả sử dụng.
Ví dụ, menu dùng hiệu ứng rê chuột có thể chạy trên máy tính nhưng không mở được bằng ngón tay. Một nút gửi biểu mẫu có thể đẹp trên điện thoại mà thông tin vẫn không tới bộ phận tư vấn. Vì vậy, cần kiểm tra nhìn thấy → thao tác được → hệ thống xác nhận thành công.
Nên thử trên những thiết bị và trình duyệt nào?
Không có danh sách cố định phù hợp cho mọi doanh nghiệp. Đơn vị thiết kế nên dùng dữ liệu truy cập hiện có, khách hàng mục tiêu và chức năng quan trọng để chọn thiết bị thử. Theo hướng dẫn mobile-first indexing của Google, nội dung chính trên điện thoại cũng cần được giữ và truy cập phù hợp.
- Điện thoại Android dùng Chrome: thử menu, biểu mẫu, nút gọi, bàn phím và gửi yêu cầu.
- iPhone dùng Safari: thử biểu mẫu, lịch chọn ngày, menu, nút cố định ở đáy và bàn phím ảo.
- Máy tính: thử trình duyệt chủ lực của khách; mở rộng Firefox, Safari hoặc Edge theo đối tượng và hợp đồng.
- Máy tính bảng hoặc màn hình đặc thù: thử khi nhân viên/khách thường dùng; kiểm tra xoay màn hình và chạm.
- Mạng chậm, phóng to chữ: xem website có mất nội dung, che nút hoặc làm khách không thể hoàn thành thao tác không.
Công cụ giả lập giúp phát hiện lỗi bố cục nhanh, nhưng không thay thế hoàn toàn điện thoại thật: trình duyệt iPhone, bàn phím ảo, thao tác chạm, hiệu năng và quyền camera/vị trí có thể khác. Đội kỹ thuật có thể dùng trình duyệt giả lập, sau đó xác minh các luồng quan trọng bằng thiết bị thật.
Không có một con số thiết bị thử cố định cho mọi dự án. Theo hướng dẫn lập kế hoạch kiểm thử của MDN, nên ưu tiên trình duyệt và thiết bị mà nhóm khách hàng thực tế sử dụng. Nếu chưa có dữ liệu truy cập, hãy ghi rõ các giả định và nhóm thiết bị đang được hỗ trợ trong biên bản.
Quy trình kiểm thử đa thiết bị trong 6 bước
- 1. Chốt phạm vi hỗ trợ: ghi rõ những thiết bị, trình duyệt và tính năng cần hoạt động, ai phê duyệt.
- 2. Chọn việc cần thử: ưu tiên tìm dịch vụ → bấm liên hệ → gửi yêu cầu; với website bán hàng là sản phẩm → giỏ hàng → đặt hàng nếu thuộc dự án.
- 3. Lập danh sách tình huống: mỗi việc cần thử trên thiết bị/trình duyệt nào, với màn hình hẹp, bàn phím và điều kiện phù hợp ra sao.
- 4. Thử cả khi có lỗi: nhập thiếu thông tin, mất kết nối, xoay màn hình, quay lại trang trước hoặc bấm gửi hai lần.
- 5. Ghi bằng chứng: đường dẫn, thiết bị, phiên bản trình duyệt, ảnh/video, kết quả mong đợi và kết quả thực tế; che dữ liệu riêng tư.
- 6. Sửa rồi kiểm tra lại: người kỹ thuật xác nhận đã sửa, khách thử lại chức năng quan trọng và ghi kết quả vào biên bản.
Ví dụ kiểm thử minh họa, không phải kết quả đã đo trên website thật: Trên iPhone Safari, khách mở trang dịch vụ, nhập tên và số điện thoại, bấm gửi; trang hiện xác nhận và hệ thống nhận đúng một yêu cầu. Nếu biểu mẫu không gửi hoặc tạo hai yêu cầu trùng, ghi Chưa đạt, sửa và thử lại.
Mẫu ghi kết quả kiểm thử để đưa vào biên bản
Với mỗi lỗi, chỉ cần ghi đủ các thông tin dưới đây. Đây là mẫu để điền sau khi kiểm thử, không phải kết quả đã thực hiện trên websitehcm.com.
- Mã và việc thử: CD-01 – gửi biểu mẫu yêu cầu tư vấn.
- Thiết bị/môi trường: ghi mẫu điện thoại, phiên bản hệ điều hành, trình duyệt và ngày thử.
- Các bước và kết quả mong đợi: mở trang dịch vụ → nhập dữ liệu thử → gửi → hệ thống nhận đúng một yêu cầu.
- Kết quả thực tế: Đạt / Chưa đạt / Không áp dụng; ghi hiện tượng, ảnh/video hoặc mã tham chiếu khi được phép.
- Người xử lý và kiểm tra lại: ghi người chịu trách nhiệm, việc cần sửa, ngày kiểm tra lại và kết quả cuối cùng.
Kiểm thử an toàn: dùng dữ liệu giả định không nhận diện cá nhân và môi trường thử nghiệm phù hợp. Với thanh toán, ưu tiên chế độ thử của cổng thanh toán và kiểm tra trạng thái đơn thử; tránh tự tạo giao dịch tiền thật hoặc gửi dữ liệu khách hàng thật khi không cần thiết. Đội kỹ thuật phải xác nhận phần dữ liệu được lưu trên hệ thống, không chỉ ảnh chụp màn hình.
Những lỗi đa thiết bị thường gặp
- Trang cuộn ngang hoặc ảnh bị cắt: Kiểm tra bảng và hình trên màn hình hẹp; sau khi sửa, nội dung vẫn đọc được khi phóng to (trừ thành phần cần bố cục hai chiều).
- Menu, nút liên hệ bị che: Thử mở menu, nhập liệu với bàn phím ảo và bấm trên điện thoại thật; xác nhận không còn bị chắn.
- Biểu mẫu gửi lỗi hoặc ghi trùng: Dùng dữ liệu thử, đối chiếu thông báo với yêu cầu thực tế đã lưu và kiểm tra việc bấm gửi hai lần.
- Ảnh đầu trang che mất chữ: Kiểm tra cách cắt ảnh khi xoay màn hình hoặc đổi kích thước, bảo đảm thông điệp chính vẫn còn.
- Chỉ dùng được chuột, không dùng được cảm ứng/bàn phím: Thử chạm và di chuyển bằng bàn phím theo chức năng đã thống nhất.
Nếu website dịch vụ có khách xem nhưng không liên hệ, hãy thử những lỗi trên trước khi tăng quảng cáo. Có thể xem thêm các lỗi trải nghiệm khiến khách rời website.
Phần kỹ thuật cần biết để nghiệm thu đúng
Những thuật ngữ sau dành cho người triển khai, nhưng chủ doanh nghiệp nên biết ảnh hưởng của chúng tới khách sử dụng website:
- Viewport là vùng hiển thị của trang; breakpoint là mốc bố cục đổi cách sắp xếp. Đừng chỉ thử vài kích thước cố định; cần thử lúc nội dung bắt đầu bị chèn, tràn hoặc che.
- Khả năng sử dụng bằng bàn phím và cảm ứng: menu, hộp thoại và biểu mẫu phải có cách thao tác phù hợp, không chỉ dựa vào việc rê chuột.
- Kích thước vùng chạm: theo WCAG 2.2 tiêu chí 2.5.8, mục tiêu có thể đáp ứng mức AA bằng vùng 24 × 24 CSS pixel hoặc ngoại lệ quy định; mức 44 × 44 thuộc tiêu chí tăng cường AAA. Tham khảo giải thích chính thức của W3C.
- Backend là phần hệ thống phía sau nhận và xử lý dữ liệu. Nút gửi phải được xác minh thực sự tạo yêu cầu hoặc đơn hàng, không chỉ xuất hiện thông báo.
- Core Web Vitals gồm LCP (hiển thị nội dung lớn), INP (độ phản hồi) và CLS (mức xê dịch bố cục); các chỉ số giúp đánh giá trải nghiệm nhưng không xác nhận biểu mẫu hay thanh toán thành công.
Khi kiểm tra giao diện bị tràn hoặc khó đọc, đội kỹ thuật có thể đối chiếu tiêu chí Reflow 1.4.10 mức AA của W3C: với nội dung cuộn dọc thông thường, cần đọc được ở chiều rộng tương đương 320 CSS pixel mà không phải cuộn cả ngang lẫn dọc, trừ trường hợp thực sự cần bố cục hai chiều như một số bảng dữ liệu. Đây là tiêu chí kiểm thử khả năng tiếp cận, không phải khẳng định trang hiện tại đã vượt qua.
Ưu tiên lỗi nào trước khi đưa website vào hoạt động?
- P0 – chặn phát hành: Ví dụ rò dữ liệu, sai thanh toán, chức năng cốt lõi không thể hoạt động. Yêu cầu sửa, kiểm tra lại và chỉ ra mắt khi an toàn.
- P1 – ưu tiên cao: Ví dụ biểu mẫu tiếp nhận khách lỗi trên điện thoại thuộc nhóm thiết bị chính. Cần sửa trước chiến dịch hoặc ghi rõ quyết định rủi ro có người phê duyệt.
- P2 – lên lịch xử lý: Ví dụ khoảng cách hoặc cắt ảnh chưa đẹp nhưng không ngăn nhiệm vụ. Ghi lỗi, người phụ trách và hạn kiểm tra lại.
Các mức P0/P1/P2 ở đây là ví dụ phân loại theo rủi ro, không phải quy tắc chung của mọi công ty. Trước khi ký nghiệm thu, hãy ghi từng mục Đạt / Chưa đạt / Không áp dụng và đối chiếu tiêu chí đánh giá website doanh nghiệp, checklist bàn giao website.
Khi nào cần kiểm tra lại website?
Nên thử lại các chức năng chính sau khi đổi giao diện, cập nhật WordPress hoặc plugin, sửa menu, biểu mẫu, giỏ hàng, cài công cụ chat hoặc thay trang đích quảng cáo. Có thể đưa các mốc kiểm thử vào quy trình thiết kế website; không chờ khách báo lỗi mới kiểm tra.
Câu hỏi thường gặp
Website đã Responsive thì có cần thử điện thoại thật không?
Có. Responsive tập trung vào bố cục, còn thiết bị thật giúp phát hiện lỗi cảm ứng, bàn phím, Safari, biểu mẫu và kết nối. Nên kết hợp giả lập với kiểm thử thực tế.
Cần thử bao nhiêu loại thiết bị?
Không có con số cố định. Hãy ưu tiên thiết bị khách đang sử dụng, chức năng quan trọng và cam kết trong hợp đồng. Không thể tuyên bố tương thích mọi thiết bị chỉ sau vài ảnh chụp màn hình.
Điểm PageSpeed cao có đủ để nghiệm thu?
Chưa đủ. Tốc độ và Core Web Vitals không chứng minh nút gọi, biểu mẫu, thanh toán hoặc hệ thống nhận đơn hoạt động. Cần thử hoàn tất nhiệm vụ.
Bước tiếp theo cho website doanh nghiệp
Trước khi nhận bàn giao, hãy yêu cầu đơn vị thiết kế cho bạn thử trực tiếp các hành động chính trên điện thoại. Nếu đang cần cải thiện luồng nhận khách, xem hướng dẫn Landing Page; nếu cần nâng cấp toàn website, có thể trao đổi với dịch vụ thiết kế website chuyên nghiệp về phạm vi kiểm tra và nghiệm thu.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.