Flaky tests in Automation: Nguyên nhân và giải pháp xử lý

7 giờ sáng, pipeline CI báo đỏ. Bạn mở log, chạy lại đúng bộ test đó — lần này xanh. Không một dòng code nào thay đổi. Lần thứ ba, lại đỏ ở một chỗ khác. Đó là khoảnh khắc một Automation Engineer bắt đầu hoài nghi chính code của mình, và tệ hơn, là khoảnh khắc cả đội bắt đầu mất niềm tin vào toàn bộ hệ thống kiểm thử tự động.

Nếu là Automation Engineer, gần như chắc chắn bạn đã gặp cảnh: script chạy thành công khi thực thi cục bộ trên máy phát triển, nhưng lại fail khi chạy run all; hoặc lúc được lúc không khi chạy trên Jenkins. Đó chính là flaky test — bài kiểm thử cho kết quả không ổn định. Vấn đề không nằm ở một lần fail, mà ở chỗ nó tạo ra cảnh báo sai và bào mòn niềm tin vào kết quả kiểm thử tự động. Khi đội ngũ quen với việc "cứ chạy lại là xanh", một lỗi thật cũng sẽ bị bỏ qua như một lần flaky bình thường — và đó là lúc CI mất hết giá trị.

Trong bài viết này, bạn sẽ nắm được:

• Định nghĩa chính xác flaky test và vì sao nó nguy hiểm hơn một lỗi fail thông thường.
• Sáu nhóm nguyên nhân phổ biến nhất khiến kiểm thử tự động trở nên không ổn định.
• Bảng đối chiếu nguyên nhân → giải pháp để xử lý dứt điểm từng loại.
• Kinh nghiệm thực chiến để cô lập và "xác minh" một test có thật sự flaky hay không.

Flaky test trong Automation là gì?

Hiểu đơn giản, flaky test là kiểm thử tự động không ổn định — cùng một đoạn code test, cùng một phiên bản ứng dụng, nhưng kết quả lúc PASS lúc FAIL. Cụ thể, một test bị coi là flaky khi có đủ các dấu hiệu sau:

• Xuất hiện fail không thường xuyên, mặc dù không có bất kỳ thay đổi nào trong code test.
• Chạy lại thì thành công mà không rõ vì sao lại như vậy.
• Gây ra cảnh báo sai và làm giảm niềm tin vào kết quả kiểm thử tự động.

Điểm mấu chốt: một test fail nhất quán là một test tốt — nó đang chỉ ra một vấn đề thật. Còn một test fail ngẫu nhiên mới là kẻ thù, vì nó che giấu lỗi thật giữa hàng loạt cảnh báo nhiễu.

Sáu nhóm nguyên nhân phổ biến

Flaky test hiếm khi đến từ một nguyên nhân duy nhất. Dưới đây là sáu nhóm thường gặp nhất, sắp theo mức độ phổ biến trong thực tế.

1. Xử lý đồng bộ (wait) sai cách

Đây là thủ phạm số một. Hai lỗi điển hình:

• Dùng Thread.sleep() thay vì cơ chế chờ thông minh như WebDriverWait (trong Selenium). Sleep cứng vừa làm test chậm, vừa không bao giờ "đủ" với mọi điều kiện mạng.
• Không chờ phần tử được load xong hoặc chưa sẵn sàng cho phép thực hiện action — script thao tác vào một element chưa tồn tại hoặc chưa interactable.

2. UI thay đổi hoặc UI động

• Các element biến mất rồi xuất hiện lại, hoặc load với độ trễ ngẫu nhiên.
• ID hoặc class trong DOM bị thay đổi giữa các lần render.

3. Locator cho element thiếu ổn định

• Cách xác định XPath hoặc CSS chưa nhất quán, chưa đảm bảo độ chính xác cao — locator khớp với nhiều element hoặc phụ thuộc vào cấu trúc DOM dễ thay đổi.

