Nếu bạn từng làm QA cho web, rồi chuyển sang mobile, chắc bạn đã thấm cái cảm giác "không gian bài toán" tự nhiên phình to gấp chục lần. Web thì có browser matrix để lo, nhưng mobile thì có cả một "vũ trụ" biến số: hàng trăm dòng máy Android từ Samsung, Xiaomi, Oppo, Vivo đến Google Pixel, mỗi hãng lại tùy biến Android theo custom ROM riêng (One UI, MIUI, ColorOS...), cộng thêm iOS với các đời iPhone từ SE đến Pro Max, chưa kể notch, Dynamic Island, foldable, tablet, và vô số biến thể về kết nối mạng, pin, permission, background execution.
Cái khó của mobile testing không nằm ở việc thiếu ý tưởng test case — mà nằm ở việc không đủ thời gian, không đủ thiết bị, và không đủ băng thông tư duy để cover hết những tổ hợp có khả năng gây lỗi thật. Đây chính là lúc AI phát huy giá trị: nó không thay bạn cầm máy test, nhưng nó giúp bạn tư duy có hệ thống hơn về ma trận thiết bị, sinh ra các kịch bản lỗi mà con người dễ quên (vì chúng "vô hình" trong lúc code chạy êm), và giúp bạn phân tích chéo giữa hai nền tảng nhanh hơn nhiều so với việc tự ngồi so sánh tay.
Trong bài này, chúng ta sẽ đi qua bốn mảng lớn: xây device matrix có ưu tiên, sinh kịch bản lỗi đặc thù mobile (connectivity, battery, permission), kiểm thử tính đồng nhất iOS/Android, và cuối cùng là deep link, push notification, background state — ba "điểm mù" kinh điển mà QA mobile hay bỏ sót.
Làm sao dùng AI để tạo device matrix test plan — phiên bản OS, kích thước màn hình, hướng xoay màn hình?
Trước khi nói tới prompt, cần thống nhất một điều: AI không biết analytics thật của app bạn. Nó không biết 60% người dùng của bạn đang dùng Android 13 trên màn hình 6.1 inch, hay 15% traffic đến từ iPhone SE 2020 màn hình nhỏ. Vì vậy, giá trị của AI trong bước này không phải là "phán" ra device matrix từ không khí, mà là giúp bạn biến dữ liệu thô (analytics, crash report, support ticket) thành một ma trận test có ưu tiên rõ ràng, đầy đủ logic, và không bỏ sót tổ hợp nguy hiểm.
Những thông tin đầu vào cần chuẩn bị trước khi prompt
Đây là bước mà nhiều bạn QA hay nhảy cóc — cứ mở AI lên và gõ "tạo device matrix cho tôi" rồi nhận về một bảng chung chung, vô dụng vì không gắn với sản phẩm thật. Trước khi prompt, hãy chuẩn bị:
- Dữ liệu phân phối thiết bị thực tế — export từ Google Play Console (Android vitals, device distribution) và App Store Connect (Analytics > Devices), hoặc từ Firebase Analytics / Mixpanel nếu app đã có tracking.
- Danh sách OS version support — minSdkVersion / targetSdkVersion trong
build.gradle, và Deployment Target trong Xcode project. - Danh sách tính năng nhạy cảm với thiết bị — ví dụ app có dùng camera, NFC, biometric, AR, foldable-aware layout không?
- Lịch sử bug liên quan đến thiết bị — nếu có Jira/Linear, lọc nhanh các ticket có tag "device-specific" hoặc từ khóa tên máy trong 6-12 tháng gần nhất.
- Ràng buộc thực tế của team — số lượng máy thật có trong phòng lab, có dùng device farm (BrowserStack, Firebase Test Lab, Sauce Labs) không, và budget thời gian cho regression mobile mỗi release.
Mẹo: Đừng đưa AI một danh sách thiết bị trống rồi hỏi "gợi ý giúp tôi" — hãy dán thẳng số liệu phân phối thật (dù chỉ là ảnh chụp màn hình Play Console rồi copy số ra text) vào prompt. AI dựa trên dữ liệu thật sẽ ưu tiên đúng hướng hơn AI dựa trên kiến thức chung về "thị trường Android phổ biến", vì thị trường chung khác hoàn toàn với tập người dùng cụ thể của app bạn.
Prompt: Generate a prioritized device matrix
Dưới đây là một prompt mẫu đầy đủ, bạn có thể copy và điền số liệu thật của app mình vào:
Bạn là một Senior Mobile QA Lead. Tôi cần bạn giúp xây dựng một device test matrix
có ưu tiên (P0/P1/P2) cho app [TÊN APP] dựa trên dữ liệu thực tế sau:
DỮ LIỆU PHÂN PHỐI THIẾT BỊ (từ Play Console, 90 ngày gần nhất):
- Android 14: 32% | Android 13: 28% | Android 12: 18% | Android 11: 12% | còn lại: 10%
- Top 5 dòng máy theo traffic: Samsung Galaxy A54, Samsung Galaxy S23,
Xiaomi Redmi Note 12, Oppo A78, Google Pixel 7
- Kích thước màn hình phổ biến nhất: 6.1"-6.5" (54%), 6.6"-6.9" (31%), <6.1" (10%), tablet (5%)
DỮ LIỆU PHÂN PHỐI THIẾT BỊ (từ App Store Connect):
- iOS 17: 61% | iOS 16: 24% | iOS 15: 10% | cũ hơn: 5%
- Top model: iPhone 13, iPhone 14, iPhone SE (2022), iPhone 15 Pro Max
RÀNG BUỘC:
- minSdkVersion = 26 (Android 8.0), targetSdkVersion = 34
- iOS Deployment Target = 15.0
- Team có 6 máy Android thật + 4 máy iOS thật trong lab, còn lại dùng
Firebase Test Lab / BrowserStack cho cloud testing
- App có dùng camera (KYC selfie), biometric login, và deep link từ email marketing
YÊU CẦU:
1. Đề xuất một ma trận thiết bị P0 (must-test mỗi release, tối đa 8 thiết bị)
với lý do rõ ràng cho từng lựa chọn (traffic %, OS fragmentation risk,
hoặc lịch sử bug).
2. Đề xuất ma trận P1 (test theo sprint/tháng, tối đa 12 thiết bị) bao gồm
các edge case như màn hình nhỏ nhất, notch/Dynamic Island, foldable.
3. Đề xuất ma trận P2 (test theo release lớn hoặc khi có thay đổi UI toàn app).
4. Với mỗi thiết bị P0, liệt kê thêm 3 tổ hợp orientation + font-scale
(ví dụ: portrait + font 100%, landscape + font 130%, split-screen nếu có)
cần test riêng vì đây là nơi layout dễ vỡ.
5. Trình bày kết quả dưới dạng bảng Markdown, có cột: Thiết bị, OS version,
Kích thước màn hình, Priority, Lý do chọn.
Khi nhận kết quả, đừng chấp nhận nguyên bảng đó làm final — hãy đọc kỹ phần "Lý do chọn" mà AI đưa ra, vì đây là nơi bạn phát hiện AI có đang suy luận đúng logic hay chỉ đang liệt kê máy phổ biến chung của thị trường (không gắn với data bạn đưa). Nếu thấy sai lệch, phản hồi lại ngay trong cùng conversation để AI điều chỉnh.
Generating an Android-specific fragmentation matrix
Android fragmentation không chỉ nằm ở phiên bản OS — nó nằm ở OEM skin (One UI, MIUI, ColorOS, Funtouch OS, EMUI), chipset (Qualcomm vs MediaTek ảnh hưởng đến hiệu năng camera, background throttling), và chính sách quản lý pin riêng của từng hãng (Xiaomi và Huawei nổi tiếng aggressive trong việc kill background process). Đây là mảng mà kinh nghiệm thực chiến rất quan trọng — nhiều QA mới vào nghề chỉ test trên Pixel (AOSP thuần) và tưởng mọi thứ ổn, rồi khi lên production mới phát hiện app bị Xiaomi kill notification service sau 5 phút.
Prompt gợi ý để AI hỗ trợ hệ thống hóa rủi ro này:
Tôi đang chuẩn bị test regression cho app Android có dùng: foreground service
để đồng bộ dữ liệu real-time, push notification qua FCM, và background location
tracking khi user đang di chuyển.
Hãy liệt kê cho tôi bảng các rủi ro fragmentation đặc thù theo OEM sau, và với
mỗi rủi ro, đề xuất một test case cụ thể để verify:
- Samsung (One UI) — Adaptive Battery, App Sleep
- Xiaomi (MIUI) — Autostart permission, Battery saver aggressive kill
- Oppo/Realme (ColorOS) — Background freeze
- Huawei (EMUI, không có Google Play Services đầy đủ ở một số model)
Với mỗi dòng, cho tôi: [OEM] | [Cơ chế gây rủi ro] | [Ảnh hưởng đến app] |
[Test case đề xuất] | [Cách setting cần bật/tắt trên máy thật để tái hiện lỗi]
Lưu ý quan trọng: AI có thể biết chung về các cơ chế này (đây là kiến thức phổ biến trong giới Android dev/QA), nhưng nó không cập nhật real-time theo firmware mới nhất của từng hãng. Hãy dùng bảng AI sinh ra như một checklist khởi điểm, sau đó verify chéo với changelog MIUI/One UI mới nhất hoặc thread trên XDA Developers trước khi đưa vào test plan chính thức.
Generating an iOS device matrix with platform-specific features
iOS ít fragment về OS hơn Android (vì Apple ép upgrade mạnh hơn), nhưng lại có một lớp phức tạp khác: sự khác biệt vật lý giữa các dòng máy — Dynamic Island (từ iPhone 14 Pro), notch (iPhone X đến 14 thường), Home Indicator vs Home Button (SE vẫn còn nút Home), safe area insets khác nhau, và ProMotion 120Hz ảnh hưởng đến animation timing.
Tôi cần một device matrix cho iOS tập trung vào rủi ro layout và tương tác
đặc thù theo hình dạng máy, cho app có: bottom navigation bar, floating
action button ở góc dưới phải, và banner quảng cáo dính đáy màn hình.
Hãy đề xuất tối thiểu các thiết bị đại diện cho từng "hình dạng" iPhone sau,
và với mỗi thiết bị, chỉ ra cụ thể phần UI nào của app có rủi ro bị che/vỡ:
1. Có Home Button, không notch (iPhone SE 3rd gen)
2. Có notch, không Dynamic Island (iPhone 13/14 thường)
3. Có Dynamic Island (iPhone 14 Pro trở lên)
4. Màn hình lớn nhất hiện tại (iPhone 15/16 Pro Max)
5. iPad (nếu app hỗ trợ, layout có bị kéo giãn vô lý không)
Với mỗi thiết bị, liệt kê: Safe Area đặc thù, rủi ro với banner quảng cáo
dính đáy, và một test case kiểm tra tap target không bị Home Indicator
hoặc gesture area nuốt mất.
Mẹo: Với device matrix — cả Android và iOS — hãy yêu cầu AI luôn kèm cột "Lý do chọn" và tránh nhận kết quả dạng danh sách khô khan. Sau đó, review matrix này với PM hoặc Data team mỗi quý một lần, vì phân phối thiết bị người dùng thay đổi theo thời gian (máy cũ rớt dần, máy mới lên) — một device matrix "đóng băng" từ 2 năm trước gần như chắc chắn đã lệch pha với thực tế.
Làm sao dùng AI để tạo các kịch bản lỗi đặc thù mobile — kết nối mạng, pin, permission?
Đây là nhóm bug "âm thầm nhưng chết người" của mobile app. Người dùng desktop hiếm khi mất mạng giữa lúc thanh toán, hiếm khi pin tụt xuống 3% giữa lúc đang nhập form, và hầu như không phải bấm "Deny" khi app xin quyền camera. Nhưng với mobile — đặc biệt là ở thị trường có mạng 3G/4G chập chờn, hoặc người dùng có thói quen tắt permission để tiết kiệm pin — đây là những tình huống xảy ra hàng ngày, và phần lớn dev không code defensive cho các case này vì happy path luôn chạy mượt trên máy dev (wifi công ty ổn định, pin đầy, mọi permission đã cấp từ trước).
Giá trị lớn nhất của AI ở mảng này là brainstorm có hệ thống — nó giúp bạn liệt kê hết các trạng thái trung gian (không chỉ "có mạng" và "mất mạng" mà còn "mạng chậm", "mạng chập chờn", "chuyển đổi wifi sang 4G giữa request") mà nếu tự nghĩ, bạn dễ chỉ ra được 3-4 case rồi dừng.
Kịch bản lỗi kết nối mạng
Tôi là QA Engineer đang viết test case cho tính năng "Thanh toán trong app"
(flow: chọn sản phẩm -> nhập thông tin thẻ -> xác nhận OTP -> nhận kết quả).
Hãy sinh cho tôi danh sách kịch bản test lỗi kết nối mạng, chia theo 4 nhóm:
1. MẤT MẠNG HOÀN TOÀN — tại từng bước cụ thể trong flow trên (không phải
chung "mất mạng" mà chỉ rõ: mất mạng ngay khi tap "Xác nhận thanh toán",
mất mạng ngay sau khi gửi OTP nhưng trước khi nhận response, v.v.)
2. MẠNG CHẬM / HIGH LATENCY — mô phỏng network throttling 3G, giả lập
request timeout 30s, và hành vi UI khi loading kéo dài bất thường
3. MẠNG CHẬP CHỜN (FLAKY) — mất kết nối rồi có lại nhiều lần trong lúc
một request đang chạy, request bị gửi trùng (duplicate) do retry logic
4. CHUYỂN ĐỔI LOẠI KẾT NỐI — user đang dùng Wifi thì bước ra khỏi vùng phủ,
máy tự chuyển sang 4G giữa lúc request đang chạy; hoặc bật Airplane Mode
rồi tắt ngay sau đó
Với mỗi kịch bản, cho tôi: mô tả case, kết quả kỳ vọng (app phải làm gì:
retry, hiển thị lỗi, giữ nguyên trạng thái nhập liệu?), và mức độ nghiêm
trọng nếu app xử lý sai (ví dụ: có nguy cơ bị double-charge không?).
Case "double-charge" trong ví dụ trên không phải ngẫu nhiên — đây là loại bug thực chiến cực kỳ phổ biến trong các app thanh toán: network timeout khiến client tưởng request fail và tự động retry, nhưng thực ra server đã xử lý xong ở lần gọi đầu. Đây là lý do khi test connectivity failure cho các flow tài chính, bạn luôn phải hỏi thêm "điều gì xảy ra ở phía server nếu client retry" — không chỉ nhìn từ góc UI.
Công cụ hỗ trợ mô phỏng thực tế: Đừng chỉ tắt wifi bằng tay. Dùng Android's Network Profiler trong Android Studio, hoặc Xcode's Network Link Conditioner (cho phép giả lập "100% Loss", "3G", "High Latency DNS" một cách chính xác và lặp lại được), hoặc Charles Proxy / Proxyman để throttle band width và tạo timeout có kiểm soát.
Kịch bản pin và trạng thái nguồn
App của tôi có tính năng ghi âm cuộc gọi tư vấn (chạy liên tục 15-30 phút)
và đồng bộ file ghi âm lên server ngay sau khi kết thúc.
Hãy sinh test case cho các trạng thái pin/nguồn sau, với trọng tâm là:
dữ liệu có bị mất không, và UX có thông báo rõ ràng cho user không?
1. Pin xuống dưới 20% -> hệ điều hành bật Low Power Mode / Battery Saver
tự động -> ảnh hưởng gì đến background sync, đến độ chính xác của timer?
2. Pin xuống dưới 5% trong khi đang ghi âm -> máy tự tắt nguồn hoàn toàn
3. User cắm sạc giữa lúc app đang chạy nền -> hành vi throttling có thay
đổi không (một số OS ưu tiên tài nguyên khác khi đang sạc)
4. Android Doze Mode / iOS App Nap kích hoạt khi app ở background quá lâu
trong lúc đang chờ đồng bộ file
Với mỗi case, chỉ rõ: hành vi kỳ vọng, cách setup để tái hiện trên máy thật
(cách bật Low Power Mode, cách simulate Doze Mode qua adb), và mức độ ưu
tiên fix nếu phát hiện lỗi mất dữ liệu.
Một chi tiết dễ bị AI generic hóa là cách bạn tái hiện Doze Mode thật trên Android — nó không tự bật ngay lập tức mà cần thiết bị đứng yên, không cắm sạc, và màn hình tắt trong một khoảng thời gian. Để test nhanh, dùng lệnh adb:
adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle
Yêu cầu AI giải thích rõ các câu lệnh adb/xcrun tương ứng để force các trạng thái này là một cách hay để rút ngắn thời gian setup — thay vì phải chờ máy tự nhiên đi vào Doze sau 30-60 phút không dùng.
Kịch bản từ chối và thu hồi permission
Đây là nhóm case QA hay quên nhất, vì trong lúc test, bạn thường "Allow" hết permission ngay từ đầu để flow chạy trôi. Nhưng thực tế, không ít user bấm "Deny", hoặc cấp quyền rồi sau đó vào Settings thu hồi lại (revoke) — và hành vi app lúc đó thường chưa được code kỹ.
App của tôi cần các permission: Camera (chụp ảnh CMND để KYC), Location
(hiển thị cửa hàng gần nhất), Notification (nhắc lịch), và Contacts
(mời bạn bè).
Sinh cho tôi ma trận test case permission theo 2 chiều: [Permission] x
[Trạng thái]. Các trạng thái cần cover:
1. User bấm "Deny" ở lần xin quyền đầu tiên
2. User bấm "Deny" và chọn "Don't ask again" (Android) / permission bị
ẩn khỏi dialog lần sau (iOS) -> app phải hướng dẫn user vào Settings
thủ công như thế nào?
3. User đã Allow trước đó, nhưng sau đó vào Settings > App > Permissions
để revoke khi app đang chạy nền -> app có detect được ngay khi quay
lại foreground không, hay vẫn tưởng mình còn quyền và crash khi gọi API?
4. (Chỉ Android 12+) User chọn "Only this time" cho Location -> app có
xin lại đúng lúc cần ở lần dùng tiếp theo không?
5. (Chỉ iOS) User chọn "Allow Once" cho Camera
Với mỗi ô trong ma trận, cho tôi kết quả kỳ vọng cụ thể và mức ảnh hưởng
đến trải nghiệm nếu app xử lý sai (crash, treo màn hình trắng, hay chỉ là
thiếu thông báo rõ ràng).
Mẹo: Khi AI generate case về permission, luôn cross-check với việc bạn có phải test cả trên Android 12+ approximate location (khi user chỉ cho "Approximate" thay vì "Precise") hay không, vì đây là case mới hơn và nhiều bộ test case cũ (viết trước 2021) hoàn toàn không có, khiến AI đôi khi cũng bỏ sót nếu bạn không nhắc rõ Android version trong prompt.
Kịch bản gián đoạn từ hệ điều hành
Nhóm case này là những "sự kiện ngoại lai" mà hệ điều hành áp đặt lên app của bạn, bất kể app muốn hay không: cuộc gọi đến, tin nhắn SMS, cảnh báo thời tiết khẩn cấp, thông báo hệ thống che màn hình, hoặc app bị OS kill để giải phóng RAM khi user mở quá nhiều app khác.
Sinh cho tôi test case về gián đoạn hệ điều hành (OS interruption) cho
tính năng "Video call tư vấn trực tiếp" trong app, tập trung vào việc
liệu session có được giữ nguyên trạng thái hay bị mất khi:
1. Có cuộc gọi thoại (Phone call) đến giữa lúc đang video call trong app
2. Có SMS/tin nhắn OTP hiện banner đè lên UI
3. App bị hệ thống kill do thiếu RAM (low memory killer) khi đang ở
background, sau đó user mở lại app từ recent apps
4. Màn hình tự động khóa (screen lock/timeout) trong khi cuộc gọi vẫn
đang diễn ra ở background
5. (Android) Cảnh báo hệ thống (system alert window) như cập nhật bảo
mật hiện đè lên toàn màn hình
Với mỗi case, phân tích: app cần lưu state gì trước khi bị gián đoạn, và
sau khi resume, trải nghiệm mong đợi là gì (tự động reconnect call, hay
kết thúc session và thông báo rõ cho user)?
Mẹo: Với nhóm kịch bản kết nối/pin/permission/OS interruption, hãy nhớ rằng đây là lĩnh vực AI sinh case rất giỏi về mặt "liệt kê đầy đủ", nhưng bạn — với vai trò QA có kinh nghiệm — mới là người biết case nào thực sự "đau" với sản phẩm cụ thể của mình. Luôn yêu cầu AI thêm cột mức độ nghiêm trọng và tự mình re-rank lại theo business impact thật, đừng để AI tự quyết định ưu tiên.
Làm sao kiểm thử tính đồng nhất giữa iOS và Android với sự hỗ trợ của AI?
Định nghĩa đúng về "tính đồng nhất"
Trước khi lao vào viết checklist, cần làm rõ một hiểu lầm rất phổ biến: "đồng nhất" (consistency) không có nghĩa là "giống y hệt về pixel". iOS và Android có Human Interface Guidelines và Material Design khác nhau — nút back, gesture navigation, vị trí action button, hành vi của pull-to-refresh, kiểu animation transition đều có convention riêng theo từng platform một cách chính đáng. Một app tuân thủ tốt native convention của từng OS thực ra là dấu hiệu của chất lượng cao, không phải lỗi.
Cái cần đồng nhất thực sự là ba lớp:
- Đồng nhất về logic nghiệp vụ (business logic) — cùng input phải ra cùng kết quả tính toán, cùng validate rule, cùng flow các bước. Đây là lớp bắt buộc phải giống 100%.
- Đồng nhất về nội dung (content) — text, giá tiền, label, thông báo lỗi phải giống nhau về nghĩa (không nhất thiết giống về câu chữ UI convention).
- Đồng nhất về hành vi tương tác chấp nhận khác biệt platform-native — layout, animation, gesture có thể (và nên) khác nhau miễn tuân theo chuẩn của từng OS.
Việc phân biệt rạch ròi ba lớp này trước khi hỏi AI là bước quan trọng nhất trong cả phần này — nếu không, bạn sẽ nhận về một đống bug report vô nghĩa dạng "nút OK bên Android màu xanh, bên iOS màu xanh nhạt hơn" mà không ai care.
Tạo checklist đối chiếu (parity checklist) đa nền tảng với AI
Tôi có app [TÊN APP] với các tính năng chính: đăng ký/đăng nhập (email +
OTP), giỏ hàng, thanh toán, và theo dõi đơn hàng. App có bản Android
(native Kotlin) và iOS (native Swift), phát triển bởi 2 team riêng.
Hãy tạo một cross-platform parity checklist, chia rõ 3 nhóm như sau:
NHÓM A - BẮT BUỘC GIỐNG 100% (business logic & content):
- Liệt kê các điểm cần verify giống nhau tuyệt đối: công thức tính giá,
validate rule cho input (OTP 6 số, password tối thiểu mấy ký tự...),
copy text của thông báo lỗi, số lượng bước trong flow checkout
NHÓM B - ĐƯỢC PHÉP KHÁC NHAU CÓ CHỦ ĐÍCH (platform convention):
- Liệt kê các điểm khác biệt hợp lý cần XÁC NHẬN là "khác có chủ đích"
chứ không phải bug: vị trí nút back, kiểu animation chuyển màn hình,
hành vi khi bấm nút Home/gesture, kiểu bàn phím số hiện ra cho OTP
NHÓM C - VÙNG XÁM CẦN QUYẾT ĐỊNH THIẾT KẾ RÕ RÀNG:
- Liệt kê các điểm mà nếu không có quyết định rõ từ Product/Design thì
rất dễ bị lệch giữa 2 team: hành vi khi mất mạng giữa flow thanh toán,
cách hiển thị số lượng ký tự còn lại trong input, thời gian timeout của
OTP, cách xử lý khi app resume từ background giữa lúc đang nhập form
Trình bày dưới dạng bảng, có cột "Cách verify" hướng dẫn cụ thể QA nên
làm gì để kiểm tra từng điểm.
Mẹo: Khi có bảng checklist này, đừng chỉ dùng một lần rồi bỏ — biến nó thành một tài liệu sống, review lại mỗi khi có tính năng lớn mới ra mắt, và gắn checklist này vào Definition of Done của story liên quan UI/flow chung cho cả 2 platform. Nhiều team để 2 platform "trôi" dần theo thời gian chỉ vì thiếu artifact này để cả 2 team cùng tham chiếu.
Tạo prompt phát hiện bug đặc thù theo nền tảng
Ngoài parity, một dạng bug khác cực kỳ phổ biến là bug chỉ xảy ra trên một platform do đặc thù kỹ thuật riêng — ví dụ WebView rendering khác nhau, keyboard behavior khác nhau, hoặc cách quản lý memory khác nhau dẫn đến crash chỉ xảy ra ở Android khi có nhiều Activity trong back stack.
Tôi cần tìm các bug tiềm ẩn CHỈ có khả năng xảy ra trên MỘT trong 2 nền
tảng, cho tính năng "Form nhập liệu nhiều bước có auto-save draft" trong
app của tôi (dùng WebView để hiển thị một số bước, native cho các bước còn lại).
Với ANDROID, hãy nghĩ về các rủi ro đặc thù liên quan đến:
- Activity lifecycle (onPause/onSaveInstanceState) khi user xoay màn hình
hoặc bị OS kill Activity để giải phóng RAM
- Bàn phím ảo (soft keyboard) đẩy layout và có thể làm mất trạng thái
scroll hoặc focus của input đang nhập
- Back button system (không phải back trong app) có thể thoát flow bất ngờ
Với IOS, hãy nghĩ về các rủi ro đặc thù liên quan đến:
- Swipe-back gesture có thể vô tình thoát flow mà không qua nút "Huỷ"
chính thức (không có confirm dialog)
- WKWebView keyboard avoidance behavior khác với UIKit native input
- App bị suspend (không terminate) ở background rồi resume - state có
đúng như lúc suspend không
Với mỗi rủi ro, đề xuất một test case cụ thể kèm bước tái hiện.
Prompt kiểu này khai thác đúng thế mạnh của AI: nó đã "học" từ rất nhiều tài liệu kỹ thuật và bug report công khai về đặc thù lifecycle của từng platform, nên có thể liệt kê nhanh những rủi ro platform-specific mà một QA chưa có nhiều năm kinh nghiệm native mobile khó nghĩ ra hết trong một buổi brainstorm.
Dùng AI phân tích báo cáo bug đa nền tảng
Một use case thực chiến khác: khi bạn đã có một danh sách bug report từ cả 2 platform (từ Jira export, hoặc từ crash report Firebase Crashlytics/Sentry), AI có thể giúp bạn tìm pattern nhanh hơn nhiều so với việc đọc tay từng ticket.
Dưới đây là export 40 bug report gần nhất liên quan đến app mobile của tôi
(tôi sẽ dán CSV/text bên dưới, gồm cột: ID, Platform, Feature, Severity,
Description, Root cause nếu đã có).
[dán dữ liệu bug report ở đây]
Hãy phân tích và trả lời:
1. Có feature nào có tỷ lệ bug lệch hẳn giữa 2 platform không (ví dụ:
feature X có 8 bug trên Android nhưng chỉ 1 bug trên iOS)? Nếu có,
đưa ra giả thuyết vì sao (thiếu test coverage một bên, khác biệt kỹ
thuật thật, hay do độ phức tạp code khác nhau giữa 2 team)?
2. Có root cause nào lặp lại nhiều lần và có khả năng là một vấn đề gốc
(systemic issue) chứ không phải bug đơn lẻ không?
3. Dựa trên pattern này, đề xuất 3 vùng cần tăng cường test coverage
ngay trong sprint tới, xếp theo mức độ rủi ro giảm dần.
Mẹo: Khi dùng AI để phân tích bug report thật, luôn đảm bảo dữ liệu đã được ẩn danh (loại bỏ thông tin khách hàng, số điện thoại, email thật) trước khi dán vào bất kỳ công cụ AI nào — đặc biệt nếu công cụ đó không nằm trong danh sách được công ty phê duyệt để xử lý dữ liệu nội bộ/khách hàng.
Làm sao dùng AI để tạo kịch bản test cho deep link, push notification và background state?
Ba nhóm này có một điểm chung khiến chúng đặc biệt khó test: chúng đều liên quan đến việc app được "đánh thức" hoặc "điều hướng" từ một nguồn bên ngoài chính app, và trạng thái app lúc bị đánh thức (đang tắt hoàn toàn, đang ở background, hay đang mở sẵn) tạo ra rất nhiều nhánh hành vi khác nhau mà rất dễ code thiếu.
Deep link test scenario generation
App của tôi hỗ trợ deep link dạng: myapp://product/{id} và universal
link https://myapp.com/product/{id}, dùng để mở trực tiếp trang chi tiết
sản phẩm từ: email marketing, SMS, quảng cáo Facebook/Google, và QR code
in trên tờ rơi.
Sinh cho tôi ma trận test case deep link theo TRẠNG THÁI APP khi link
được click, đây là biến số quan trọng nhất cần cover đủ 3 trường hợp:
1. APP CHƯA CÀI (cold - not installed): click link -> mở store -> sau khi
cài và mở app lần đầu, có deferred deep linking để vẫn đưa user đến
đúng trang sản phẩm không, hay user bị rơi về Home?
2. APP ĐÃ CÀI NHƯNG ĐANG TẮT HOÀN TOÀN (cold start): app phải launch từ
đầu rồi navigate đến đúng trang, không phải chỉ mở Home rồi user tự tìm
3. APP ĐANG CHẠY Ở BACKGROUND (warm start): app resume và phải điều hướng
đến đúng trang MỚI, kể cả khi trước đó user đang xem một trang khác
hoàn toàn (có cần clear back stack cũ không, hay cho phép back về
trang trước?)
4. APP ĐANG MỞ SẴN Ở FOREGROUND, đúng nhiều lần liên tiếp click nhiều
deep link khác nhau (ví dụ user click 2 email marketing gần nhau)
Ngoài ra, thêm case: deep link chứa {id} không tồn tại/đã bị xoá (sản
phẩm hết hàng và bị gỡ) -> app cần fallback về đâu, không được crash
hoặc hiện màn hình trắng.
Với mỗi case, cho tôi bước test cụ thể kèm lệnh adb (Android) hoặc xcrun
simctl (iOS) để trigger deep link đó trực tiếp không cần thao tác thật
trên email/SMS.
Câu lệnh trigger deep link trực tiếp là chi tiết cực kỳ hữu ích để yêu cầu AI cung cấp, vì nó giúp bạn test lặp lại nhanh mà không cần dựng lại email/SMS thật mỗi lần:
adb shell am start -W -a android.intent.action.VIEW -d "myapp://product/12345" com.yourapp.package
xcrun simctl openurl booted "myapp://product/12345"
Mẹo: Với deep link, case dễ bị bỏ sót nhất không phải là "link có mở đúng trang không" mà là "back stack sau khi mở deep link có hợp lý không" — ví dụ user từ ngoài app bấm vào link sản phẩm, xem xong bấm back, kỳ vọng là về Home chứ không phải thoát app hoàn toàn (vì stack chỉ có 1 màn hình). Đây là bug UX âm thầm rất phổ biến, hãy luôn yêu cầu AI thêm case này vào test plan.
Push notification test scenario generation
App có push notification cho 3 loại: (1) thông báo giao dịch (order status
update, cần mở đúng màn hình chi tiết đơn hàng), (2) thông báo marketing
(khuyến mãi, mở landing page khuyến mãi), (3) thông báo silent/data-only
(đồng bộ dữ liệu ngầm, không hiện banner).
Sinh test case cho các nhóm sau:
1. TAP HÀNH VI THEO TRẠNG THÁI APP: app tắt hoàn toàn / app ở background /
app ở foreground khi notification đến (với case foreground, banner có
tự hiện hay app phải tự custom hiển thị in-app banner?)
2. NOTIFICATION PERMISSION CHƯA ĐƯỢC CẤP: user chưa Allow notification
permission -> push server vẫn gửi được nhưng device không hiện gì ->
app cần có cơ chế nào để nhắc lại user bật permission trong app không?
3. RICH NOTIFICATION: notification có hình ảnh, action button (ví dụ nút
"Xem đơn hàng" ngay trong notification không cần mở app) -> test case
khi action button được bấm trong các trạng thái app khác nhau
4. NHIỀU NOTIFICATION CÙNG LOẠI CHỒNG NHAU: user nhận 5 thông báo order
status trong 2 phút (ví dụ đơn hàng chuyển trạng thái nhanh) -> có bị
group/collapse hợp lý không, hay tap vào notification cũ vẫn dẫn đến
đúng order id của nó (không bị lẫn với order mới nhất)?
5. TOKEN FCM/APNS HẾT HẠN HOẶC BỊ THAY ĐỔI: user gỡ cài rồi cài lại app,
hoặc đổi máy -> app có đăng ký lại token mới với server đúng cách
không, tránh gửi notification vào "hố đen"
Với mỗi case, mô tả kết quả kỳ vọng và cách test được trên thiết bị thật
(không phải chỉ test trên Notification Composer console).
Mẹo: Test push notification chỉ qua Firebase Console hoặc Notification Composer là chưa đủ — hãy luôn có ít nhất một test case gửi qua API thật từ backend (dùng Postman gọi endpoint gửi notification production đang dùng), vì payload thực tế backend gửi (custom data, click_action, priority) thường khác với payload test đơn giản của console, và chính sự khác biệt này là nơi bug hay ẩn.
Background state and app lifecycle test generation
Đây là mảng đòi hỏi hiểu biết sâu về lifecycle của cả 2 platform, và là nơi AI hỗ trợ tốt nhất khi bạn cung cấp đúng ngữ cảnh kỹ thuật của app (dùng background task loại nào, có WorkManager/BGTaskScheduler không).
App của tôi có: (1) một audio player cho phép nghe podcast tiếp tục khi
app ở background, (2) một tính năng upload file lớn (video) chạy nền,
và (3) một bộ đếm thời gian (session timer) cho tính năng "học tập tập
trung" cần chính xác đến từng giây dù app ở background.
Sinh test case về background state & app lifecycle, phân theo các trục:
1. CHUYỂN TIẾP TRẠNG THÁI: foreground -> background -> foreground, đo
xem: audio có dừng đột ngột không, upload có tiếp tục hay bị OS
suspend giữa chừng và cần resume thủ công, session timer có bị lệch
giờ (do OS không cho code chạy chính xác từng giây ở background)?
2. THỜI GIAN Ở BACKGROUND KÉO DÀI (>30 phút): OS (đặc biệt iOS) sẽ
terminate hẳn app đứng nền quá lâu -> khi app mở lại, có phục hồi
đúng trạng thái session/upload đã dừng ở đâu, hay mất trắng?
3. BACKGROUND TASK BỊ HẾT THỜI GIAN CHO PHÉP: iOS cho background task
khoảng 30s (background fetch) hoặc dùng BGProcessingTask cho task
dài hơn nhưng không đảm bảo được cấp; Android WorkManager có constraint
riêng theo battery optimization -> app cần xử lý gì khi task bị OS
cắt giữa chừng (upload file dở, cần resume từ đâu, không phải upload
lại từ đầu)?
4. CHUYỂN ĐỔI QUA LẠI NHIỀU LẦN NHANH (app switcher): user vào app khác
rồi quay lại app liên tục trong vài giây (kiểm tra memory leak, UI có
bị re-render sai trạng thái, có bị gọi API trùng lặp do lifecycle
callback bị gọi nhiều lần không đúng ý)
Với mỗi case, đề xuất cách setup test cụ thể (dùng Xcode Debug > Simulate
Background Fetch, hoặc adb shell am kill để giả lập OS kill app; adb shell
am set-inactive để giả lập Android App Standby).
Mẹo: Với background state, luôn hỏi thêm AI câu "nếu app không có quyền chạy nền lâu, đâu là chỗ tự nhiên nhất để thông báo cho user (ví dụ: hiện banner 'Upload đang tiếp tục, vui lòng giữ app mở' khi phát hiện file lớn)" — vì phần lớn bug ở mảng này không nằm ở lỗi kỹ thuật thuần, mà nằm ở việc app không giao tiếp rõ với user về giới hạn hệ điều hành, khiến user tưởng app bị lỗi trong khi thực chất đó là hành vi OS chủ động.
Tổng kết
Mobile testing với sự hỗ trợ của AI không phải là việc "AI test giúp bạn" — mà là AI giúp bạn mở rộng không gian tư duy đủ nhanh để cover được độ phức tạp thật của hệ sinh thái mobile: hàng trăm tổ hợp thiết bị, vô số trạng thái kết nối/pin/permission, sự khác biệt platform cần phân biệt rạch ròi giữa "bug thật" và "khác biệt có chủ đích", và các luồng lifecycle phức tạp của deep link/notification/background task. Giá trị lớn nhất bạn nhận được không phải là danh sách case AI sinh ra ngay lần đầu, mà là việc dùng AI như một công cụ brainstorm có cấu trúc, sau đó áp kinh nghiệm và dữ liệu thật của sản phẩm để lọc, ưu tiên, và biến nó thành test plan thực sự đáng tin cậy.