Cách Kiểm Thử App Trước Khi Ra Mắt: Kế Hoạch Thực Tế
Để kiểm thử app trước khi ra mắt, hãy liệt kê vài hành trình mà người dùng phải hoàn thành được, chạy từng hành trình với tư cách người dùng mới hoàn toàn trên máy tính và điện thoại, rồi thử những cách họ có thể gặp trục trặc: dữ liệu trống, đầu vào sai, tài khoản thứ hai, kết nối chậm. Kiểm thử cẩn thận hơn bất cứ thứ gì liên quan đến tiền hoặc dữ liệu riêng tư, và lặp lại các hành trình chính trên URL thật sau khi xuất bản. Cuối cùng, hãy quan sát một người chưa từng thấy app cố gắng sử dụng nó.
Bạn không cần đội QA hay một framework kiểm thử cho việc này. Bạn cần một danh sách, một đến hai giờ, và kỷ luật để thật sự thực hiện từng bước trong danh sách đó.
Bước 1: Ghi lại những hành trình quan trọng
Hành trình là một tác vụ từ đầu đến cuối mà người dùng đến để thực hiện. Đa số app có ba đến sáu hành trình thực sự quan trọng. Với một app đặt lịch:
- Đăng ký và xác nhận tài khoản
- Tìm một lớp học và đặt chỗ
- Hủy một lần đặt chỗ
- Thanh toán cho một gói học
- Nhân viên: xem các lượt đặt chỗ trong ngày
Nếu bạn đã viết user stories, tiêu chí chấp nhận của chúng chính là các trường hợp kiểm thử. Nếu chưa, hãy viết một dòng cho mỗi hành trình, mô tả "thành công" trông như thế nào.
Hãy xếp hạng chúng. Những hành trình tạo ra doanh thu hoặc mà mọi người dùng đều đi qua (đăng ký, đăng nhập, hành động cốt lõi) được kiểm thử trước và kỹ nhất.
Bước 2: Kiểm thử đường đi thuận lợi với tư cách người dùng mới
"Đường đi thuận lợi" là hành trình diễn ra đúng như dự định. Hãy kiểm thử nó như một người lạ sẽ trải nghiệm:
- Dùng một cửa sổ trình duyệt riêng tư, để bạn không đăng nhập và không có dữ liệu đã lưu.
- Dùng một tài khoản mới với địa chỉ email thật mà bạn có thể kiểm tra.
- Bắt đầu từ trang chủ hoặc một đường link, không phải trang bạn đã đánh dấu trong lúc xây dựng.
Người dùng mới không có dữ liệu. Nhiều lỗi chỉ xuất hiện khi một danh sách trống, một hồ sơ chưa có ảnh, hoặc chưa có gì được mua. Tài khoản của chính bạn, đầy dữ liệu thử nghiệm, sẽ che giấu chúng.
Bước 3: Thử làm hỏng nó
Bây giờ hãy lặp lại từng hành trình và cố tình làm điều sai.
| Thử điều này | Bạn đang kiểm tra |
|---|---|
| Gửi form trống, hoặc chỉ có khoảng trắng | Các trường bắt buộc được kiểm soát, với thông báo rõ ràng |
| Văn bản rất dài, emoji, tên có dấu | Bố cục giữ được, dữ liệu lưu đúng |
| Định dạng sai: chữ trong ô số điện thoại, ngày quá khứ | Xác thực cả trên trang lẫn trên máy chủ |
| Nhấn đúp nút gửi | Không có đơn hàng hoặc lượt đặt chỗ bị trùng |
| Nút quay lại của trình duyệt giữa chừng | Không có trạng thái hỏng hoặc mất dữ liệu |
| Tải lại mọi trang | Dữ liệu được giữ lại; không có trang trắng hay 404 |
| Đăng xuất, rồi nhấn quay lại | Các trang riêng tư không hiển thị |
| Hai tab cùng sửa một thứ | Lần lưu sau không lặng lẽ xóa lần lưu trước |
Việc tải lại đáng được lưu ý riêng: nếu app hoạt động khi bạn bấm qua, nhưng tải lại một trang sâu hơn hiện 404, hãy xem cách sửa lỗi 404 sau khi triển khai.
Bước 4: Kiểm thử quyền truy cập bằng hai tài khoản
Đây là bài kiểm thử quan trọng nhất đối với mọi app có tài khoản, và cũng là bài thường bị bỏ qua nhất.
Tạo hai người dùng bình thường, A và B, và (nếu app có) một admin.
- Với tư cách A, tạo một bản ghi. Đăng nhập với tư cách B. B có thấy, sửa hoặc xóa nó được không? Họ không nên làm được, trừ khi đó là thiết kế có chủ đích.
- Với tư cách A, sao chép URL của một bản ghi. Đăng nhập với tư cách B và mở trực tiếp URL đó.
- Với người dùng bình thường, thử mở trang admin bằng cách gõ URL của chúng.
- Đăng xuất hoàn toàn và thử các URL tương tự.
Nếu bạn tìm thấy vấn đề ở đây, đừng ra mắt cho đến khi nó được sửa. Việc kiểm tra phải diễn ra trên máy chủ, không chỉ bằng cách ẩn một nút. Danh sách kiểm tra bảo mật cho app do AI xây dựng đi sâu hơn.
Bước 5: Kiểm thử trên thiết bị thật
Mở app trên một chiếc điện thoại thật, không chỉ trong một cửa sổ trình duyệt hẹp.
- Bạn có thể chạm vào mọi nút mà không cần phóng to không?
- Bàn phím có che ô bạn đang gõ không?
- Bảng và nội dung rộng có cuộn hoặc xuống dòng, thay vì đẩy cả trang sang ngang không?
- Văn bản có dễ đọc mà không cần chụm ngón tay không?
Hãy thử ít nhất một chiếc iPhone (Safari) và một điện thoại Android (Chrome), nếu bạn có thể mượn. Riêng Safari có những đặc thù riêng với ngày tháng, video và các phần tử cố định.
Bước 6: Kiểm thử tiền và email từ đầu đến cuối
Bất cứ thứ gì trừ tiền thẻ hoặc gửi email đều cần được chạy thử toàn bộ.
Thanh toán. Dùng chế độ test của nhà cung cấp thanh toán và số thẻ thử nghiệm. Kiểm tra một thanh toán thành công, một thẻ bị từ chối, và một lần thanh toán bị hủy. Xác nhận đơn hàng hoặc gói đăng ký hiển thị trong app sau khi thanh toán, không chỉ trên bảng điều khiển của nhà cung cấp. Nếu app của bạn phụ thuộc vào webhook (thông điệp mà nhà cung cấp thanh toán gửi đến máy chủ của bạn), hãy kiểm tra chúng đến được app đã xuất bản, không chỉ trong môi trường phát triển. Sau đó, trước khi ra mắt, chuyển sang khóa thật và thực hiện một giao dịch thật nhỏ rồi hoàn tiền.
Email. Đăng ký bằng địa chỉ thật ở hai hoặc ba nhà cung cấp khác nhau. Kiểm tra email có đến nơi, không rơi vào thư rác, và mọi liên kết trong email đều trỏ đến tên miền thật, không phải địa chỉ xem trước.
Bước 7: Kiểm tra tốc độ và lỗi
- Mở công cụ dev của trình duyệt (chuột phải → Inspect) và xem tab Console trên mỗi trang chính. Các lỗi màu đỏ đáng được sửa ngay cả khi bề ngoài không có gì hỏng.
- Tải trang trên điện thoại bằng dữ liệu di động, không phải Wi-Fi. Nếu màn hình đầu tiên mất vài giây, hãy xem kích thước ảnh trước.
- Chạy một bài kiểm tra miễn phí như Lighthouse trong công cụ dev của Chrome để có đánh giá nhanh về hiệu năng và khả năng truy cập.
Bước 8: Kiểm thử app đã xuất bản, không chỉ bản xem trước
Bản xem trước và app đã xuất bản không phải là cùng một môi trường. Trước khi thông báo cho ai về việc ra mắt, hãy lặp lại các hành trình chính trên URL thật:
- Mọi biến môi trường và khóa bí mật đã được đặt cho app đã xuất bản chưa?
- App có đang dùng đúng cơ sở dữ liệu, với dữ liệu bạn mong đợi không?
- Chuyển hướng sau đăng nhập và liên kết trong email có dùng tên miền thật không?
- Tải lại một trang sâu có hiển thị đúng không?
Bước 9: Quan sát người khác dùng app
Đưa cho một hoặc hai người một mục tiêu ("đặt một lớp yoga vào thứ Bảy"), không phải hướng dẫn. Quan sát, đừng giúp, và ghi lại những chỗ họ ngập ngừng. Đây là cách nhanh nhất để tìm ra cách diễn đạt khó hiểu và các nút ẩn. Để có phiên bản lớn hơn của việc này, xem cách chạy beta test.
Khi họ gặp lỗi, hãy ghi lại đầy đủ: các bước, kết quả mong đợi và kết quả thực tế. Hướng dẫn về viết báo cáo lỗi tốt trình bày định dạng.
Dùng AI để hỗ trợ kiểm thử
Nếu bạn xây dựng bằng AI, bạn có thể nhờ nó giúp lên kế hoạch và chạy kiểm thử:
Liệt kê các hành trình người dùng chính của app này và, với mỗi hành trình, các trường hợp biên dễ gây lỗi nhất: trạng thái trống, đầu vào không hợp lệ, quyền truy cập và tải lại. Đưa vào một danh sách kiểm tra để tôi làm theo.
Đăng nhập bằng hai tài khoản thử nghiệm khác nhau và kiểm tra xem người dùng B có thể xem hoặc thay đổi bất cứ thứ gì người dùng A đã tạo không, kể cả khi mở trực tiếp URL bản ghi của A. Báo cáo những gì bạn tìm thấy trước khi sửa bất cứ thứ gì.
Hãy coi báo cáo kiểm thử của AI là lượt quét đầu tiên. Vẫn tự mình bấm qua các hành trình về tiền và quyền truy cập.
Kiểm thử trong Mythex
Trong Mythex, lệnh /test chạy App Testing: agent điều khiển một trình duyệt trên bản xem trước trực tiếp của bạn, bấm qua các trang, chụp ảnh màn hình và báo cáo các luồng bị lỗi trong chat. Nó hoạt động tốt nhất với một hành trình cụ thể, chẳng hạn "kiểm thử đăng ký và đặt một lớp học". Sửa những gì nó tìm thấy bằng /fix hoặc một tin nhắn thông thường, rồi chạy /test lại. App Testing dùng bản xem trước, vì vậy sau khi xuất bản, hãy tự kiểm tra các hành trình chính trên URL đã xuất bản. Xem App Testing trong tài liệu, và hướng dẫn về gỡ lỗi app do AI xây dựng khi có gì đó thất bại.
Những lỗi thường gặp
- Chỉ kiểm thử bằng chính mình. Tài khoản admin của bạn với nhiều dữ liệu che giấu các lỗi trạng thái trống và lỗi quyền truy cập.
- Chỉ kiểm thử trên máy tính. Với nhiều trang web, phần lớn khách truy cập đến từ điện thoại.
- Bỏ qua tài khoản thứ hai. Dữ liệu bị rò rỉ giữa các người dùng là lỗi nghiêm trọng nhất mà một app có thể ra mắt cùng.
- Tin tưởng bản xem trước. App đang chạy thật có cấu hình khác; hãy kiểm thử cả nó.
- Sửa lỗi mà không kiểm thử lại các phần lân cận. Một bản sửa cho một form có thể làm hỏng một form khác dùng chung code.
Danh sách kiểm tra trước khi ra mắt
- Các hành trình chính đã được liệt kê và xếp hạng
- Mỗi hành trình đều đạt khi là người dùng mới trong cửa sổ riêng tư
- Đầu vào trống, không hợp lệ, quá dài và trùng lặp đều được xử lý
- Tải lại hoạt động trên mọi trang
- Người dùng không thể xem hoặc thay đổi dữ liệu của nhau, kể cả qua URL
- Trang admin bị chặn với người dùng thường và khách chưa đăng nhập
- Hoạt động trên iPhone thật và điện thoại Android thật
- Đã kiểm thử thanh toán: thành công, bị từ chối, hủy, và app được cập nhật sau đó
- Email đến nơi, không vào thư rác, và liên kết trỏ đến tên miền thật
- Không có lỗi đỏ trong console trên các trang chính
- Các hành trình chính được lặp lại trên URL đã xuất bản
- Ít nhất một người bên ngoài đã dùng thử khi bạn đang quan sát
Câu hỏi thường gặp
Một app nhỏ cần kiểm thử bao nhiêu trước khi ra mắt?
Đủ để tin chắc rằng các hành trình chính hoạt động với người dùng mới hoàn toàn trên cả điện thoại và máy tính, rằng người dùng không thể xem dữ liệu của nhau, và rằng mọi thứ liên quan đến tiền hoạt động trọn vẹn từ đầu đến cuối. Với đa số app nhỏ, đó là vài giờ tập trung, không phải nhiều tuần.
MVP có cần kiểm thử tự động không?
Không nhất thiết. Kiểm thử thủ công các hành trình cốt lõi bắt được hầu hết các lỗi chặn việc ra mắt. Kiểm thử tự động bắt đầu có giá trị khi bạn thường xuyên thay đổi app và muốn biết nhanh rằng mình không làm hỏng thứ từng hoạt động.
Nên kiểm thử trên bản xem trước hay trên app đang chạy thật?
Cả hai. Hãy kiểm thử kỹ trên bản xem trước, sau đó lặp lại các hành trình chính trên app đã xuất bản, vì thiếu biến môi trường, cơ sở dữ liệu khác hoặc cấu hình định tuyến có thể làm phiên bản thật hoạt động khác đi.
Ngoài bạn ra, ai nên kiểm thử app?
Ít nhất một người chưa từng thấy app. Hãy giao cho họ một mục tiêu, không phải hướng dẫn, và quan sát mà không giúp đỡ. Người xây dựng vô thức tránh những đường đi có thể gây lỗi.