4 phút đọcRead in English
VibeQA trong ba phút
Ba video ngắn quay từ dashboard thật: Tokay đề xuất suite cho một dự án mới, team review từng case, và một run fail thành defect được re-verify.
Các bài khác trên blog này mỗi bài nói kỹ một phần của VibeQA. Bài này thì ngược lại: cả vòng lặp, gói trong ba video, mỗi video chừng một phút, quay từ dashboard thật. Trước mỗi video có một đoạn ngắn kể trong đó diễn ra chuyện gì và vì sao bước đó cần có.
1. Dự án mới: Tokay đề xuất, bạn quyết
Team tạo một dự án tên Kênh người bán, nhập địa chỉ app, upload một tài liệu yêu cầu và dán thêm một link. Tokay đọc tài liệu, rồi tự đi một vòng trong app: mở hết các menu trước để biết app có những trang nào, sau đó mới xem kỹ những trang quan trọng. Từ đó nó đề xuất suite: mỗi tính năng một suite, và mỗi luồng nghiệp vụ đi qua nhiều tính năng cũng một suite, ví dụ từ lúc đăng sản phẩm tới lúc bán được.
Lúc này chưa có gì được viết. Mỗi đề xuất ghi lại những gì Tokay thấy trên app, chẳng hạn nhập giá bằng 0 thì app báo "Nhập giá bán". Phải có người xác nhận hoặc bỏ từng quan sát đó thì mới duyệt được đề xuất, vì cái gì đã xác nhận sẽ thành kết quả mong đợi: lỡ xác nhận một bug thì test sẽ coi bug đó là đúng. Chỉ khi có người duyệt đề xuất, Tokay mới viết suite, và suite đó cũng chưa chạy cho tới khi có người duyệt tiếp.
Bước này có để những suite đầu tiên đi ra từ tài liệu và từ chính app của bạn, thay vì từ một trang trắng, còn quyết định test cái gì thì vẫn nằm trong tay người.
2. Review: từng case một
Mỗi suite bắt đầu bằng một test design. Mỗi case là một dòng trong design đó: dữ liệu test cụ thể cho
một scenario, viết theo dạng Given, When, Then. Người review đọc lần lượt, case nào ổn thì bấm "Đúng
rồi", case nào cần sửa thì hỏi ngay trong thread của case đó. Trong video, người review nhờ @Tokay phủ
thêm giới hạn 255 ký tự của địa chỉ giao hàng. Tokay không tự sửa design; nó trả lời trong thread bằng
một đề xuất, gồm một lớp mới 256 ký tự và một dòng mới, và người review chấp nhận.
Coverage được tính ra, không ai tự khai: mỗi lựa chọn của mọi input đều có mặt trong ít nhất một case, và giá trị biên nào cũng được test. Cả Tokay lẫn người review đều không tuyên bố được là design đã đủ; màn hình độ phủ chỉ báo đủ khi quy tắc đó thoả. Case nào bị sửa sau khi đã bấm "Đúng rồi" sẽ quay về chờ review. Phần còn lại của màn hình review có trong bài Review test design cùng Tokay.
Review design thay vì review code chính là mục đích. Product manager đọc được một dòng dữ liệu test; còn đọc một file Playwright thì không mấy người làm được.
3. Một run fail thành defect được theo dõi
Video cuối bắt đầu một lần chạy. Kết quả về từng test một, trong lúc các suite khác vẫn pass. Rồi suite Thanh toán fail, và run nói rõ lý do bằng lời thường: thanh tổng tiền dính ở cuối trang che mất nút Thanh toán ở kích thước cửa sổ này, nên cú bấm rơi vào thanh tổng tiền. Nếu lỗi nằm ở phía chúng tôi, như sandbox hay nhà cung cấp model, run được ghi là lỗi hạ tầng và hàng đợi tự chạy lại; nó không bao giờ hiện thành test fail.
Báo lỗi lấy phiên bản suite vừa fail làm repro: một test fail khi bug còn đó và pass khi bug đã được sửa. Trong video, defect chỉ lưu trong VibeQA, không có Jira, nên re-verify được bấm tay bằng nút Re-verify ngay. VibeQA chạy repro ba lần trong các sandbox mới, và kết luận đi ra từ một quy tắc cố định, không phải từ cảm nhận của ai: ba trên ba lần pass là Đã sửa.
Khi đã kết nối Jira thì không cần bấm gì cả. Ticket chuyển sang Ready for QA là re-verify tự chạy, và kết luận được comment ngược lên ticket. Cách thiết lập có trong Từ một run fail tới ticket Jira, rồi quay lại, còn ý nghĩa từng kết luận thì xem Vì sao một bản fix phải chạy ba lần.
Những gì video chưa quay
- Đăng ký và cài đặt dự án: test account, môi trường và lịch chạy có trong Từ đăng ký tới lần chạy đầu tiên.
- Sinh code: Tokay viết một test cho mỗi case tự động hoá và chạy thử một lần trước khi có người duyệt phiên bản. Video bỏ qua đoạn chờ đó.
- Chỉ web app: Android và iOS hiện chưa chạy được.