Cách kiểm thử ứng dụng xây bằng AI trước khi ra mắt

Với Claude Code, Cursor, Lovable, Bolt, Replit hay v0, chỉ vài ngày là bạn đã có một app chạy được. Bản demo mượt, màn hình đẹp, luồng chính hoạt động đúng như mong đợi.

Nhưng lỗi thường không nằm ở luồng chính. AI viết code để đáp ứng đúng prompt bạn đưa ra. Nó không biết nghiệp vụ của bạn, không biết người dùng thật sẽ thao tác ra sao, cũng không tự nghĩ đến chuyện hai người cùng sửa một đơn hàng, trừ khi bạn nói cho nó biết. Dưới đây là checklist chúng tôi luôn chạy trước khi một app xây bằng AI được đưa lên production.

App xây bằng AI hay lỗi ở đâu?

Có ba kiểu lỗi rất đặc trưng:

• Code đúng prompt nhưng sai nghiệp vụ. Tính năng chạy đúng như yêu cầu, nhưng thiếu những quy tắc bạn chưa từng viết ra: ai được sửa đơn, sau 30 ngày còn được hoàn tiền không.
• Test do AI viết thường có cùng điểm mù với code. Khi cùng một công cụ vừa viết tính năng vừa viết test, test chủ yếu xác nhận lại những gì code đang làm, chứ không kiểm tra xem code có làm đúng hay không.
• Sửa chỗ này, hỏng chỗ kia. Mỗi prompt mới có thể viết lại những file mà tính năng cũ đang dùng. Không có kiểm thử hồi quy thì thường người dùng là người phát hiện ra đầu tiên.

Không phải app xây bằng AI thì kém chất lượng. Chỉ là việc kiểm thử phải xuất phát từ nghiệp vụ, từ người dùng và từ những tình huống có thể hỏng, chứ không chỉ từ code.

1. Liệt kê các luồng quan trọng trước tiên

Trước khi test bất cứ thứ gì, hãy ghi ra năm đến mười luồng mà app tuyệt đối không được lỗi. Với hầu hết các app, danh sách sẽ gần giống thế này:

1. Đăng ký, xác nhận tài khoản, đăng nhập.
2. Thao tác chính: đặt hàng, đặt lịch, đăng bài.
3. Thanh toán và nhận hóa đơn.
4. Quên mật khẩu và đặt lại.
5. Admin tìm và xử lý vấn đề cho một người dùng.

Mọi bước sau đều bám theo danh sách này. Nếu chỉ có thời gian làm một việc, hãy test trọn vẹn các luồng này, cả trên điện thoại lẫn máy tính.

2. Đăng nhập, phiên và mật khẩu

Phần đăng nhập thường được AI viết rất nhanh nhưng ít ai test kỹ. Hãy thử:

• Link đặt lại mật khẩu có hết hạn không, dùng lại lần hai được không?
• Đăng xuất trên một thiết bị rồi quay lại tab cũ: có còn thao tác được không?
• Khi phiên hết hạn, app có đưa người dùng về trang đăng nhập không, hay hiện màn hình lỗi?
• Đăng ký bằng email đã tồn tại, email viết hoa, email có khoảng trắng ở cuối.

3. Phân quyền và cô lập dữ liệu

Đây là chỗ app xây bằng AI hay để lộ dữ liệu nhất. Từng người dùng riêng lẻ thì mọi thứ đều ổn, nhưng không ai kiểm tra xem người dùng A có xem được dữ liệu của người dùng B hay không.

Tạo hai tài khoản test, đăng nhập bằng tài khoản A rồi thử:

• Đổi ID trên URL để mở đơn hàng, hồ sơ hoặc hóa đơn của tài khoản B.
• Gửi lại đúng request API đó nhưng thay bằng ID của tài khoản B.
• Gọi API lấy danh sách và xem nó có chỉ trả về dữ liệu của chính bạn không.

