Quy trình tái hiện lỗi Android trên nhiều điện thoại thật cho đội hỗ trợ

Khi khách hàng báo “nút không phản hồi”, “đăng nhập xong lại quay về màn hình cũ” hoặc “giao diện chỉ lỗi trên máy của tôi”, vấn đề thường không nằm ở cách mô tả. Vấn đề là đội hỗ trợ chưa tách được điều kiện môi trường khiến lỗi xuất hiện.

Trên Android, cùng một phiên bản ứng dụng có thể cho kết quả khác nhau vì phiên bản hệ điều hành, giao diện tùy biến của nhà sản xuất, kích thước màn hình, ngôn ngữ, quyền truy cập, đường truyền mạng, chính sách pin hoặc trạng thái phiên đăng nhập cũ.

Bài viết này trình bày một quy trình nhỏ, có thể bắt đầu với ba điện thoại thật. Mục tiêu không phải sở hữu thật nhiều thiết bị, mà là tạo ra bằng chứng đủ rõ để kỹ sư có thể chạy lại cùng một ca lỗi.

1. Chuẩn hóa dữ liệu đầu vào của ticket

Trước khi chọn điện thoại, hãy biến cuộc trò chuyện hỗ trợ thành một ca kiểm thử có thể thực hiện được. Tối thiểu cần ghi lại:

• hãng và model điện thoại;
• phiên bản Android;
• phiên bản ứng dụng và nguồn cài đặt;
• ngôn ngữ, khu vực và múi giờ;
• Wi-Fi hay dữ liệu di động;
• loại tài khoản và trạng thái phiên đăng nhập;
• màn hình bắt đầu;
• các bước thao tác, kết quả mong đợi và kết quả thực tế;
• thời điểm xảy ra lỗi, ảnh chụp hoặc video ngắn.

Nếu khách hàng không biết một thông tin, hãy ghi “chưa rõ” thay vì tự điền theo phỏng đoán. Việc này giúp kỹ sư phân biệt dữ kiện đã xác nhận với giả thuyết của đội hỗ trợ.

Không yêu cầu khách hàng gửi mật khẩu, mã xác thực, thông tin thanh toán, tin nhắn riêng tư hoặc tệp cá nhân không liên quan. Ưu tiên tài khoản thử nghiệm và dữ liệu giả lập.

2. Xây dựng ma trận ba thiết bị

Ba điện thoại nên có ba vai trò khác nhau.

Ví dụ, nếu ticket nói lỗi chỉ xuất hiện trên một máy Android 12 dùng tiếng Thổ Nhĩ Kỳ, thiết bị thứ hai nên gần với hãng và thế hệ hệ điều hành đó. Thiết bị thứ ba có thể dùng Android khác hoặc nhà sản xuất khác để kiểm tra xem lỗi đi theo hệ điều hành, hãng hay ngôn ngữ.

Chỉ thêm thiết bị mới khi dữ liệu ticket cho thấy ma trận hiện tại bỏ sót một nhóm quan trọng. Mỗi điện thoại trên bàn cần có một lý do tồn tại rõ ràng.

3. Mỗi lần chỉ thay đổi một biến

Đầu tiên, chạy luồng đã biết là hoạt động trên thiết bị chuẩn. Sau đó chạy lại trên thiết bị gần với khách hàng, giữ nguyên phiên bản ứng dụng, loại tài khoản và mạng nếu có thể.

Khi kết quả khác nhau, vòng tiếp theo chỉ đổi một điều kiện:

1. đổi ngôn ngữ trên cùng thiết bị;
2. đổi mạng nhưng giữ nguyên tài khoản;
3. xóa dữ liệu ứng dụng nhưng giữ nguyên build;
4. đổi trạng thái quyền nhưng giữ nguyên Android;
5. so sánh màn hình dọc và ngang;
6. bật hoặc tắt tối ưu pin.

Hãy ghi cả lần thành công và thất bại. “Lỗi 4 trên 5 lần, nhưng không còn xuất hiện sau khi xóa dữ liệu ứng dụng” có giá trị hơn nhiều so với “lúc được lúc không”.

4. Quan sát tập trung nhưng không đồng bộ thao tác một cách mù quáng

Việc liên tục cầm từng máy, mở khóa, chuyển màn hình và chụp ảnh dễ làm trạng thái giữa các điện thoại khác nhau. Một không gian làm việc trên máy tính giúp đội hỗ trợ nhìn cùng lúc các màn hình, mã thiết bị và thời điểm giao diện thay đổi.

