Kiểm Thử Ứng Dụng AI Của Bạn Như Một Người Lạ Mới Dùng (Trước Khi Người Dùng Phát Hiện Lỗi)

Tại Sao Lỗi Chỉ Xuất Hiện Khi Người Khác Dùng Ứng Dụng Của Bạn?

Vì bạn đã biết chính xác cách dùng thứ mình vừa tạo ra — bạn đưa chuột đến đúng chỗ, không bao giờ thử một ngày tháng đã qua, và bạn luôn test trên máy tính để bàn. “Kiểm thử kiểu người lạ” nghĩa là đưa ứng dụng hoàn chỉnh của bạn cho một người chưa từng thấy nó, rồi quan sát trực tiếp xem điều gì khiến họ gặp lỗi, bối rối, hoặc bị chặn lại — trước khi người dùng thật của bạn gặp phải.

Bạn đã xây một ứng dụng đặt lịch bằng công cụ AI builder. Bạn tự test: chọn ngày, điền tên, xác nhận. Chạy tốt.

Đồng nghiệp của bạn thử: chọn ngày, thấy múi giờ sai. Bối rối. Họ rời đi.

Mẹ bạn thử: lỡ tay chọn nhầm một ngày trong quá khứ, ứng dụng bị sập.

Bạn bè dùng điện thoại: bộ chọn ngày không hoạt động (họ không chạm vào ô nhập được).

Không cái nào trong số này là lỗi khó. Nhưng tất cả đều vô hình với bạn vì bạn biết chính xác cách dùng thứ mình tạo ra. Một người lạ sẽ tìm ra mọi trường hợp ngoại lệ mà bạn đã bỏ sót. Tin tốt là: kiểm thử kiểu người lạ rất rẻ, và nó bắt được đúng những thứ quan trọng.

Làm Sao Để Kiểm Thử Ứng Dụng Như Một Người Lạ?

Đưa ứng dụng của bạn cho ai đó chưa biết nó tồn tại, quan sát họ thử dùng từ đầu, và ghi lại điều gì khiến họ gặp lỗi hoặc bối rối. Bạn không cần một đội QA. Bạn chỉ cần một người và 10 phút.

Cách một: nhờ một người thật (mất 15 phút)

Nhắn tin cho một người bạn: “Cậu thử cái này nhanh giúp mình và cho mình biết cậu nghĩ sao được không?” Gửi cho họ đường link, để họ nghịch trong 5–10 phút, rồi hỏi:

Bạn đang cố làm gì?
Nó có hoạt động như bạn mong đợi không?
Điều gì khiến bạn bối rối?
Bạn sẽ thay đổi điều gì?

Bạn sẽ nhận được những bất ngờ. “Mình không tìm thấy nút gửi” (vì bạn giấu nó trong một modal). “Mình không biết là phải điền email” (vì bạn không đánh dấu nó là bắt buộc). “Sao lịch hẹn của mình lại ghi Thứ Ba trong khi mình chọn Thứ Tư?” (vấn đề múi giờ mà bạn chưa từng để ý).

Vì sao cách này hiệu quả: Một người thật sẽ test cả luồng chính lẫn những luồng vô tình bị lỗi mà bạn không ngờ tới.

Điểm cần lưu ý: Họ có thể sẽ tử tế với bạn. Họ có thể không nói thẳng là có gì đó thực sự tệ vì không muốn làm bạn buồn. Hãy quan sát nét mặt họ nhiều hơn là lời họ nói.

Cách hai: test trên một thiết bị bạn không thường dùng (mất 5 phút)

Nếu bạn xây trên máy tính để bàn, hãy test trên điện thoại. Nếu bạn xây trên điện thoại, hãy test trên máy tính bảng.

Mở ứng dụng của bạn lên. Thử:

Chạm vào một nút gần mép màn hình (có thể nó bị cắt mất)
Cuộn màn hình một cách tự nhiên (có hoạt động không?)
Điền một ngày tháng (có bộ chọn ngày thật, hay nó bắt bạn gõ tay?)
Chụp một bức ảnh nếu ứng dụng của bạn xử lý hình ảnh (định dạng gì, dung lượng bao nhiêu, tốc độ ra sao?)

Hầu hết các AI builder làm giao diện responsive khá tốt, nhưng bạn sẽ bất ngờ với những gì bị vỡ ở độ rộng 375px hoặc trên kết nối mạng chậm.

Vì sao cách này hiệu quả: Di động thay đổi hoàn toàn cảm giác về tốc độ của ứng dụng và cách người dùng tương tác với nó. Một lệnh gọi database mất hai giây thì ổn trên máy tính để bàn. Trên di động với mạng 4G, nó lại có cảm giác như bị hỏng.

Điểm cần lưu ý: Cách này chỉ tốt tùy vào mức độ kiên nhẫn của bạn. Test một luồng, từ đầu đến cuối, trên một thiết bị. Đừng đi dạo một vòng quanh app; hãy hoàn thành một nhiệm vụ cụ thể.

Cách ba: bài test theo checklist (mất 10 phút)

Nếu bạn chưa sẵn sàng nhờ người thật, hãy tự test ứng dụng như một người lạ:

