Viết bug report tái hiện được từ trace, log và ảnh chụp bằng AI
Dùng Playwright Trace Viewer để kiểm tra action, ảnh chụp, log và network; sau đó dùng AI chuẩn hóa bằng chứng thành bug report rõ bước tái hiện, expected/actual và các điểm cần xác minh.
Một test trên CI chuyển đỏ, nhưng lỗi chỉ báo không tìm thấy phần tử. Screenshot cho thấy trang chưa về trạng thái mong đợi; dev lại cần biết lỗi xuất hiện sau thao tác nào, console ghi gì và request nào diễn ra lúc đó.
Nếu ticket chỉ viết “test fail trên CI”, vòng hỏi–đáp sẽ bắt đầu. Nếu ticket bám vào trace, log và ảnh chụp, người nhận có thể điều tra từ cùng một bộ bằng chứng.
Playwright Trace Viewer giúp xem lại trace sau khi test chạy, đặc biệt hữu ích khi test thất bại trên CI. AI có thể hỗ trợ biến các bằng chứng đã được QA kiểm tra thành bug report có cấu trúc. Nhưng AI không nên tự kết luận nguyên nhân gốc.
Bug report tốt bắt đầu từ bằng chứng
Một bug report dễ xử lý nên trả lời rõ:
Steps to reproduce: Đã thực hiện những gì, theo thứ tự nào?
Expected result: Hệ thống được kỳ vọng hoạt động thế nào theo spec hoặc test case?
Actual result: Điều gì thực sự quan sát được?
Evidence: Trace, ảnh chụp, log console, lỗi test và dữ liệu network liên quan.
Environment: Browser, viewport và metadata hiển thị trong trace.
Unknowns: Điều gì cần điều tra hoặc xác minh thêm?
Trong Trace Viewer, tab Actions hiển thị locator của từng action, thời gian chạy và các DOM snapshot. Tùy loại action, trace có thể gồm:
Before: Snapshot tại thời điểm action được gọi.
Action: Snapshot ở thời điểm input được thực hiện; hữu ích để xác định vị trí Playwright thao tác.
After: Snapshot sau action.
Tab Log cho biết Playwright đã thực hiện hoặc chờ những gì, chẳng hạn chờ phần tử hiển thị, enabled, stable rồi click, fill hoặc press. Tab Console hiển thị log từ browser và từ file test. Tab Network hiển thị request; có thể xem status code, headers, request body và response body.
Điểm quan trọng là mô tả điều quan sát được, chẳng hạn: action nào xảy ra, giao diện trước/sau action ra sao, log nào xuất hiện và request nào nằm trong cùng khoảng thời gian. Đừng biến điều đó thành kết luận như “backend hỏng” khi chưa có bằng chứng xác minh.
Thu trace ở local và CI
Khi điều tra ở local, bật trace lúc chạy test:
bash
npx playwright test --trace on
Mở HTML report:
bash
npx playwright show-report
Hoặc mở trực tiếp trace đã lưu:
bash
npx playwright show-trace path/to/trace.zip
Trên CI, tài liệu Playwright khuyến nghị ghi trace ở lần retry đầu tiên của test lỗi:
ts
import { defineConfig } from '@playwright/test'
export default defineConfig({
retries: 1,
use: {
trace: 'on-first-retry',
},
})
Với on-first-retry, Playwright tạo trace.zip cho từng test được retry lần đầu. Nếu không bật retry nhưng vẫn muốn giữ trace của test thất bại, có thể dùng:
ts
use: {
trace: 'retain-on-failure',
}
Tùy chọn on ghi trace cho mọi test, nhưng tài liệu lưu ý đây là lựa chọn nặng về hiệu năng.
Nếu không dùng Playwright Test Runner, có thể dùng API browserContext.tracing. Bắt đầu trace trước khi tạo hoặc điều hướng page, rồi xuất trace thành file ZIP khi kết thúc:
ts
await context.tracing.start({
screenshots: true,
snapshots: true,
})
// Thực hiện các thao tác test
await context.tracing.stop({
path: 'trace.zip',
})
Quy trình đọc trace để chuẩn bị ticket
Hãy đi theo một trình tự cố định để không bỏ sót bằng chứng:
Mở tab Errors để xác định thông báo lỗi và mốc lỗi trên timeline.
Chọn action ngay trước hoặc tại thời điểm lỗi; đối chiếu Before, Action và After.
Mở Log để xem Playwright đã chờ hoặc thao tác gì.
Double-click một action để lọc Console và Network theo khoảng thời gian của action đó.
Kiểm tra Metadata để lấy thông tin như browser và viewport mà trace hiển thị.
Gắn trace, ảnh chụp và các trích đoạn log/network liên quan vào ticket theo quy định của đội.
Trace cũng có thể được mở tại trace.playwright.dev bằng cách kéo-thả file hoặc chọn file. Theo tài liệu Playwright, phiên bản này được host tĩnh, tải trace hoàn toàn trong trình duyệt và không truyền dữ liệu ra bên ngoài.
Dù vậy, trước khi chia sẻ artifact CI, vẫn cần tuân thủ quy định nội bộ về dữ liệu nhạy cảm.
Dùng AI để chuẩn hóa, không để AI đoán
AI phù hợp để biến ghi chú rời rạc thành ticket nhất quán. Tuy nhiên, đừng chỉ đưa một trace ZIP rồi yêu cầu “tìm root cause”.
Trước hết, QA nên tự kiểm tra trace và trích các bằng chứng liên quan. Sau đó yêu cầu AI phân biệt rõ giữa quan sát, thông tin chưa có và giả thuyết cần xác minh.
Dùng prompt sau:
text
Bạn là trợ lý hỗ trợ QA viết bug report.
Chỉ sử dụng các bằng chứng tôi cung cấp. Không suy đoán nguyên nhân gốc,
không tự thêm bước tái hiện, status code, dữ liệu hay hành vi không có trong input.
Hãy trả về Markdown theo đúng cấu trúc:
Title
Preconditions
Steps to reproduce
Expected result
Actual result
Evidence
Environment
Questions / unknowns for investigation
Quy tắc:
Mỗi nhận định phải gắn với evidence tương ứng.
Nếu expected result không xuất hiện trong input, ghi “Chưa được cung cấp”.
Tách “Quan sát” và “Giả thuyết cần xác minh”.
Không đưa credentials, token hoặc dữ liệu nhạy cảm vào output.
Feature/spec:
<featurespec>
Trace actions đã xác minh:
<traceactions>
Console log đã lọc:
<consolelog>
Network evidence đã lọc:
<networkevidence>
Screenshot mô tả:
<screenshotdescription>
CI error:
<cierror>
Environment/Metadata:
<environment>
Prompt này giới hạn AI ở vai trò biên tập viên kỹ thuật: sắp xếp bằng chứng thành báo cáo, thay vì thay QA đưa ra kết luận.
Ví dụ: từ action lỗi thành ticket điều tra được
Giả sử spec quy định: sau khi người dùng gửi biểu mẫu, màn hình phải hiển thị trạng thái hoàn tất.
QA kiểm tra trace và ghi lại:
Action: click nút gửi biểu mẫu.
Before: biểu mẫu đang hiển thị.
After: biểu mẫu vẫn hiển thị.
CI error: test không tìm thấy trạng thái hoàn tất.
Console: có log lỗi trong khoảng action đã chọn.
Network: có request trong khoảng action; chưa xác minh nội dung response.
Screenshot: sau click không thấy trạng thái hoàn tất.
AI có thể tạo bản nháp như sau:
markdown
## Title
[Bug] Không hiển thị trạng thái hoàn tất sau khi gửi biểu mẫu
Preconditions
Steps to reproduce
Expected result
Actual result
Evidence
Questions / unknowns for investigation
Bản nháp không nên viết “API bị lỗi” hoặc “frontend không xử lý response”, vì các kết luận đó chưa xuất hiện trong bằng chứng đã cung cấp.
Review output AI trước khi tạo issue
Không nên copy-paste thẳng kết quả AI vào Jira hoặc GitHub Issues. Hãy review như review một test case:
Steps có bám trace không? Không thêm thao tác mà trace hoặc ghi chú đã xác minh không có.
Expected có nguồn không? Trace cho biết điều đã xảy ra, không tự xác định yêu cầu sản phẩm.
Actual có tách khỏi nguyên nhân không? “Không thấy trạng thái hoàn tất” là quan sát; nguyên nhân cần được điều tra.
Evidence có đúng phạm vi không? Dùng timeline hoặc double-click action để đối chiếu Console và Network với action liên quan.
Environment đã đủ chưa? Bổ sung browser, viewport và các metadata cần thiết mà trace hiển thị.
Dữ liệu nhạy cảm đã được xử lý chưa? Không đưa token, cookie, credentials, thông tin cá nhân hoặc nội dung nhạy cảm vào prompt và ticket.
Chuẩn hóa ticket bằng GitHub Issue Forms
GitHub Issue Forms cho phép tạo biểu mẫu YAML trong thư mục:
text
/.github/ISSUETEMPLATE
Form có thể dùng các kiểu trường như input, textarea, dropdown, checkboxes và upload. Đây là cách phù hợp để nhắc người tạo issue cung cấp các phần quan trọng như:
Current Behavior
Expected Behavior
Steps To Reproduce
Environment
Relevant log output
Screenshot hoặc tệp đính kèm khi cần
Tài liệu GitHub lưu ý Issue Forms đang ở trạng thái public preview và có thể thay đổi.
Checklist trước khi gửi
[ ] Expected result đã được đối chiếu với spec hoặc test case.
[ ] Steps to reproduce bám theo trace hoặc thao tác đã kiểm chứng.
[ ] Actual result chỉ mô tả điều quan sát được.
[ ] Trace, ảnh chụp và log liên quan đã được gắn làm bằng chứng.
[ ] Các giả thuyết được ghi rõ là cần xác minh.
[ ] Dữ liệu nhạy cảm đã được loại bỏ trước khi chia sẻ.
AI giúp giảm công việc chép và chuẩn hóa thông tin. Nhưng trace mới là bằng chứng, còn QA vẫn là người chịu trách nhiệm kiểm tra bằng chứng đó trước khi gửi ticket.