Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một website bán hàng. Trên máy tính của bạn — Chrome mới nhất, màn hình 27 inch, macOS — mọi thứ chạy mượt như nhung. Bạn tự tin bấm release. Ba ngày sau, bộ phận chăm sóc khách hàng gửi cho bạn một loạt ảnh chụp màn hình: nút "Thanh toán" bị đè lên phần chân trang trên iPhone SE, chữ tiếng Việt hiển thị lỗi font trên một chiếc Samsung đời cũ, và toàn bộ layout vỡ tan trên trình duyệt mặc định của điện thoại Oppo mà cô nhân viên bán hàng ở Cần Thơ đang dùng.
Đây chính là cơn ác mộng mà Compatibility Testing (kiểm thử tính tương thích) sinh ra để ngăn chặn. Vấn đề cốt lõi rất đơn giản để phát biểu nhưng cực khó để giải quyết: phần mềm của bạn không chạy trong một môi trường duy nhất, mà phải chạy trên vô số tổ hợp của trình duyệt (browser) × hệ điều hành (OS) × thiết bị (device). Mỗi tổ hợp là một môi trường thực thi khác nhau, với những đặc tính render, kích thước màn hình, engine JavaScript và khả năng phần cứng riêng.
Bài toán khó ở chỗ: số tổ hợp bùng nổ theo cấp số nhân. Chỉ cần 5 trình duyệt × 4 phiên bản OS × 10 dòng thiết bị là bạn đã có 200 môi trường. Test hết tất cả là bất khả thi cả về thời gian lẫn chi phí. Vì vậy, năng lực thật sự của một tester không phải là "test tất cả", mà là biết cách xây dựng một ma trận ưu tiên dựa trên dữ liệu người dùng thực tế — để với nguồn lực hữu hạn, bạn phủ được phần lớn rủi ro. Đây là kỹ năng phân biệt tester nghiệp dư với tester chuyên nghiệp, và đó là trọng tâm của bài học này.
Khái niệm cốt lõi
Compatibility Testing là gì?
Compatibility Testing là loại kiểm thử phi chức năng (non-functional testing) nhằm xác minh phần mềm hoạt động đúng và nhất quán trên các môi trường khác nhau. Nó không kiểm tra "logic nghiệp vụ có đúng không" (đó là việc của functional testing), mà kiểm tra "cùng một chức năng đúng đó có hiển thị và vận hành ổn định trên mọi môi trường mục tiêu không".
Ta thường chia thành hai nhánh:
- Backward compatibility: phần mềm chạy tốt trên các phiên bản cũ hơn (ví dụ: web vẫn dùng được trên Chrome cách đây 2 năm, app vẫn cài được trên Android 9).
- Forward compatibility: phần mềm vẫn ổn trên các phiên bản mới sắp ra (khó test hơn vì môi trường tương lai chưa tồn tại, thường chỉ test được với bản beta).
Ba trục của ma trận tương thích
Với ứng dụng web, ba biến số chính cần cân nhắc:
- Browser: Chrome, Safari, Firefox, Edge, và các trình duyệt trên di động như Chrome Mobile, Safari iOS, Samsung Internet, Cốc Cốc (rất phổ biến ở Việt Nam). Mỗi trình duyệt dùng một rendering engine — Chrome/Edge dùng Blink, Safari dùng WebKit, Firefox dùng Gecko — nên cùng một dòng CSS có thể render khác nhau.
- OS / phiên bản: Windows 10/11, macOS, iOS 15/16/17, Android 10/11/12/13/14. Phiên bản OS ảnh hưởng đến trình duyệt nào chạy được và các API hệ thống (camera, thông báo, chia sẻ file).
- Device / kích thước màn hình: từ điện thoại nhỏ (iPhone SE, 375px), tablet, đến desktop lớn. Không chỉ độ rộng, mà còn độ phân giải (DPI/retina), tỉ lệ khung hình, và có "tai thỏ"/notch hay không.
Các loại tương thích khác cần lưu ý
Ngoài trục browser/OS/device, kiểm thử tương thích còn bao gồm: network compatibility (mạng 3G/4G/WiFi — chi tiết ở bài về mạng yếu), hardware compatibility (RAM thấp, CPU yếu), và software compatibility (app cùng tồn tại với phần mềm diệt virus, VPN, extension). Trong bài này ta tập trung vào ba trục chính vì chúng chiếm phần lớn bug tương thích thực tế.
Compatibility Matrix mẫu (web)
Đây là trái tim của bài học. Một ma trận tương thích là bảng liệt kê các tổ hợp môi trường mà bạn cam kết hỗ trợ, kèm mức độ ưu tiên. Ví dụ ma trận cho một website thương mại điện tử Việt Nam:
| Môi trường | Trình duyệt | Độ rộng | Ưu tiên | Ghi chú |
|---|---|---|---|---|
| Android (chiếm ~65% traffic) | Chrome Mobile mới nhất | 360–412px | P0 | Tổ hợp phổ biến nhất |
| iOS | Safari iOS 16–17 | 375–430px | P0 | Nhóm chi tiêu cao |
| Windows | Chrome desktop | 1366–1920px | P0 | Nhân viên, mua ban ngày |
| Android | Samsung Internet | 360–412px | P1 | Máy Samsung rất phổ biến |
| Windows | Cốc Cốc | 1366px | P1 | Đặc thù VN |
| Windows | Edge | 1366px | P2 | Người dùng doanh nghiệp |
| Android cũ (v9–10) | Chrome Mobile | 360px | P2 | Máy giá rẻ, RAM thấp |
| macOS | Safari desktop | 1440px | P2 | Ít traffic nhưng khách VIP |
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT và cú vấp trên iPhone SE
Một sàn thương mại điện tử tại TP.HCM (giả định, quy mô tương tự các sàn nội địa) chạy chiến dịch Flash Sale 12/12. Đội dev test toàn bộ trên iPhone 14 Pro và Chrome desktop, mọi thứ hoàn hảo. Nhưng khi lên sản xuất, tỉ lệ hoàn tất thanh toán tụt bất thường vào giờ vàng.
Điều tra ra: trên iPhone SE (màn hình chỉ 375px, vẫn còn khá phổ biến trong phân khúc người dùng phổ thông), nút "Đặt hàng" bị thanh điều hướng của Safari iOS che mất do dev dùng 100vh cố định mà không tính đến thanh công cụ động của Safari. Khoảng 8% người dùng — tương ứng hàng nghìn đơn hàng trong ngày Sale — không bấm được nút.
Bài học: Traffic lớn không đồng nghĩa với "thiết bị cao cấp". Một phần trăm nhỏ trên tổng lượng người dùng khổng lồ vẫn là con số doanh thu rất lớn. iPhone SE và các máy màn hình nhỏ bắt buộc phải nằm trong danh sách P0, và cần test với thanh công cụ trình duyệt thật chứ không chỉ chế độ giả lập.
Ví dụ 2 — Ngân hàng số và trình duyệt Cốc Cốc
Một ngân hàng số triển khai tính năng eKYC (định danh điện tử) trên web. Đội QA test đủ Chrome, Safari, Firefox, Edge và pass hết. Sau khi ra mắt, tổng đài nhận được cụm khiếu nại: "không mở được camera để chụp CCCD".
Truy vết ra tất cả đều dùng Cốc Cốc — trình duyệt Việt Nam có thị phần đáng kể trên desktop trong nước. Một phiên bản Cốc Cốc xử lý quyền truy cập camera khác với Chrome gốc dù cùng nền Chromium, khiến luồng eKYC treo. Vì đội QA không đưa Cốc Cốc vào ma trận (họ mặc định "Cốc Cốc = Chromium = Chrome, khỏi cần test"), lỗi lọt qua hoàn toàn.
Bài học: Không được suy diễn "cùng engine thì hành vi giống nhau". Với thị trường Việt Nam, Cốc Cốc và Samsung Internet là hai trình duyệt bắt buộc cân nhắc vì thị phần thực tế, đặc biệt cho các luồng nhạy cảm dùng API hệ thống (camera, thông báo, thanh toán).
Ví dụ 3 — Startup fintech và ma trận thiết bị Đông Nam Á
Một startup ví điện tử mở rộng từ Việt Nam sang Indonesia và Philippines. Đội QA vốn quen test trên máy Android tầm trung, giả định người dùng khu vực cũng tương tự. Khi ra mắt, app crash liên tục ở Indonesia.
Phân tích crash log cho thấy phần lớn thiết bị là Android giá rẻ RAM 2–3GB với các dòng máy nội địa ít gặp ở Việt Nam, chạy Android phiên bản cũ. App bị OutOfMemory khi tải danh sách giao dịch dài. Ma trận thiết bị cũ hoàn toàn không phản ánh thị trường mới.
Bài học: Ma trận tương thích phải bám theo dữ liệu của từng thị trường, không copy nguyên từ thị trường cũ. Khi mở rộng địa lý, việc đầu tiên là kéo báo cáo thiết bị/OS thực tế của thị trường đó (qua Firebase, Google Play Console, hoặc GSMArena về xu hướng máy phổ biến) rồi dựng lại ma trận.
Hướng dẫn từng bước
Đây là quy trình xây dựng và thực thi kiểm thử tương thích một cách có hệ thống:
Bước 1 — Thu thập dữ liệu người dùng thật. Vào Google Analytics (mục Tech / Audience) hoặc Firebase để lấy phân bố browser, OS, thiết bị, độ phân giải màn hình. Nếu là sản phẩm mới chưa có dữ liệu, dùng thống kê thị trường Việt Nam (StatCounter cho browser share) làm mốc khởi đầu.
Bước 2 — Áp quy tắc phủ (ví dụ 80/20). Sắp xếp các tổ hợp theo lượng người dùng giảm dần. Chọn nhóm tổ hợp phủ được khoảng 80–90% người dùng làm P0/P1. Phần đuôi dài còn lại xếp P2 hoặc "best effort".
Bước 3 — Dựng Compatibility Matrix. Lập bảng như mẫu ở trên, ghi rõ mức ưu tiên và ghi chú lý do. Đây là tài liệu sống, cần review lại mỗi quý vì thị phần thiết bị thay đổi.
Bước 4 — Chọn công cụ test. Với đội nhỏ không thể mua đủ máy thật:
- BrowserStack / LambdaTest / Sauce Labs: cho thuê hàng nghìn tổ hợp browser/OS/device thật qua cloud.
- Chrome DevTools Device Mode: giả lập nhanh kích thước màn hình (chỉ để sàng lọc sơ bộ, KHÔNG thay thế máy thật).
- Máy thật (real device): bắt buộc cho các tổ hợp P0, đặc biệt luồng thanh toán, camera, thông báo.
Bước 6 — Thực thi và ghi nhận có kèm bằng chứng. Luôn chụp screenshot/quay màn hình ghi rõ tổ hợp môi trường (browser + phiên bản + OS + thiết bị). Bug tương thích rất khó tái hiện nếu thiếu thông tin môi trường chính xác.
Bước 7 — Đối chiếu và báo cáo theo ma trận. Trình bày kết quả dạng ma trận có màu (xanh = pass, vàng = lỗi nhỏ, đỏ = fail) để stakeholder thấy ngay độ phủ và rủi ro còn tồn đọng.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ test trên máy của dev/QA. Đội ngũ kỹ thuật thường dùng máy cao cấp, mạng khỏe, Chrome mới nhất. Đây là "vùng an toàn giả tạo". Mẹo: mỗi đội nên có một "máy khổ" — một điện thoại Android giá rẻ, RAM thấp, đời cũ — để test những gì gần với người dùng phổ thông nhất.
Lỗi 2 — Nhầm giả lập với máy thật. Chrome DevTools Device Mode chỉ đổi kích thước viewport, nó KHÔNG mô phỏng đúng engine Safari iOS, không có thanh công cụ động, không phản ánh hiệu năng phần cứng thật. Nhiều bug (như bug 100vh ở ví dụ 1) chỉ hiện trên máy thật. Mẹo: dùng giả lập để sàng lọc nhanh, nhưng mọi tổ hợp P0 phải verify trên máy thật hoặc cloud device thật.
Lỗi 3 — Bỏ quên font và tiếng Việt. Nhiều thiết bị Android cũ thiếu font đầy đủ, khiến ký tự có dấu tiếng Việt bị vỡ hoặc hiển thị ô vuông. Mẹo: luôn có test case kiểm tra chuỗi tiếng Việt đầy đủ dấu ("Nguyễn Thị Ánh Nguyệt", "Đường Cống Quỳnh") trên các máy trong ma trận.
Lỗi 4 — Ma trận đóng băng. Lập ma trận một lần rồi dùng mãi 2 năm. Thị phần thiết bị thay đổi liên tục. Mẹo: đặt lịch review ma trận mỗi quý dựa trên analytics mới.
Lỗi 5 — Suy diễn "cùng engine, cùng hành vi". Như ví dụ Cốc Cốc cho thấy, các trình duyệt cùng nền Chromium vẫn có khác biệt về quyền, extension, cấu hình. Mẹo: với luồng nhạy cảm, test đích danh từng trình duyệt trong ma trận, đừng gộp.
Mẹo tối ưu công sức: Không cần chạy full regression trên mọi tổ hợp. Chọn một tổ hợp "reference" (thường Chrome desktop) để chạy đầy đủ chức năng, còn các tổ hợp khác chỉ chạy bộ test tập trung vào rủi ro tương thích (hiển thị + luồng cốt lõi). Đây là cách cân bằng độ phủ và chi phí.
Bài tập thực hành
Bài 1 — Dựng ma trận từ dữ liệu. Giả sử bạn có analytics của một web bán khóa học tại Việt Nam: 62% Android Chrome, 18% iOS Safari, 9% Windows Chrome, 5% Cốc Cốc, 3% Samsung Internet, 3% còn lại. Hãy lập một Compatibility Matrix với cột Ưu tiên (P0/P1/P2) và giải thích lý do xếp hạng cho từng dòng. Xác định ngưỡng phủ 90% cần bao nhiêu tổ hợp.
Bài 2 — Săn bug tương thích. Mở một website bất kỳ (ví dụ trang chủ trường bạn hoặc một shop online) bằng Chrome DevTools Device Mode. Lần lượt chọn iPhone SE, Galaxy S8, và một tablet. Ghi lại tối thiểu 3 vấn đề hiển thị (chữ tràn, nút bị che, ảnh vỡ tỉ lệ) kèm screenshot và ghi rõ tổ hợp môi trường.
Bài 3 — Test tiếng Việt. Chuẩn bị một form nhập liệu có tên đầy đủ dấu và địa chỉ tiếng Việt. Test trên ít nhất 2 thiết bị khác nhau (một iOS, một Android nếu có). Kiểm tra: chữ có dấu hiển thị đúng không, khi nhập có bị nhảy dấu không, dữ liệu lưu và hiển thị lại có nguyên vẹn không.
Bài 4 — Viết báo cáo ma trận. Từ kết quả Bài 2, trình bày một bảng ma trận có tô màu pass/lỗi nhỏ/fail, kèm khuyến nghị: tổ hợp nào chặn release, tổ hợp nào chấp nhận được.
Tóm tắt
- Compatibility Testing xác minh phần mềm chạy đúng và nhất quán trên nhiều tổ hợp browser × OS × device; đây là kiểm thử phi chức năng, tập trung vào hiển thị và tính ổn định qua các môi trường.
- Số tổ hợp bùng nổ theo cấp số nhân nên test hết là bất khả thi — chìa khóa là xây ma trận ưu tiên dựa trên dữ liệu người dùng thật, không phải cảm tính.
- Compatibility Matrix phân loại tổ hợp theo P0/P1/P2, giúp tập trung nguồn lực vào nơi rủi ro và giá trị cao nhất; đây là tài liệu sống cần review định kỳ mỗi quý.
- Bối cảnh Việt Nam có đặc thù riêng: Cốc Cốc, Samsung Internet, máy Android giá rẻ RAM thấp, và font tiếng Việt đều là những điểm bắt buộc cân nhắc.
- Giả lập không thay thế máy thật: dùng DevTools để sàng lọc, nhưng mọi tổ hợp P0 phải verify trên thiết bị thật hoặc cloud device (BrowserStack/LambdaTest).
- Ba bài học lớn từ thực tế: traffic lớn không có nghĩa thiết bị cao cấp; đừng suy diễn "cùng engine cùng hành vi"; và ma trận phải bám theo dữ liệu từng thị trường khi mở rộng địa lý.