Device matrix và OS support policy

Vì sao "đã test trên Android" là một câu rỗng

Trên web, môi trường chạy gần như đồng nhất. Trên mobile thì không: cùng một build chạy trên máy 8GB RAM màn 6,7 inch Android 16, và trên máy 3GB RAM màn 5 inch Android 12 đã cài đầy app. Hai môi trường đó khác nhau đủ để một build chạy mượt ở máy này và freeze ở máy kia.

Vì vậy kết quả test phải ghi được device nào, OS version nào. Và để ghi được thì trước hết dự án phải có một device matrix chính thức. Danh sách máy đội đang có, kèm mã máy để dán vào báo lỗi: Thiết bị test.

Ba tier device

Không test đều tất cả device. Test theo actual user distribution cộng với mức risk.

Tier	Gồm những gì	Test khi nào	Cách có device
Tier 1	5–8 device phủ phần lớn user, cộng một máy low-end	Mọi release, và mọi hạng mục có màn hình	Device thật, đội giữ
Tier 2	Device phổ biến còn lại, resolution và kích thước màn lạ	Regression suite trước release	Device thật hoặc device cloud
Tier 3	Device ít user, device cũ còn trong diện hỗ trợ	Automation, định kỳ, không chặn release	Device cloud
Deprecated	Dưới ngưỡng cắt đã công bố	Không test	—

Một máy low-end thật nằm ở Tier 1 là bắt buộc, không phải tuỳ chọn. Đo performance trên máy cao cấp của dev rồi kết luận là nhanh là cách phổ biến nhất để tự lừa mình.

OS support policy

Nguyên tắc: hỗ trợ theo tỷ lệ user thật, không theo cảm tính về độ mới.

Platform	Mức hỗ trợ khởi điểm	Ngưỡng cắt
iOS	Current và current − 2	Nhóm version chiếm dưới 2% user trong hai quý liên tiếp
Android	Current và current − 3	Nhóm version chiếm dưới 2% user trong hai quý liên tiếp

Android cần phủ rộng hơn vì user nâng cấp chậm hơn. Con số 2% là ngưỡng khởi điểm — sau hai quý có dữ liệu thật từ App Store Connect và Play Console thì chỉnh lại cho đúng với tập user của Alliance App.

Deprecate một OS version phải báo trước một release và ghi vào release notes. Cắt im lặng thì user chỉ biết khi app ngừng chạy.

Beta OS testing

Đây là phần bị bỏ quên nhiều nhất, và nó gây ra loại incident tệ nhất: app đang chạy tốt thì hỏng hàng loạt trong một đêm vì user cập nhật OS, mà đội không hề đụng vào code.

Mỗi năm Apple và Google đều có chu kỳ beta kéo dài vài tháng trước bản public. Lịch làm việc với chu kỳ đó:

Mốc	Việc phải làm
Beta đầu tiên	Cài lên một device Tier 1, chạy critical path suite, ghi nhận thứ gãy
Giữa chu kỳ	Chạy full regression, mở hạng mục fix cho thứ đã gãy
Trước ngày public release	Phải có một build tương thích sẵn sàng, không phải bắt đầu fix

Chi phí thấp — một device và vài giờ mỗi chu kỳ. Chi phí của việc không làm là một incident diện rộng không có cách nào chặn trước.

Ai giữ device matrix và cập nhật khi nào

Bài này giữ chính sách: tier nghĩa là gì, OS version nào còn hỗ trợ, cắt theo ngưỡng nào. Danh sách máy cụ thể nằm ở Thiết bị test: máy nào, ai giữ, OS nào, kiểm kê lần cuối khi nào. Tách hai thứ ra vì chúng đổi theo hai nhịp khác nhau — chính sách đổi mỗi quý, danh sách máy đổi mỗi lần mua máy, đổi người giữ hay máy hỏng. Bản yêu cầu gửi cho người giữ máy — cần những trường nào và vì sao cần — ở Vì sao cần kiểm kê thiết bị test.

Chủ kỹ thuật sở hữu cả hai, cập nhật mỗi quý dựa trên dữ liệu thật từ App Store Connect và Play Console, không dựa vào thị phần chung của thị trường.

Mỗi lần cập nhật ghi rõ: device nào vào, device nào ra, vì sao. Một device bị loại khỏi Tier 1 nghĩa là từ đó bug chỉ xảy ra trên device đó không còn là bug chặn release — đó là một quyết định có hậu quả, nên nó phải có dấu vết.

Giới hạn

Không mua hết device được, và cũng không nên. Tier 1 là device thật; từ Tier 2 trở đi dùng device cloud. Device cloud không thay được device thật ở các kịch bản cần cảm nhận: độ mượt khi scroll, độ trễ khi chạm, máy nóng, hao pin.
Matrix rộng ra thì chi phí mỗi release tăng theo. Rộng thêm một tier phải trả lời được: tier đó đã từng bắt được bug nào chưa? Chưa bao giờ bắt được gì thì thu hẹp lại.
Device matrix là điều kiện cần, không phải điều kiện đủ. Device đúng mà kịch bản test sai thì vẫn lọt bug — xem Kiểm thử đặc thù mobile.