Mở đầu — vì sao bài này quan trọng
Nếu bạn đang bước chân vào nghề QA (Quality Assurance) trong năm 2026, có một sự thật khó chối cãi: người dùng Việt Nam sống trên điện thoại. Theo số liệu ngành, hơn 70% lưu lượng truy cập của các nền tảng thương mại điện tử như Shopee, Lazada, Tiki đến từ ứng dụng di động chứ không phải web. MoMo có hơn 30 triệu người dùng, và gần như 100% giao dịch của họ diễn ra trên app. Nói cách khác, chất lượng của một sản phẩm số ở Việt Nam ngày nay phần lớn được quyết định trên màn hình 6 inch.
Vậy mà rất nhiều bạn QA mới vào nghề lại mang tư duy kiểm thử web sang kiểm thử mobile — và vấp ngã. Họ nghĩ "cũng là một cái app có nút bấm, có form, mình cứ click qua từng màn hình là xong". Đó là một sai lầm nghiêm trọng. Mobile testing là một thế giới riêng, với những ràng buộc, rủi ro và kỹ thuật hoàn toàn khác. Một app có thể chạy hoàn hảo trên iPhone 15 của bạn nhưng crash ngay khi mở trên chiếc Samsung Galaxy A05 giá rẻ mà đại đa số người dùng phổ thông đang cầm.
Bài học đầu tiên này không dạy bạn viết một dòng code test nào cả. Thay vào đó, nó xây cho bạn bản đồ tổng quan — hiểu mobile testing là gì, khác web ra sao, và tại sao nó khó. Nắm được bức tranh lớn này, bạn sẽ hiểu vì sao 59 bài học tiếp theo lại tồn tại và mỗi bài giải quyết mảnh ghép nào. Đây là nền móng. Hãy đọc kỹ.
Khái niệm cốt lõi
Mobile testing là gì?
Mobile testing là quá trình kiểm thử một ứng dụng chạy trên thiết bị di động (điện thoại, máy tính bảng) để đảm bảo nó hoạt động đúng chức năng, đủ nhanh, ổn định và mang lại trải nghiệm tốt trong muôn vàn điều kiện thực tế mà thiết bị di động phải đối mặt: mạng chập chờn, pin yếu, bị gọi điện xen ngang, xoay màn hình, hết bộ nhớ, chuyển từ nền sáng sang nền tối...
Có ba loại ứng dụng di động mà bạn sẽ gặp, và mỗi loại kiểm thử hơi khác nhau:
- Native app: viết bằng ngôn ngữ riêng của nền tảng (Swift/Objective-C cho iOS, Kotlin/Java cho Android). Nhanh, mượt, truy cập sâu vào phần cứng. Ví dụ: app MoMo, app VietinBank iPay.
- Hybrid/Cross-platform app: viết một lần chạy hai nền tảng, dùng React Native hoặc Flutter. Ví dụ: nhiều app fintech và startup dùng để tiết kiệm chi phí.
- Mobile web / PWA: chạy trong trình duyệt điện thoại, không cần cài đặt.
Sự khác biệt cốt lõi: Mobile vs Web Testing
Đây là phần quan trọng nhất của bài. Hãy nhìn bảng so sánh dưới đây — nó chính là "linh hồn" giải thích vì sao mobile testing khó hơn web:
| Khía cạnh | Web Testing | Mobile Testing |
|---|---|---|
| Thiết bị | Vài trình duyệt (Chrome, Firefox, Safari, Edge) | Hàng nghìn thiết bị khác nhau về chip, RAM, màn hình |
| Hệ điều hành | Windows, macOS — vài phiên bản | iOS + Android, mỗi bên nhiều phiên bản còn dùng song song |
| Kích thước màn hình | Tương đối lớn, ít đa dạng | Từ màn 5 inch đến máy tính bảng, đủ mọi tỉ lệ và mật độ điểm ảnh |
| Nhập liệu | Chuột + bàn phím | Cảm ứng, vuốt, chạm giữ, đa điểm, bàn phím ảo, giọng nói |
| Kết nối mạng | Thường ổn định (LAN, WiFi) | Chập chờn: 3G, 4G, 5G, WiFi yếu, mất sóng trong thang máy |
| Ngắt quãng | Hiếm | Liên tục: cuộc gọi đến, thông báo, báo pin yếu, chuyển app |
| Tài nguyên | Máy tính mạnh, ít lo | Pin, bộ nhớ, nhiệt độ máy đều là ràng buộc |
| Quyền (permission) | Ít | Nhiều: camera, vị trí, danh bạ, thông báo — người dùng có thể từ chối |
| Cập nhật | Refresh trình duyệt là xong | Phải qua App Store / Google Play, người dùng có thể không cập nhật |
Thách thức 1: Device Fragmentation (Phân mảnh thiết bị)
Đây là "cơn ác mộng" kinh điển của mobile QA, đặc biệt với Android. Trên thế giới có hơn 24.000 mẫu thiết bị Android khác nhau, đến từ hàng trăm hãng, chạy đủ mọi phiên bản hệ điều hành từ Android 8 cũ kỹ đến Android 15 mới nhất. Mỗi hãng lại "chế" lại giao diện (Samsung One UI, Xiaomi MIUI, Oppo ColorOS...) khiến hành vi của cùng một API có thể khác nhau. iOS đỡ hơn nhiều vì Apple kiểm soát cả phần cứng lẫn phần mềm, nhưng vẫn có sự khác biệt giữa iPhone SE nhỏ và iPhone Pro Max lớn, giữa iOS 16 và iOS 18.
Với QA, phân mảnh nghĩa là: bạn không bao giờ test được hết mọi thiết bị. Nghệ thuật nằm ở việc chọn đúng tập thiết bị đại diện dựa trên dữ liệu người dùng thực.
Thách thức 2: Điều kiện môi trường thay đổi liên tục
App web thường sống trong môi trường ổn định. App mobile thì không. Người dùng mở app khi đang đi xe buýt (mạng chập chờn), khi pin còn 5%, khi vừa nhận cuộc gọi, khi vặn màn hình sáng tối. Mỗi biến số này đều có thể làm lộ ra bug. Một QA giỏi phải chủ động tạo ra những điều kiện "khắc nghiệt" này chứ không chỉ test trong phòng lạnh với WiFi mạnh.
Thách thức 3: Vòng đời ứng dụng và ngắt quãng
Trên mobile, app liên tục bị đẩy xuống nền (background) rồi kéo lên lại (foreground). Người dùng đang điền form thanh toán thì có cuộc gọi đến — khi họ quay lại, dữ liệu còn nguyên không? App đang tải ảnh thì bị chuyển sang app khác — quay lại nó có tải tiếp hay bắt đầu lại từ đầu? Đây là loại bug rất đặc trưng của mobile mà web hầu như không có.
Thách thức 4: Ràng buộc tài nguyên
Pin, bộ nhớ, nhiệt độ, dung lượng lưu trữ — tất cả đều hữu hạn trên điện thoại. Một app ngốn pin, làm nóng máy hay chiếm quá nhiều RAM sẽ bị người dùng gỡ ngay và đánh giá 1 sao. QA mobile phải để mắt tới những chỉ số này, điều mà web QA gần như không bao giờ quan tâm.
Tình huống thực tế
Tình huống 1: Bug chỉ xuất hiện trên máy giá rẻ ở tỉnh
Một công ty giao đồ ăn (tạm gọi là FastBite) tại TP.HCM ra mắt tính năng đặt món mới. Đội QA test kỹ trên iPhone 14 và Samsung S23 của công ty, mọi thứ hoàn hảo, họ cho phát hành. Ba ngày sau, bộ phận chăm sóc khách hàng ngập trong phàn nàn: người dùng ở các tỉnh không đặt được món, app đứng hình ở màn hình thanh toán.
Điều tra ra mới thấy: đa số khách ở tỉnh dùng máy Android giá rẻ 2-3 triệu đồng với RAM 3GB. Trên những máy này, màn hình thanh toán render danh sách món ăn kèm ảnh khiến app ngốn RAM, hệ điều hành "giết" tiến trình khi app xuống nền để nhận thông báo, và khi quay lại app crash. Máy cao cấp RAM 8-12GB của đội QA không bao giờ gặp cảnh này.
Bài học rút ra: Thiết bị test phải phản ánh thiết bị của người dùng thật, không phải thiết bị xịn nhất công ty có. Đây chính là hệ quả trực tiếp của device fragmentation và ràng buộc bộ nhớ.
Tình huống 2: Ví điện tử và cuộc gọi xen ngang
Một ví điện tử (tạm gọi PayViet) có luồng xác thực OTP khi chuyển tiền. Người dùng nhập số tiền, bấm chuyển, app gửi OTP qua SMS. Trong khoảnh khắc chờ SMS, nhiều người dùng nhận được... chính cuộc gọi từ tổng đài ngân hàng, hoặc app tự chuyển sang app tin nhắn để copy mã.
Đội QA ban đầu chỉ test trong điều kiện lý tưởng: nhập OTP thủ công, không rời app. Khi lên production, hàng loạt giao dịch "treo" vì khi người dùng rời app đi lấy OTP rồi quay lại, session giao dịch đã bị reset, tiền không chuyển nhưng cũng không báo lỗi rõ ràng. Khách hoảng loạn vì tưởng mất tiền.
Bài học rút ra: Vòng đời app (background/foreground) và ngắt quãng là kịch bản BẮT BUỘC phải test với app tài chính. Bug này không thuộc về "chức năng" theo nghĩa truyền thống mà thuộc về đặc thù môi trường mobile.
Tình huống 3: Grab và mạng chập chờn trong thang máy
Một tài xế công nghệ mở app nhận cuốc trong khi di chuyển liên tục: từ tầng hầm giữ xe (mất sóng) lên mặt đất (4G), vào toà nhà (WiFi yếu). App phải giữ được trạng thái cuốc xe, không được "quên" chuyến đang chạy khi mạng chập chờn. Với một ứng dụng thật như Grab, nhóm QA phải chủ động mô phỏng chuyển đổi mạng đột ngột, mất mạng giữa chừng và mạng cực chậm (2G) để đảm bảo app không mất dữ liệu chuyến đi.
Bài học rút ra: Mạng trên mobile không bao giờ được coi là "luôn có và luôn nhanh". QA phải test cả các trạng thái mạng xấu — điều mà web testing hiếm khi làm.
Hướng dẫn từng bước
Khi bắt đầu tiếp cận kiểm thử một ứng dụng mobile mới, hãy đi theo trình tự tư duy sau. Đây là khung định hướng, các kỹ thuật cụ thể sẽ có ở những bài sau.
Bước 1 — Xác định loại app. App bạn test là native, hybrid hay mobile web? Điều này quyết định công cụ và cách tiếp cận. Hãy hỏi đội dev nếu chưa rõ.
Bước 2 — Hiểu người dùng thật. Mở dữ liệu analytics (nếu có) hoặc hỏi đội sản phẩm: người dùng chủ yếu dùng iOS hay Android? Phiên bản OS nào phổ biến? Dòng máy nào chiếm đa số? Ở Việt Nam, đừng bất ngờ nếu phần lớn là Android tầm trung và giá rẻ.
Bước 3 — Lập ma trận thiết bị (device matrix). Dựa trên dữ liệu bước 2, chọn một tập thiết bị đại diện. Ví dụ: 1 iPhone cũ + 1 iPhone mới, 1 Android cao cấp + 1 Android tầm trung + 1 Android giá rẻ. Nguyên tắc: bao phủ được các "cực" — cũ/mới, mạnh/yếu, màn to/nhỏ.
Bước 4 — Liệt kê các điều kiện môi trường cần test. Ghi ra danh sách: mạng (WiFi tốt, 4G, 3G, mất mạng), pin (đầy, yếu), ngắt quãng (cuộc gọi, thông báo), vòng đời (chuyển nền/tiền cảnh), xoay màn hình, nền sáng/tối.
Bước 5 — Phân loại phạm vi test. Với mỗi tính năng, tự hỏi ba câu: (a) Nó có chạy đúng chức năng không? (b) Nó có chịu được điều kiện môi trường xấu không? (c) Nó có tốn tài nguyên bất thường không? Ba câu hỏi này chính là bộ khung tư duy mobile QA.
Bước 6 — Ưu tiên rủi ro. Bạn không test được hết. Hãy tập trung nguồn lực vào luồng quan trọng nhất (thanh toán, đăng nhập, chức năng cốt lõi) trên tập thiết bị phổ biến nhất trước.
Lỗi thường gặp & mẹo
Lỗi 1: Chỉ test trên máy xịn của công ty. Đây là cái bẫy phổ biến nhất. Máy iPhone Pro Max hay Samsung Ultra của đội QA không đại diện cho người dùng phổ thông. Mẹo: luôn giữ trong đội ít nhất một chiếc Android giá rẻ, RAM thấp làm "máy chứng thực" trước khi phát hành.
Lỗi 2: Coi mobile testing như web testing có màn hình nhỏ. Nếu bạn chỉ click qua từng màn hình, bạn bỏ sót toàn bộ nhóm bug đặc trưng của mobile: ngắt quãng, mạng, vòng đời, pin, quyền. Mẹo: mỗi khi test một luồng, hãy cố tình "phá" nó — tắt mạng giữa chừng, chuyển app rồi quay lại, xoay màn hình.
Lỗi 3: Bỏ qua điều kiện mạng xấu. Test trong văn phòng WiFi mạnh khiến bạn ảo tưởng app ổn định. Mẹo: dùng chế độ giả lập mạng chậm hoặc đơn giản là bật chế độ máy bay giữa lúc app đang tải dữ liệu để xem nó xử lý ra sao.
Lỗi 4: Không tính đến quyền bị từ chối. Người dùng thật thường bấm "Không cho phép" khi app xin quyền camera hay vị trí. Nếu app crash khi bị từ chối quyền, đó là bug nghiêm trọng. Mẹo: luôn test cả hai nhánh — cho phép và từ chối quyền.
Mẹo vàng: Hãy nghĩ như một người dùng bận rộn, mạng yếu, máy yếu, tay đang bận — chứ đừng nghĩ như một kỹ sư ngồi bàn với WiFi mạnh và máy đầy pin. Sự đồng cảm với hoàn cảnh người dùng thật là kỹ năng số một của một mobile QA giỏi.
Bài tập thực hành
- Vẽ ma trận thiết bị của riêng bạn. Chọn một app bạn đang dùng hàng ngày (ví dụ Shopee, MoMo, Grab). Giả sử bạn là QA của app đó, hãy liệt kê 5 thiết bị bạn sẽ chọn để test và giải thích lý do chọn từng cái (dựa trên: nền tảng, phiên bản OS, phân khúc giá, kích thước màn hình).
- Săn bug môi trường. Lấy một app bất kỳ trên điện thoại bạn. Thực hiện một luồng đơn giản (ví dụ: tìm kiếm sản phẩm và thêm vào giỏ). Trong lúc làm, cố tình gây ba loại ngắt quãng: (a) bật chế độ máy bay giữa chừng, (b) chuyển sang app khác rồi quay lại, (c) xoay ngang màn hình. Ghi lại app phản ứng ra sao và liệu có hành vi nào bạn coi là bug.
- So sánh web vs mobile. Chọn một dịch vụ có cả bản web và bản app (ví dụ Tiki). Thử cùng một tác vụ trên cả hai. Viết ra 3 điểm khác biệt trong trải nghiệm và trong những điều bạn nghĩ QA phải kiểm tra ở bản mobile mà bản web không cần.
Tóm tắt
Mobile testing không phải là web testing thu nhỏ — nó là một lĩnh vực riêng với những thách thức đặc thù. Bốn trụ cột cần khắc cốt ghi tâm là: phân mảnh thiết bị (hàng nghìn máy khác nhau, đặc biệt trên Android), điều kiện môi trường thay đổi liên tục (mạng, pin, ngắt quãng), vòng đời app (chuyển nền/tiền cảnh dễ sinh bug), và ràng buộc tài nguyên (pin, RAM, nhiệt độ).
Bối cảnh Việt Nam càng làm những điều này quan trọng: đa số người dùng dùng Android tầm trung và giá rẻ, mạng không phải lúc nào cũng tốt, và các luồng tài chính (ví điện tử, thanh toán) đòi hỏi độ tin cậy tuyệt đối. Nguyên tắc tối thượng của người QA mobile là đồng cảm với hoàn cảnh thật của người dùng: máy yếu, mạng chập chờn, tay bận, dễ bị ngắt quãng.
Bài học này đã dựng nên bản đồ tổng quan. Từ đây, chúng ta sẽ đi sâu vào từng mảnh ghép: viết test case, dùng Appium để tự động hoá, kiểm thử hiệu năng, accessibility, thanh toán, và nhiều hơn nữa. Hãy giữ vững bức tranh lớn này trong đầu — nó sẽ giúp bạn hiểu vì sao mỗi kỹ thuật tiếp theo lại cần thiết.