Phân loại lỗi CI và nhận diện flaky test bằng AI cho QA

Playbook giúp QA dùng log GitHub Actions và kết quả retry của Playwright để gom lỗi, nhận diện flaky test, xếp thứ tự điều tra và giữ bằng chứng trước khi mở bug.

Một pipeline vừa đỏ: có test timeout, assertion thất bại, job lỗi dependency và vài dòng retry. Nếu chỉ đọc log từ trên xuống, QA dễ ưu tiên nhầm—đi sửa test UI trong khi job thực ra hỏng ở bước thiết lập.

Cách làm hiệu quả hơn là dùng AI như một trợ lý phân loại log: gom lỗi có dấu hiệu tương tự, trích bằng chứng và đề xuất thứ tự điều tra. AI không nên tự kết luận nguyên nhân chỉ từ vài dòng log.

Với Playwright, retry cung cấp một tín hiệu rõ ràng: test fail ở lần chạy đầu nhưng pass khi retry được phân loại là flaky. Đây là tín hiệu để điều tra, không phải lý do để bỏ qua lỗi.

Mục tiêu: biến log dài thành hàng đợi điều tra

GitHub Actions cho phép xem, tìm kiếm và tải log của từng job trong một workflow run. Khi run thất bại, step lỗi được tự động mở rộng. QA cũng có thể lấy permalink tới dòng log để chia sẻ với đội ngũ.

Thay vì hỏi AI chung chung “log này lỗi gì?”, hãy yêu cầu AI trả lời năm câu:

Job và step nào thất bại? Log cho thấy loại dấu hiệu nào? Ví dụ: assertion, timeout, setup môi trường hoặc dependency. Test nào liên quan? Chỉ nêu file, tên test hoặc thông báo có trong log. Có retry không, và retry cho kết quả gì? QA cần kiểm tra gì tiếp theo?

AI hữu ích nhất khi nhiều job cùng lỗi với dấu hiệu tương tự. QA có thể gom chúng thành một nhóm điều tra, nhưng vẫn cần giữ các dòng log tương ứng của từng job hoặc test làm bằng chứng.

Bước 1: Lấy đúng log có ngữ cảnh

Trên GitHub, vào Actions, chọn workflow, chọn workflow run, sau đó chọn job trong mục Jobs hoặc trên biểu đồ workflow. Các step thất bại sẽ được mở rộng tự động.

Dùng ô Search logs để tìm tên test, thông báo assertion, timeout hoặc chuỗi lỗi quen thuộc. Lưu ý: tìm kiếm chỉ áp dụng cho các step đang được mở rộng.

Khi cần xem nhiều job, có thể tải log archive từ trang log. Nếu workflow được chạy lại một phần, archive chỉ chứa các job đã được chạy lại. Để có đủ log của workflow, cần xem hoặc tải thêm log từ những lần chạy trước chứa các job còn lại.

Đừng đưa nguyên archive vào AI. Hãy tách log theo job và failed step, đồng thời giữ:

Tên workflow, job và step. Tên test, file và thông báo lỗi. Dòng thể hiện retry hoặc trạng thái pass/fail. Dòng liên quan đến setup runner hoặc dependency, nếu có. Permalink tới dòng log quan trọng trên GitHub.

Bước 2: Dùng AI để phân loại, không suy đoán

Dùng prompt sau với phần log đã được lọc và che thông tin nhạy cảm:

text Bạn là trợ lý triage cho QA automation.

Hãy phân tích log bên dưới và chỉ dùng bằng chứng có trong log.

Quy tắc: Không gọi một test là flaky nếu log không cho thấy test fail lần đầu rồi pass khi retry. Không kết luận lỗi sản phẩm nếu log chỉ cho thấy lỗi setup hoặc runner. Nếu thiếu log, ghi “chưa đủ dữ liệu”, không tự tạo nguyên nhân. Có thể gom lỗi cùng dấu hiệu, nhưng phải nêu riêng từng test hoặc job trong nhóm.

Prompt này biến AI thành công cụ tạo bản đồ điều tra. Nếu AI nêu một nguyên nhân không có trong log, hãy xem đó là giả thuyết cần kiểm tra thêm, không phải kết luận.

Bước 3: Xếp thứ tự xử lý bằng rubric nội bộ

Playwright phân loại kết quả test khi bật retries như sau:

passed: pass ở lần chạy đầu. flaky: fail ở lần chạy đầu nhưng pass khi retry. failed: fail ở lần chạy đầu và fail ở mọi lần retry.