4. Sự phụ thuộc giữa các kịch bản

• Các bài kiểm thử phụ thuộc lẫn nhau, bài này dựa vào logic hoặc kết quả của bài kia.
• Phụ thuộc về dữ liệu: dữ liệu chưa được thiết lập lại (reset) giữa các bài, nên chạy một bài thì PASS, chạy cả bộ thì FAIL.

5. Môi trường thực thi không ổn định

• Ảnh hưởng từ hạ tầng chạy test: độ trễ mạng, máy ảo chậm, RAM thấp, dữ liệu kiểm thử không nhất quán.

6. Lỗi từ bên thứ ba (3rd party)

• API trả về lỗi 500 một cách ngẫu nhiên.
• Dịch vụ phụ thuộc ngừng hoạt động ngay trong quá trình thực thi kiểm thử.

Nguyên nhân → Giải pháp xử lý

Việc gọi tên đúng nhóm nguyên nhân quyết định cách chữa. Bảng dưới đối chiếu từng nguyên nhân với hướng xử lý thực tế:

Nhóm nguyên nhân	Biểu hiện thường gặp	Giải pháp xử lý
Xử lý đồng bộ (wait)	Dùng Thread.sleep(); thao tác trước khi element sẵn sàng	Thay bằng explicit wait (WebDriverWait + ExpectedConditions); chờ đúng trạng thái element trước khi action
UI động / UI thay đổi	Element load trễ ngẫu nhiên; ID/class đổi liên tục	Chờ điều kiện hiển thị cụ thể; phối hợp với dev để gắn thuộc tính ổn định (ví dụ data-testid)
Locator thiếu ổn định	XPath/CSS chưa nhất quán, khớp nhiều element	Ưu tiên locator duy nhất, ngắn, ít phụ thuộc cấu trúc DOM; tránh XPath tuyệt đối
Phụ thuộc kịch bản / dữ liệu	Chạy 1 bài PASS, chạy cả bộ FAIL	Mỗi test độc lập; reset/khởi tạo dữ liệu trong setup; không để test này phụ thuộc kết quả test kia
Môi trường thực thi	Mạng trễ, máy ảo chậm, RAM thấp	Chuẩn hóa môi trường CI; tăng tài nguyên runner; ổn định nguồn dữ liệu test
Lỗi bên thứ ba	API trả 500 ngẫu nhiên; service down	Mock/stub dịch vụ ngoài; thêm cơ chế retry có kiểm soát cho phụ thuộc bất ổn

Kinh nghiệm thực chiến. Trước khi sửa, hãy xác minh một test có thật sự flaky hay không: chạy lặp lại đúng test đó nhiều lần (ví dụ 20–50 lần) trên cùng một build mà không đổi gì. Nếu nó lúc PASS lúc FAIL, bạn đã có bằng chứng. Đừng vội lạm dụng auto-retry để "giấu" flaky — retry chỉ nên là tấm lưới an toàn tạm thời, còn việc cần làm là gọi tên nguyên nhân và xử lý gốc, nếu không bạn sẽ vô tình che mất cả những lỗi thật.

Kết luận

Flaky test không phải lỗi của riêng người viết script — nó là tín hiệu cho thấy một mắt xích trong cơ chế chờ, locator, dữ liệu hoặc môi trường đang thiếu ổn định. Mô hình tư duy cần nhớ rất gọn: một test phải cho cùng một kết quả khi đầu vào không đổi; mọi sự "lúc được lúc không" đều là một nguyên nhân đang ẩn nấp chờ được gọi tên. Khi bạn xử lý dứt điểm từng nhóm nguyên nhân thay vì chạy lại cho qua, CI mới thực sự trở lại làm điểm tựa đáng tin của cả đội.

Bạn thường gặp loại flaky test nào nhất, và đã xử lý ra sao? Hãy chia sẻ phương hướng và kinh nghiệm thực chiến của bạn để cộng đồng cùng học hỏi.