Cách kiểm thử app làm bằng AI khi bạn chưa từng kiểm thử phần mềm bao giờ

Bạn đã xây một app bằng AI. Nó chạy được trên đường suôn sẻ — bạn gõ tên mình, bấm nút, thấy màn hình thành công. Giờ thì sao? Nó đã sẵn sàng gửi cho ba người dùng thử nghiệm của bạn chưa? Cho đội của bạn? Cho khách hàng của bạn?

Nếu bạn không có nền tảng về phần mềm, kiểm thử nghe như một trong những thứ mà “lập trình viên thực thụ” mới làm — với framework, assertion, và đủ thứ quy trình CI. Tin vui: phần lớn việc kiểm thử thật ra không phải vậy. Phần lớn việc kiểm thử, nhất là khi bạn đang ra mắt một thứ nhỏ và mới, chỉ là một người bấm loanh quanh một cách có chủ đích. Việc đó bạn làm được. Bài viết này nói về việc làm điều đó một cách có chủ ý, để bạn tìm ra lỗi trước khi người dùng tìm ra.

Mục tiêu không phải là kiểm thử app làm bằng AI của bạn như một dân chuyên. Mà là kiểm thử nó như một người bạn đa nghi thật lòng muốn nó hoạt động.

Mẹo hai danh sách

Trước khi bấm bất cứ thứ gì, hãy ngồi xuống mười phút với một tài liệu trắng và viết hai danh sách.

Danh sách A — những đường suôn sẻ. Ba bốn việc mà một người dùng đáng lẽ làm với app này là gì? Với một sản phẩm SaaS điển hình, đó có thể là: đăng ký, tạo dự án đầu tiên, mời một đồng đội, xuất một kết quả. Với một app kiểu danh bạ: tìm kiếm, lọc, bấm vào một mục, lưu nó lại. Ba bốn luồng thật, bằng ngôn ngữ đời thường.

Danh sách B — những đường trục trặc. Sẽ ra sao nếu người dùng làm một thứ gần đúng nhưng không hẳn? Gõ email kèm một lỗi đánh máy. Bấm nút quay lại giữa chừng. Mở hai tab và chỉnh cùng một thứ ở cả hai. Gửi một biểu mẫu trống không. Dán nội dung của một file Word — kèm cả định dạng — vào một ô văn bản. Đóng laptop rồi mở lại sau mười phút. Cố mời một đồng đội bằng một địa chỉ email đã có sẵn trong hệ thống.

Danh sách đường suôn sẻ là thứ mà công cụ tạo app bằng AI của bạn đã tối ưu cho. Đó là thứ AI thầm kiểm thử trong đầu khi nó viết code. Danh sách đường trục trặc mới là nơi lỗi ẩn náu, bởi gần như chẳng ai — không phải AI, không phải bạn lúc đang ra lệnh — nghĩ đến những trường hợp đó.

Khi thật sự kiểm thử, hãy đi qua Danh sách A trước để xác nhận những thứ cơ bản chạy được. Rồi dành phần lớn thời gian cho Danh sách B. Danh sách B là nơi có giá trị. Danh sách B cũng là nơi bạn phát hiện ra mình thật sự muốn app làm gì khi mọi thứ đi chệch hướng, điều thường buộc phải có một cuộc trò chuyện làm rõ với công cụ AI (“khi biểu mẫu mới điền một nửa, nó nên cảnh báo hay tự lưu?”).

Ba thứ cần cố tình làm hỏng

Một khi bạn đã có hai danh sách, đây là ba nhóm bắt được phần lớn các lỗi thật trong app làm bằng AI.

Đầu vào trống và kỳ quặc. Gửi biểu mẫu mà không điền gì cả. Gửi nó với chỉ một ô được điền. Gửi một cái tên dài 500 ký tự. Gửi một cái tên có emoji. Dán một URL vào một ô vốn để nhập tên. Thử ô email với “test”, với “test@”, với “test@example”, với địa chỉ “a@b.co” — nó có chấp nhận những email ngắn nhưng hợp lệ không? Các công cụ tạo app bằng AI thường thêm cơ chế kiểm tra hợp lệ, nhưng việc kiểm tra đó có thể sai theo cả hai hướng — quá chặt (từ chối người dùng thật) hoặc quá lỏng (chấp nhận rác).

Đi lùi và đi ngang. Hầu hết các app chạy ổn nếu bạn đi qua chúng như một đoàn du lịch ngoan ngoãn. Chúng hỏng ngay khoảnh khắc có người đi khám phá lung tung. Bấm nút quay lại. Bấm tiến tới. Tải lại trang giữa chừng một luồng. Mở cùng một trang trong hai tab và chỉnh ở cả hai. Đăng xuất rồi đăng nhập lại. Nếu bạn có nút “hoàn tác”, hãy bấm nó ba lần liền. Đây không phải những trường hợp ngoại lệ. Đây là cách người thật dùng phần mềm.

Dữ liệu về sau. Hãy xây cái thứ mà app của bạn tạo ra. Một dự án, một bài đăng, một bản ghi, bất cứ thứ gì. Rồi mai quay lại. Nó còn ở đó không? Định dạng còn nguyên không? Nếu bạn chỉnh sửa nó, chỉnh sửa có được lưu không? Nếu bạn xóa nó, nó có thật sự biến mất, hay nó quay lại khi bạn tải lại trang? Các công cụ tạo app bằng AI thường làm rất chuẩn luồng “tạo” mà quên rằng mọi thứ bạn tạo ra đều cần được lưu lại và chỉnh sửa được về sau.

”Đủ tốt” trông như thế nào