Đội QA có thể tự đặt rubric để AI hỗ trợ xếp hàng xử lý. Đây là cách làm nội bộ, không phải điểm số do Playwright hoặc GitHub Actions cung cấp.

text Dựa trên bảng triage, chấm điểm ưu tiên từ 1 đến 9 cho từng test hoặc nhóm lỗi.

Cộng điểm khi: Test vẫn failed sau mọi retry. Cùng dấu hiệu lỗi xuất hiện ở nhiều job hoặc nhiều lần chạy được cung cấp. Lỗi chặn luồng kiểm thử quan trọng theo nhãn do tôi cung cấp. Log cho thấy lỗi setup khiến nhiều test không thể chạy.

Trừ điểm khi: Chỉ có một lần fail rồi pass khi retry. Bằng chứng thiếu hoặc chỉ là suy đoán.

Với mỗi điểm số, nêu: Bằng chứng trong log Việc cần kiểm tra tiếp theo Nên tái hiện trước hay đã đủ thông tin để mở bug Không dùng dữ liệu ngoài đầu vào.

Một test failed sau mọi retry thường đáng được ưu tiên tái hiện vì đã thất bại lặp lại trong cấu hình retry hiện tại. Ngược lại, nếu job lỗi ở bước cài đặt trước khi test chạy, không nên tạo bug riêng cho các test chưa có bằng chứng đã được thực thi.

Ví dụ: từ CI đỏ đến danh sách điều tra

Giả sử một tính năng có yêu cầu: người dùng bấm nút gửi và hệ thống hiển thị thông báo thành công.

Test Playwright có thể click nút gửi rồi assertion thông báo. Khi CI đỏ, QA lấy phần failed step, đưa vào prompt triage và nhận lại một bảng như sau:

| Nhóm | Dấu hiệu trong log | Việc QA cần làm | |---|---|---| | Assertion | Giá trị thực tế khác giá trị mong đợi | Đối chiếu spec, test data và giao diện hiện tại | | Timeout | Hết thời gian chờ ở thao tác hoặc assertion | Kiểm tra điều kiện chờ, trạng thái trang và khả năng tái hiện | | Flaky cần điều tra | Fail lần đầu, pass khi retry | Chạy lại và thu thêm bằng chứng theo quy trình của đội | | Setup hoặc dependency | Job lỗi trước khi test chạy | Điều tra CI hoặc dependency trước khi tạo bug UI |

Điểm cần xác minh là expected result có còn đúng với spec hay không. Một assertion thất bại chưa đủ để khẳng định sản phẩm lỗi: test script cũng có thể đang dùng giá trị mong đợi không còn phù hợp.

Tương tự, một timeout không tự xác định được nguyên nhân. QA cần thêm bằng chứng từ log, trạng thái hệ thống và lần tái hiện.

Retry của Playwright: tín hiệu tốt, không phải cách che lỗi

Playwright Test chạy test trong các worker process độc lập. Mỗi worker có môi trường giống nhau và tự khởi động browser.

Khi một test thất bại, Playwright loại bỏ worker cùng browser đó và tiếp tục bằng worker mới. Nếu bật retries, worker mới sẽ retry test thất bại trước khi tiếp tục chạy các test sau.

Có thể cấu hình retry trong playwright.config.ts hoặc chạy:

bash npx playwright test --retries <sốlầnretry>

Trong test, hook hoặc fixture, testInfo.retry cho biết lần chạy hiện tại có phải là retry hay không. Tài liệu Playwright minh họa việc dùng thông tin này để dọn một phần trạng thái phía server trước khi retry.

Với nhóm test chạy serial, nếu một test fail thì các test sau bị skip. Khi bật retry, cả nhóm serial được chạy lại. Playwright khuyến nghị ưu tiên các test độc lập để chúng có thể chạy và retry riêng, hiệu quả hơn.

Checklist trước khi mở ticket

[ ] Xác định failed step, không chỉ nhìn trạng thái đỏ của workflow. [ ] Lưu permalink tới các dòng log quan trọng. [ ] Tách lỗi test khỏi lỗi setup và dependency. [ ] Kiểm tra trạng thái retry của Playwright. [ ] Dùng AI để gom bằng chứng và đề xuất thứ tự điều tra. [ ] Đối chiếu expected result với spec. [ ] Kiểm tra test data, điều kiện chạy và khả năng tái hiện. [ ] Đính kèm log liên quan cùng kết quả retry khi báo lỗi.

AI giúp QA đọc log nhanh hơn. Nhưng log, spec và kết quả tái hiện mới là cơ sở để kết luận đúng.