Mở ứng dụng lên. Đừng nhớ lại bạn đã xây nó để làm gì. Bạn nghĩ ứng dụng này dùng để làm gì?
Chọn thứ đầu tiên trông có vẻ bấm được. Đừng nghĩ về việc bạn muốn nó làm gì. Nó có làm đúng như bạn đoán không?
Cố hoàn thành nhiệm vụ chính (đặt lịch, điền form, tạo bài đăng) mà không xem phần hướng dẫn. Nó có chạy đúng ngay lần thử đầu tiên không?
Tìm các trường bắt buộc. Chúng có được đánh dấu rõ ràng không? (Chỉ dùng màu sắc thôi thì không phải ai cũng nhìn thấy được.)
Cố tình phạm lỗi (bỏ trống một trường, nhập dữ liệu sai). Ứng dụng có báo cho bạn biết chỗ nào sai không?
Thử trên điện thoại của bạn. Bạn có đọc được chữ không? Bạn có chạm được vào các nút không?

Đây không phải là thứ thay thế cho người test thật, nhưng vẫn tốt hơn là tung ra một thứ chưa được kiểm thử.

Nên Chú Ý Điều Gì Khi Ai Đó Đang Test Ứng Dụng Của Bạn?

Hãy chú ý sự do dự, các cách giải quyết vòng vo, trạng thái lỗi không rõ ràng, trải nghiệm di động chậm chạp, và dữ liệu có vẻ như biến mất — mỗi dấu hiệu này đều chỉ ra một vấn đề cụ thể, có thể sửa được.

Sự do dự: Nếu họ khựng lại trước khi bấm một nút, nghĩa là nút đó chưa đủ rõ ràng. Nếu họ hỏi “mình có phải điền cái này không?”, nghĩa là trường đó chưa được đánh dấu đủ rõ.

Cách giải quyết vòng vo: Nếu họ cố làm điều gì đó mà không được, rồi tìm một cách khác, bạn đang có một “vách đá” trải nghiệm người dùng. (Cố gửi form bằng cách nhấn Enter thay vì bấm nút. Cố xóa trống một ô bằng cách nhấp ba lần thay vì bấm dấu X.)

Trạng thái lỗi: Nếu có gì đó thất bại — lỗi mạng, lỗi kiểm tra dữ liệu, hết thời gian chờ — ứng dụng có báo cho họ biết nên làm gì tiếp theo không? Hay chỉ hiện một ô đỏ giận dữ?

Trải nghiệm di động: Nếu mất ba giây để một cú chạm được ghi nhận, họ sẽ nghĩ ứng dụng bị hỏng (có thể không phải — chỉ là mạng chậm — nhưng nó có cảm giác như bị hỏng). Nếu họ không đọc được chữ vì độ tương phản quá thấp, họ sẽ không phàn nàn đâu; họ sẽ chỉ rời đi.

Sự nhầm lẫn về dữ liệu: Nếu họ tạo ra thứ gì đó rồi sau đó không tìm lại được, hoặc nghĩ là đã lưu nhưng thực ra chưa, đó là lỗi nằm trong lược đồ database của bạn. Có thể AI builder đã làm đúng những gì bạn yêu cầu, nhưng những gì bạn yêu cầu lại không khớp với những gì người dùng mong đợi.

AI Builder Của Bạn Có Thể Sửa Những Lỗi Mà Người Lạ Tìm Ra Không?

Có — một khi bạn mô tả những gì bạn đã thấy, chứ không phải điều bạn nghĩ là vấn đề, builder của bạn có thể sửa trực tiếp. Bạn không cần tự mình sửa nó:

“Trường ngày tháng không hoạt động trên di động” → Builder có thể thay bằng một bộ chọn ngày thật.
“Form không hiện trường nào là bắt buộc” → Builder có thể thêm các dấu hiệu trực quan.
“Mình không tìm được chỗ để gửi” → Builder có thể làm nút to hơn hoặc chuyển vị trí.
“Khi mình gõ sai chính tả, mình chẳng biết là đã sai chỗ nào” → Builder có thể thêm phần kiểm tra dữ liệu ngay tại chỗ.

Điều quan trọng là mô tả cụ thể những gì bạn đã thấy, chứ không phải điều bạn nghĩ là vấn đề. “Ứng dụng gây rối” thì chẳng giúp được gì. “Mình điền ba trường rồi không tìm thấy chỗ để bấm tiếp” thì có.

Bài kiểm thử kiểu người lạ, mỗi lần đều vậy

Trước khi bạn cho rằng đã xong, trước khi chia sẻ nó với người dùng thật, hãy đưa nó cho ai đó không biết bạn là người xây nó. Quan sát họ dùng thử từ đầu. Ghi lại những gì bị lỗi.

Bạn sẽ tìm thấy:

Những lỗi mà bạn không biết là tồn tại
Những luồng thao tác khó hơn bạn tưởng
Những giả định bạn đưa ra mà người dùng không hề chia sẻ

Điều tuyệt vời: bài test này miễn phí, chỉ mất 10 phút, và cắt giảm một nửa số tin nhắn kiểu “sao cái này không chạy vậy?”.

Hãy đổi múi giờ điện thoại của bạn sang một nơi kỳ lạ nào đó, dùng thử ứng dụng của bạn, rồi quay lại cho mình biết nếu bạn tìm thấy điều gì thú vị.