Bạn sẽ không bao giờ kiểm thử app làm bằng AI của mình đến mức hoàn hảo. Phần mềm thì quá chằng chịt còn thời gian của bạn thì quá quý giá. Câu hỏi không phải là “nó đã hoàn hảo chưa” — mà là “nó đã đủ tốt cho nhóm người tiếp theo mà tôi sắp đặt nó trước mặt chưa”.

Đây là một thang bậc đại khái mà bạn có thể mượn.

Đủ tốt để demo: đường suôn sẻ chạy được mà không bị treo. Các nút dẫn tới đúng chỗ chúng cần dẫn. Bạn có thể quay màn hình mà không phải cắt bỏ đoạn nào.

Đủ tốt cho người dùng thân thiện: các đường trục trặc không làm mất dữ liệu. Biểu mẫu báo cho bạn biết cái gì sai thay vì thất bại một cách lặng lẽ. Tải lại trang không làm hỏng mọi thứ. Ba người bạn có thể dùng nó mà không nhắn tin cầu cứu bạn.

Đủ tốt cho người dùng trả tiền: app xử lý được những người dùng mà bạn chưa từng gặp. Trình duyệt của họ, dữ liệu của họ, thói quen của họ. Bạn có cách để thấy khi mọi thứ hỏng (theo dõi lỗi cơ bản là đủ — bạn không cần một bảng điều khiển hào nhoáng). Bạn có thể sửa và triển khai lại mà không làm hỏng những người đang dùng.

Hầu hết người xây ra mắt ở mức “người dùng thân thiện” rồi nâng cấp dần khi phản hồi đổ về. Đó là cách đúng. Sai lầm là cố nhảy từ “đủ tốt để demo” thẳng lên “đủ tốt cho người dùng trả tiền” mà bỏ qua bước trung gian. Người dùng thân thiện tìm ra những thứ mà người dùng thật cũng sẽ tìm ra — nhưng họ không nổi giận vì chúng. Hãy tận dụng khoảng đệm đó.

Khi nào nên nhờ AI kiểm thử thay bạn

Công cụ tạo app bằng AI của bạn có thể giúp kiểm thử, nhưng bạn phải cụ thể về thứ bạn muốn. “Thêm test đi” là một câu lệnh dở. Nó sẽ tạo ra code trông như test và có lẽ chạy qua hết, mà không thật sự kiểm tra bất cứ điều gì bạn quan tâm. Hầu hết những test tự sinh đó chỉ xác nhận rằng 1+1 vẫn bằng 2.

Một câu lệnh tốt hơn: “Tôi vừa thử gửi biểu mẫu đăng ký với ô email để trống và nó bị treo. Hãy tìm chỗ xử lý việc đó và thêm một bước kiểm tra để hiển thị một lỗi thân thiện thay vì treo.” Lỗi cụ thể, cách sửa cụ thể, kết quả cụ thể. AI làm việc này giỏi. Nó làm dở câu “đảm bảo app của tôi không còn lỗi” vì đó không phải một nhiệm vụ — đó là một điều ước.

Thứ khác mà các công cụ AI làm giỏi là tái hiện lại lỗi của bạn. Nếu bạn mô tả mình đã làm gì, mong đợi gì, và chuyện gì đã xảy ra, công cụ thường có thể lần theo code và đề xuất một cách sửa. Kỷ luật bạn cần là kỷ luật ghi lại ba điều đó một cách rõ ràng. Hầu hết các báo cáo lỗi của người mới là một biến thể nào đó của “nó không chạy”. Hầu hết các báo cáo lỗi sửa được là “tôi bấm X, mong đợi Y, nhận được Z”.

Kiểm thử là đọc, không chỉ là bấm

Một điều cuối. Bạn không cần hiểu từng dòng code trong app làm bằng AI của mình để kiểm thử nó tốt. Nhưng ít nhất bạn nên lướt qua. Mở file mà AI vừa thay đổi. Đọc hàm mà nó vừa thêm vào. Bạn không cần biết mỗi từ khóa nghĩa là gì — bạn cần biết liệu cái hàm đó có vẻ đang làm đúng thứ bạn yêu cầu hay không.

Rất nhiều lỗi trong app làm bằng AI không phải là “code bị hỏng”. Chúng là “code làm một thứ hơi khác với điều bạn muốn”. Một ô lưu vào sai chỗ. Một cái nút cập nhật một thứ nhưng không cập nhật thứ liên quan. Một nút “xóa” lại ẩn đi thay vì xóa. Bạn không thể bắt được những lỗi đó nếu không đọc thứ thật sự được xây ra.

Hãy coi code là thứ bạn có thể soát xét, chứ không phải thứ bạn buộc phải viết. Đó là sự khác biệt giữa một app làm bằng AI mà bạn tin tưởng và một app mà bạn chỉ hy vọng nó chạy.

Phiên bản gọn gàng

Nếu bạn chẳng nhớ điều gì khác: hãy viết hai danh sách, cố tình làm hỏng mọi thứ, và quyết định bạn đang ra mắt ở mức “đủ tốt” nào. Hầu hết lỗi trong một app làm bằng AI đều không tinh vi. Chúng đang nằm sờ sờ trên danh sách đường trục trặc mà chẳng ai buồn viết ra.

Nếu bạn muốn một bài tập nhỏ về nhà: hãy chọn một app bạn đã xây và thử bốn việc — gửi một biểu mẫu trống, tải lại trang giữa chừng một luồng, chỉnh sửa một bản ghi rồi mai kiểm tra lại, và nhờ một người bạn dùng nó mà bạn không đứng cạnh xem. Bất cứ thứ gì hỏng chính là danh sách lỗi thật của bạn. Mọi thứ khác chỉ là chần chừ.