Khả năng điều khiển nhiều điện thoại Android phù hợp để đưa các máy về cùng màn hình bắt đầu hoặc nhập dữ liệu thử nghiệm không nhạy cảm. Tuy nhiên, khi một máy xuất hiện hộp thoại quyền, bàn phím, thông báo cập nhật hoặc tải chậm, phải dừng thao tác nhóm.

Lúc đó, sự khác biệt giữa các thiết bị chính là bằng chứng cần giữ lại. Nếu tiếp tục gửi cùng một lần nhấp đến tất cả máy, đội hỗ trợ có thể vô tình đóng hộp thoại quan trọng hoặc tạo ra một lỗi khác.

Một số quy tắc thực tế:

• dán mã ngắn lên mỗi điện thoại;
• đưa mã thiết bị vào ảnh chụp và ghi chú;
• giữ một tài khoản chuẩn để so sánh;
• xóa dữ liệu ứng dụng giữa các ca khi trạng thái cũ có thể ảnh hưởng;
• ghi lại nguồn điện, USB, Wi-Fi và nhiệt độ khi chúng liên quan.

5. Tạo gói bằng chứng mà kỹ sư có thể chạy lại

Không nên chuyển tiếp toàn bộ đoạn chat rồi yêu cầu kỹ sư tự tìm vấn đề. Gói bàn giao cần đủ ngắn để đọc trong một phút và đủ chi tiết để chạy lại.

Nội dung tối thiểu

1. một câu mô tả lỗi và mức ảnh hưởng;
2. mã máy, model, Android và build ứng dụng;
3. trạng thái bắt đầu;
4. các bước được đánh số;
5. kết quả mong đợi và thực tế;
6. tỷ lệ tái hiện, ví dụ 4/5;
7. kết quả trên máy lỗi và máy chuẩn;
8. ảnh, video hoặc log có mốc thời gian;
9. các điều kiện đã được loại trừ.

Tên tệp nên chứa mã ticket, mã thiết bị, build và thời gian. Cắt video chỉ còn phần cần thiết. Xóa tên khách hàng, email, tin nhắn, token, mã đơn hàng và nội dung không liên quan. Khi hết thời hạn lưu giữ, xóa dữ liệu thử nghiệm theo chính sách của công ty.

6. Khi nào dùng emulator hoặc thiết bị đám mây

Ba môi trường giải quyết ba loại nhu cầu khác nhau:

• Emulator: kiểm tra nhanh, cấu hình ảo lặp lại được, độ phân giải đặc biệt.
• Điện thoại thật tại chỗ: ticket tương tác thường xuyên, hành vi theo hãng, camera, Bluetooth, USB và trình diễn trực tiếp.
• Thiết bị thật trên cloud: model hiếm, phạm vi phát hành rộng, nhóm làm việc từ xa và kiểm thử song song.

Một trình tự hợp lý là kiểm tra cơ bản trên emulator, thử nguyên nhân có khả năng cao trên điện thoại tại chỗ, rồi dùng cloud khi thiếu model hoặc cần xác nhận rộng hơn.

7. Chạy thử trong hai tuần

Chọn 5–10 ticket từng bị chậm vì không rõ thiết bị. Dùng cùng một biểu mẫu tiếp nhận và cùng một mẫu gói bằng chứng. Trong hai tuần, theo dõi:

• thời gian đến lần tái hiện có ý nghĩa đầu tiên;
• số lần phải hỏi thêm khách hàng;
• số lần kỹ sư trả ticket vì thiếu thông tin;
• điều kiện thực sự làm kết quả thay đổi;
• khoảng trống thiết bị mà ba máy chưa bao phủ.

Nếu thời gian giảm và số vòng hỏi lại ít hơn, hãy bổ sung từng điện thoại theo bằng chứng. Nếu không cải thiện, hãy sửa biểu mẫu tiếp nhận và cách ghi trạng thái trước khi mua thêm thiết bị.

Tôi tham gia phát triển LaiCai Screen Mirroring. Phiên bản đầy đủ hơn về lựa chọn thiết bị, quyền riêng tư và cách kết hợp máy thật, emulator và cloud nằm trong bài cách đội hỗ trợ tái hiện lỗi Android trên nhiều điện thoại thật.

Kết quả tốt nhất không phải một chiếc kệ đầy điện thoại. Đó là một ca lỗi mà bất kỳ đồng đội nào cũng có thể chạy lại, so sánh và tiếp tục xử lý.