6 phút đọcRead in English
VibeQA có gì khác
VibeQA khác các công cụ kiểm thử AI ở đâu: bạn review test design, mỗi phiên bản do một người duyệt, và run đỏ nghĩa là app của bạn hỏng thật.
Muốn có test end-to-end cho một web app, bạn đã có vài cách. Tự viết Playwright, dùng công cụ record-and-replay để ghi lại các cú click, hoặc nhờ một công cụ kiểm thử AI viết thẳng code test. Cách nào cũng kết thúc bằng một đoạn code chạy được.
VibeQA cũng kết thúc ở đó. Cái nó thay đổi là team bạn review cái gì, ai được nói một suite đã sẵn sàng, và một kết quả đỏ có nghĩa là gì. Dưới đây là từng điểm khác, kèm cơ chế đứng sau.
Bạn review thiết kế, không phải một file code
Khi Tokay, agent của chúng tôi, viết một suite, nó bắt đầu bằng test design chứ không phải code.
Design đi từ yêu cầu, tới cây phân lớp (mỗi input chia thành các lớp hợp lệ và không hợp lệ, có đánh
dấu giá trị biên), tới các kịch bản Gherkin mà mỗi dòng Examples là một test case cụ thể. Với ô số
điện thoại ở bước checkout của Storefront, đó là một bảng ngắn: số di động 10 chữ số, định dạng +84,
9 chữ số, 11 chữ số, có chữ cái. Một QA lead đọc trong một phút là thấy thiếu gì.
Coverage được tính từ design bằng một quy tắc cố định: mỗi lớp xuất hiện ít nhất một lần, mọi giá trị biên đều được test, mỗi dòng có tối đa một lớp không hợp lệ, và test theo cặp các lớp hợp lệ với yêu cầu rủi ro cao. Tokay không tự khai coverage, người review cũng không. Cùng một design thì luôn ra cùng một kết quả. Chi tiết ở bài Thiết kế test trước, viết code sau.
Mỗi phiên bản đều do một người duyệt
Tokay soạn design, trả lời comment bằng những đề xuất sửa để bạn chấp nhận hay từ chối, rồi viết
code: mỗi dòng được tự động hoá thành một test Playwright mang tên của dòng đó, ví dụ TC-2.3. Nó
không bao giờ tự duyệt việc mình làm.
Chỉ người có vai trò owner hoặc admin mới duyệt được một phiên bản, và hệ thống kiểm tra phiên bản đó đã sẵn sàng chưa: code được sinh từ đúng design này, coverage đã đủ, không còn thread comment nào mở, mọi case đã được một người review ở dạng hiện tại, và đã có một lần chạy thử (dry run) chạy xong, báo kết quả cho mọi dòng tự động. Dòng fail vẫn được phép, vì test tái hiện lỗi vốn phải fail.
Pass hay fail là do runner quyết định
Một run pass hay fail dựa trên hai thứ test runner để lại: exit code và file report.json. Không dựa
vào log, và không dựa vào việc một model đọc output rồi đưa ra ý kiến. Test có thể có những bước do
AI thực hiện, nhưng kết luận vẫn là của runner.
Sáu kết quả, không phải hai
Một run đỏ phải có nghĩa là app của bạn hỏng. Vì vậy mỗi run khi kết thúc có một trong sáu kết quả:
Sandbox hết bộ nhớ hay nhà cung cấp model bị timeout là lỗi phía chúng tôi. Chỉ hai loại đó được chạy lại, và chỉ do hàng đợi chạy lại. Một lần fail thật không bao giờ bị chạy đi chạy lại cho tới khi xanh. Đọc thêm ở bài Một run đỏ phải có nghĩa là app của bạn hỏng.
Mỗi run một sandbox mới
Mỗi run bắt đầu trong một sandbox mới, có trình duyệt riêng và mạng riêng, và bị xoá bỏ sau khi chạy xong. Sandbox không chứa secret nào của nền tảng; credential duy nhất bên trong là một token hết hạn cùng run. Test account của một dự án chỉ tới được sandbox của chính dự án đó, và Tokay chỉ thấy tên và username, không bao giờ thấy password.
Bản fix trên Jira được kiểm lại ba lần
Khi một defect được theo dõi trong VibeQA và ticket Jira của nó, ví dụ SHOP-388, chuyển sang Ready for QA, VibeQA chạy test tái hiện lỗi ba lần và comment một kết luận lên ticket: đã fix, vẫn còn lỗi, flaky hoặc bị chặn. Khi các lần chạy không khớp nhau, kết quả là flaky và một người sẽ quyết định. Vì sao là ba lần, và ba lần không bắt được gì, có trong bài Vì sao một bản fix phải chạy ba lần.
Ở ngay chỗ team bạn đang làm việc
Tokay đọc đặc tả từ Jira, Confluence và Notion, còn kết quả được gửi tới Slack và Telegram. Một kết nối thuộc về cả tổ chức hoặc một dự án, và kết nối của dự án được ưu tiên hơn của tổ chức. Mọi thứ Tokay đọc từ ticket, trang tài liệu, file tải lên hay chính app của bạn đều tới model với nhãn dữ liệu không tin cậy, không phải chỉ dẫn để làm theo.
Chạy trên server của bạn, nếu cần
VibeQA có thể chạy trên server của bạn bằng Docker Compose, dùng Anthropic key của bạn, nên các app bạn test không bao giờ rời khỏi mạng nội bộ.
So với Playwright viết tay và các công cụ kiểm thử AI khác
Không lựa chọn nào trong số này là sai. Mỗi cách đánh đổi một kiểu.
Record-and-replay là cách nhanh nhất để ghi lại một luồng bạn đã biết. Bạn có đúng con đường mình đã click. Các case negative và giá trị biên xung quanh nó, và việc biết còn thiếu case nào, vẫn là việc bạn làm tay.
Tự viết Playwright cho bạn toàn quyền kiểm soát, và test nằm ngay trong repo của bạn. Nhưng mọi thứ đều làm tay: có người quyết định case, viết chúng, theo dõi coverage và lo chỗ để chạy. VibeQA cũng sinh ra Playwright; khác biệt là bản design đã được review nằm phía trên, và các run bao quanh.
Để AI viết thẳng code test thì nhanh. Nhưng muốn biết nó đã test gì, bạn phải đọc code, và vài trăm dòng chạy xanh nói rất ít về những case chưa ai nghĩ tới. Nếu chính agent đó cũng báo run pass hay fail, thì không có gì độc lập đứng sau kết quả.
Những gì chưa làm được
Hiện VibeQA test web app; Android và iOS sẽ đến sau. Nếu app của bạn đăng nhập bằng magic link hay social login, bạn export một phiên đã đăng nhập cho test dùng, và tự thay khi phiên đó hết hạn. Kết nối Jira và Confluence dùng Atlassian API token, hoạt động với danh nghĩa một người. Và viết design trước thì chậm hơn nhờ AI viết code ngay. Chúng tôi nghĩ thứ bạn được review xứng đáng với khoảng chờ đó.