4 phút đọcRead in English
Vì sao một bản fix phải chạy ba lần mới được coi là đã fix
Một lần chạy xanh có thể chỉ là may. VibeQA kiểm tra lại bản fix bằng ba lần chạy repro test rồi gộp thành một kết luận. Đây là ý nghĩa của từng kết luận.
Một dev chuyển ticket Jira sang Ready for QA. Giờ phải có người mở app, làm theo các bước trong ticket và quyết định lỗi đã hết chưa. Nếu lỗi chỉ thỉnh thoảng mới xuất hiện, người đó chạy thử một lần, thấy ổn, đóng ticket. Một tuần sau lỗi quay lại.
VibeQA kiểm tra lại bản fix thay bạn, và làm ba lần.
Chuyện gì xảy ra khi ticket đổi trạng thái
Khi một defect được theo dõi trong VibeQA, nó có một test tái hiện lỗi: một test đã được duyệt, sẽ fail khi lỗi còn đó. Khi ticket Jira chuyển sang trạng thái bạn chọn, VibeQA xếp hàng test đó ba lần trong cùng một nhóm re-verify. Mỗi lần chạy có một sandbox mới: trình duyệt mới, không còn cookie hay phiên đăng nhập nào của lần chạy trước.
Khi lần chạy cuối xong, ba kết quả được gộp thành một kết luận và VibeQA comment kết luận đó lên ticket.
- #48211m 38s
- #48221m 41s
- #48231m 36s
Vì sao kiểm tra lại bản fix một lần là không đủ
Nhiều lỗi tới tay QA là lỗi không ổn định: hai request tranh nhau, cache che mất lỗi ở lần tải thứ hai, dữ liệu test chỉ hỏng vào vài ngày. Giả sử lỗi vẫn còn và xuất hiện ở một nửa số lần chạy. Chạy một lần thì bỏ sót nó một nửa số lần. Chạy ba lần thì cả ba cùng bỏ sót chỉ một lần trong tám.
Ba không phải con số thần kỳ. Một lỗi chỉ xuất hiện ở 30% số lần chạy vẫn lọt qua cả ba lần khoảng một phần ba số lần. Nhưng nó biến "ăn may" từ khả năng cao nhất thành khả năng thấp, với cái giá là hai lần chạy thêm của một test bạn đã có sẵn.
Kết luận được quyết định thế nào
Kết luận là một hàm nhỏ, tất định, chỉ dựa trên kết quả các lần chạy. Không có model nào đọc log rồi đưa ra ý kiến; cùng ba kết quả thì luôn ra cùng một kết luận.
| Kết quả các lần chạy | Kết luận |
|---|---|
| Mọi lần chạy xong đều pass | Đã fix |
| Mọi lần chạy xong đều fail | Vẫn còn lỗi |
| Có lần pass, có lần fail | Flaky |
| Bản thân test bị hỏng, hoặc có lần chạy bị huỷ | Bị chặn |
| Chưa tới hai lần chạy ra được pass hoặc fail | Bị chặn |
Có hai chi tiết quan trọng.
Lỗi của chúng tôi không phải lỗi của bạn. Nếu một lần chạy chết vì sandbox hết bộ nhớ hay nhà cung cấp model bị timeout, đó là lỗi phía chúng tôi, không phải test fail. Hàng đợi sẽ chạy lại, và lần chạy đó không bao giờ được tính là pass hay fail. Nếu vẫn có hai lần chạy ra kết quả thật, kết luận dựa trên hai lần đó.
Flaky thì để người quyết định. Khi các lần chạy không khớp nhau, VibeQA không tự chọn phe. Nó báo kết quả là flaky và để bạn quyết định. Bản thân kết luận flaky cũng có ích: bản fix đã thay đổi được một phần, nhưng chưa phải tất cả.
- #51071m 52s
- #51080m 47s
- #51091m 49s
Mỗi lúc chỉ một nhóm
Mỗi defect chỉ có tối đa một nhóm re-verify đang chạy. Nếu Jira gửi cùng một cập nhật hai lần, hay có người kéo ticket qua lại trong lúc các lần chạy đang diễn ra, các yêu cầu thừa sẽ bị bỏ qua thay vì chồng thêm lần chạy. Và khi bạn đóng defect trong VibeQA, nó thôi re-verify defect đó.
Chạy ba lần tốn hơn chạy một lần. Chúng tôi nghĩ đó vẫn là lựa chọn rẻ hơn, khi tính cả những ticket phải mở lại.