Nhiều app dùng Supabase hay Firebase gọi thẳng database từ trình duyệt. Khi đó, quy tắc truy cập của chính database (ví dụ row-level security) mới là lớp bảo vệ thật sự. Hãy kiểm tra để chắc chắn bảng nào cũng có, không riêng những bảng được nhắc đến trong prompt.

4. Dữ liệu nhập và các trường hợp biên

Form do AI tạo thường chỉ chạy đúng với dữ liệu mẫu. Hãy thử thêm:

• Để trống, nhập chuỗi rất dài, emoji, tiếng Việt có dấu.
• Bấm nút gửi hai lần liên tiếp.
• Mạng chậm hoặc rớt mạng đúng lúc đang lưu.
• Ngày giờ qua nửa đêm, khác múi giờ, số tiền có phần lẻ.

5. Thanh toán

Đã dính đến tiền thì phải test thật kỹ:

• Một lần bấm có tạo ra hai giao dịch hoặc hai đơn hàng không?
• Cổng thanh toán gửi xác nhận hai lần, hoặc gửi muộn, thì chuyện gì xảy ra?
• Hoàn tiền, mã giảm giá và làm tròn có ra đúng tổng không?
• Thanh toán thất bại thì trạng thái đơn hàng có khớp với trạng thái thanh toán không?

6. Màn hình lỗi và màn hình trống

Mở những màn hình mà bản demo chưa từng hiện: không có kết quả, mất mạng, lỗi server, dữ liệu đã bị xóa. Một trang trắng trơn hay một thông báo lỗi kỹ thuật khó hiểu vẫn là bug, dù app không hề crash.

7. Điện thoại thật, nhiều kích thước màn hình

Đừng chỉ thu nhỏ trình duyệt, hãy mở app trên điện thoại thật. Kiểm tra xem nút có dễ bấm không, có bị cuộn ngang không, và bàn phím có che mất ô đang nhập không.

8. API key và cấu hình

Tìm trong bản build xem có lọt API key hay thông tin đăng nhập dịch vụ nào không. Thứ gì đã gửi xuống trình duyệt thì coi như công khai. Key của server phải nằm trên server, và cấu hình môi trường test không được lẫn với production.

9. Tự động hóa các luồng quan trọng

Khi các luồng quan trọng đã chạy đúng lúc test tay, hãy tự động hóa chúng để mỗi lần prompt và sửa code đều được kiểm tra lại. Chỉ cần vài test end-to-end bằng Playwright, Cypress hoặc Selenium là đủ để bắt đầu. Ví dụ, test dưới đây đảm bảo một người dùng không mở được đơn hàng của người khác:

import { expect, test } from '@playwright/test';

test("a user cannot open someone else's order", async ({ page }) => {
  await logInAs(page, 'user-a@example.com');
  const response = await page.goto('/orders/ORDER-OF-USER-B');
  expect(response?.status()).toBe(404);
  await expect(page.getByText('ORDER-OF-USER-B')).toHaveCount(0);
});

Cho các test này chạy ở mỗi lần thay đổi, trước khi deploy.

10. Kiểm tra lại ngay sau khi deploy

Bản release đã pass hết test vẫn có thể lỗi trên production: thiếu biến môi trường, migration database có vấn đề, cấu hình thanh toán sai. Ngay sau mỗi lần deploy, hãy đi lại các luồng quan trọng trên app thật. Chỉ mất vài phút, nhưng bạn sẽ bắt được lỗi trước khi người dùng gặp phải.

Tóm lại

• Liệt kê các luồng quan trọng và test trọn vẹn từng luồng.
• Test phân quyền bằng hai tài khoản: lộ dữ liệu thường nằm ở đây.
• Thử những dữ liệu và tình huống mà bản demo chưa từng gặp.
• Thanh toán, màn hình lỗi và điện thoại thật đều phải được test kỹ như luồng chính.
• Tự động hóa các luồng quan trọng và kiểm tra lại sau mỗi lần deploy.

Tại Red Giant, chúng tôi làm đúng như vậy, kể cả với ShipMe, app chúng tôi xây bằng công cụ lập trình AI và đang vận hành thực tế.