6 phút đọcRead in English
Làm quen với VibeQA và Tokay
VibeQA là công cụ test tự động bằng AI cho web app: Tokay viết test design và code, con người duyệt cả hai. Toàn bộ vòng lặp, từ ticket Jira tới bản fix.
Trong bài trước, chúng tôi đã kể ra những lý do bộ test end-to-end dần xuống cấp: test flaky, selector dễ vỡ, file không ai đọc nổi, những lần chạy đỏ hoá ra do môi trường, và coverage không ai nói rõ được. VibeQA, một công cụ test tự động bằng AI cho web app, là câu trả lời của chúng tôi cho những vấn đề đó. Bài này nói VibeQA là gì, dành cho ai, và các phần ghép với nhau ra sao.
VibeQA là gì
VibeQA là công cụ test cho web app. Một AI agent tên Tokay đọc ticket và tài liệu đặc tả của bạn, viết một test design để team review, sinh code automation từ design đó, rồi chạy nó trong một sandbox mới. Con người ra quyết định: case nào đúng, phiên bản nào được đưa vào dùng, và một lần chạy fail có ý nghĩa gì với ticket.
VibeQA dành cho những team release web app khoảng mỗi tuần một lần và cần bộ test regression đáng tin: QA lead chịu trách nhiệm kế hoạch test, developer muốn biết bản fix của mình có hiệu quả không, và engineering manager muốn biết "xanh" thực ra bao phủ những gì.
Vì sao lại là tắc kè
Tokay được đặt theo tên loài tắc kè tokay, mà tên loài này lại lấy từ tiếng kêu của nó: "to-kay". Một câu đùa nhỏ nhưng có ý. Tokay làm phần viết, nhưng không tự duyệt được việc của mình. Mọi phiên bản suite đều do một người duyệt, và chỉ duyệt được khi mọi case đã được review, coverage đã đủ và lần chạy thử đã xong.
Vòng lặp test tự động bằng AI, từ đầu tới cuối
1. Bắt đầu từ thứ bạn đã có
Đưa cho Tokay một ticket Jira, một trang Confluence hay Notion, một tài liệu bạn upload (PDF hoặc Word), hoặc chỉ cần mô tả luồng trong một câu. Giả sử SHOP-388 mô tả bước giao hàng của Storefront: khách nhập số điện thoại và địa chỉ, cả hai được kiểm tra trước khi thanh toán. Mọi thứ Tokay đọc từ ticket, từ một trang tài liệu hay từ app của bạn đều được gắn nhãn là văn bản không tin cậy, nên một chỉ dẫn giấu trong ticket chỉ được coi là nội dung, không phải mệnh lệnh.
2. Review test design, không phải file test
Trước khi có code, Tokay viết test design: các yêu cầu, mỗi input được chia thành lớp hợp lệ và không hợp lệ có đánh dấu giá trị biên, và các kịch bản Gherkin mà mỗi dòng Examples là một case cụ thể. Với ô số điện thoại, đó là các dòng cho số di động 10 chữ số, định dạng +84, 9 chữ số, 11 chữ số và số có chữ cái.
Coverage được tính bằng một quy tắc cố định, Tokay hay người review đều không tự khai: mỗi lớp xuất hiện
ít nhất một lần, mọi giá trị biên đều được test, và không dòng nào chứa hai lớp không hợp lệ cùng lúc.
Team bạn review từng case một: bấm "Đúng rồi", sửa tay, hoặc comment @Tokay rồi chấp nhận hay từ chối
thay đổi nó đề xuất. Các quy tắc này được giải thích kỹ trong
Thiết kế test trước, viết code sau.
3. Sinh code, rồi chạy thử một lần
Khi mọi case đã được review và coverage đã đủ, Tokay biến mỗi case tự động thành một test dựa trên
Playwright, đặt tên theo case, ví dụ TC-1.2. Phiên bản mới được chạy thử một lần trong sandbox, và kết
quả từng test được map ngược về đúng dòng của nó trong design. Sau đó một người duyệt phiên bản. Một case
fail vẫn có thể được duyệt, vì test tái hiện một lỗi đã biết thì đương nhiên phải fail.
4. Chạy trong một sandbox mới
Mỗi lần chạy có sandbox riêng, với trình duyệt và mạng riêng. Bên trong không có secret nào của nền tảng; credential duy nhất là một token chỉ dùng được cho lần chạy đó. Test account bạn thêm vào một dự án chỉ tới được các lần chạy của dự án đó. Bạn có thể chạy bằng tay ("Chạy tất cả suite"), theo lịch, hoặc từ CI bằng API key.
Khi một lần chạy không xong được vì sự cố phía chúng tôi, như sandbox hay nhà cung cấp model, nó được ghi là lỗi hạ tầng hoặc lỗi model, được hàng đợi chạy lại, và không bao giờ hiện thành lỗi của app bạn.
5. Theo dõi defect và kiểm lại bản fix
Khi một test fail vì app hỏng thật, nút "Báo lỗi" trên trang lần chạy sẽ tạo một bug trên Jira hoặc gắn với một ticket có sẵn, lấy phiên bản suite làm bản tái hiện lỗi. Bạn cũng có thể đi từ đầu kia: chọn "Theo dõi ticket Jira" ở trang Defect, rồi gắn một test tái hiện đã được duyệt, hoặc nhờ Tokay viết nháp một test để người duyệt.
Khi ticket chuyển sang trạng thái bạn chọn, VibeQA chạy test tái hiện ba lần trong các sandbox mới và comment một kết luận lên Jira: đã fix, vẫn còn lỗi, flaky hoặc bị chặn. Vì sao là ba lần thì có một bài riêng.
Dùng bản hosted hay tự host
VibeQA có bản hosted với gói miễn phí cho một dự án, và chi phí AI đã nằm trong mọi gói hosted. Nếu app của bạn không được rời khỏi mạng nội bộ, bạn có thể tự host bằng Docker Compose trên một server, với Anthropic key của chính bạn.
Những gì chưa làm được
- Chỉ web app. Android và iOS là bước tiếp theo, nhưng hiện chưa chạy được.
- Không có hộp thư. Luồng đăng nhập bằng magic link hay đăng nhập mạng xã hội vẫn phải test tay, hoặc bạn đưa cho test một phiên đăng nhập đã export sẵn.
- Đính kèm trên Jira. Defect tạo từ một lần chạy chỉ mô tả lỗi; ảnh chụp màn hình và trace vẫn nằm trong VibeQA chứ không được đính kèm vào ticket.
Đọc tiếp
- VibeQA có gì khác: so với bảng tính test case và Playwright viết tay.
- Từ đăng ký tới lần chạy đầu tiên: giờ đầu tiên với một dự án thật.
- Thiết kế test trước, viết code sau: test design và quy tắc coverage chi tiết.