AI giúp gì khi viết bug report
AI viết bug report tốt nhất ở khâu "chuẩn hóa": bạn đưa mô tả lỗi thô, AI xếp lại thành report đủ trường — tiêu đề, môi trường, các bước tái hiện, kết quả mong đợi/thực tế, severity, priority. Nó giúp bạn viết nhanh hơn, câu chữ rõ ràng hơn, ít bỏ sót trường. Nhưng AI không thay tester: nó không tự chạy được ứng dụng, không biết nghiệp vụ đặc thù, nên mọi thông tin nó tạo ra đều cần bạn kiểm chứng.
Nói cách khác, AI lo phần diễn đạt và định dạng, còn bạn giữ phần sự thật kỹ thuật. Một bug report tốt vẫn phải bám các trường chuẩn mà bất kỳ tester nào cũng cần nắm — xem chi tiết ở vòng đời của bug. Đây cũng là tư duy song hành với việc dùng AI viết test case: AI là trợ lý viết nháp, tester là người biên tập có chuyên môn.
Quy trình dùng AI viết bug report
Một quy trình gọn, lặp lại được cho ai báo lỗi:
- Tái hiện & ghi lại sự thật. Tự bạn reproduce lỗi, ghi lại đúng các bước, môi trường (trình duyệt, OS, phiên bản build), kết quả thực tế và ảnh/log kèm theo. Đây là dữ liệu AI không tự có.
- Đưa mô tả thô cho AI. Dán các mẩu ghi chú của bạn vào một prompt có cấu trúc, kèm yêu cầu định dạng report theo template đội đang dùng.
- AI dựng bản nháp report. AI xuất tiêu đề, steps to reproduce đánh số, expected vs actual, đề xuất severity/priority kèm lý do.
- Kiểm chứng & sửa (human-in-the-loop). Soát lại: bước tái hiện đúng chưa, expected có đúng nghiệp vụ không, severity/priority AI đề xuất có hợp lý không — đây là bước human in the loop bắt buộc.
- Chốt & log lên tool. Dán report đã duyệt vào Jira/Redmine, đính kèm bằng chứng.
Các trường một bug report cần có (theo chuẩn ISTQB CTFL, mục "Defect report"):
| Trường | Ý nghĩa | AI hỗ trợ được? |
|---|---|---|
| ID / Title | Định danh + tóm tắt lỗi một dòng | Có — viết title rõ, súc tích |
| Environment | Trình duyệt, OS, phiên bản build | Chỉ khi bạn cung cấp |
| Steps to reproduce | Các bước tái hiện, đánh số | Có — chuẩn hóa, đánh số |
| Expected vs Actual | Kết quả mong đợi và thực tế | Diễn đạt lại; sự thật do bạn |
| Severity / Priority | Nghiêm trọng kỹ thuật / ưu tiên sửa | Gợi ý — tester chốt |
| Attachments / References | Ảnh, log, link yêu cầu liên quan | Không — bạn tự đính kèm |
Prompt mẫu: mô tả lỗi → bug report chuẩn
Prompt dưới đây dùng khung structured prompt 6 thành phần (vai trò, bối cảnh, chỉ thị, dữ liệu đầu vào, ràng buộc, định dạng đầu ra). Bạn thay phần trong ngoặc vuông bằng dữ liệu thật rồi chạy trên ChatGPT hoặc Claude. Đây là prompt bug report áp dụng được ngay:
# Vai trò
Bạn là Senior Tester giàu kinh nghiệm viết defect report chuẩn ISTQB.
# Bối cảnh
Hệ thống: Hệ thống đặt phòng họp nội bộ (web).
Màn hình gặp lỗi: [VÍ DỤ: màn hình đăng nhập]
# Chỉ thị
Từ mô tả lỗi thô của tôi, hãy dựng một bug report hoàn chỉnh, đủ trường,
để dev đọc là tái hiện được và không reject vì thiếu thông tin.
# Dữ liệu đầu vào
Mô tả lỗi thô:
"""
[DÁN GHI CHÚ CỦA BẠN: thao tác gì, thấy gì, môi trường nào]
"""
# Ràng buộc
- Steps to reproduce đánh số 1, 2, 3...; mỗi bước MỘT hành động.
- Expected và Actual phải CỤ THỂ, kiểm chứng được.
- Đề xuất Severity và Priority KÈM lý do; đánh dấu "CẦN XÁC MINH"
cho bất kỳ thông tin nào tôi chưa cung cấp — KHÔNG bịa.
- Viết tiếng Việt.
# Định dạng đầu ra
Các trường theo thứ tự: Title | Environment | Steps to reproduce |
Expected result | Actual result | Severity | Priority | Notes.
Mẹo: nếu title chưa đủ "đắt", nhờ AI viết lại 3 phương án title súc tích để bạn chọn. Về khác biệt severity và priority, đừng để AI gộp làm một — chúng là hai khái niệm riêng.
AI phân tích log & gợi ý nguyên nhân
AI phân tích log khá hữu ích: dán một đoạn stack trace hay console log, AI có thể chỉ ra dòng exception đáng ngờ, dịch thông báo lỗi khó hiểu và gợi ý vài hướng nguyên nhân. Với tester chưa mạnh về code, đây là cách nhanh để có "manh mối đầu tiên" trước khi trao đổi với dev.
Prompt gợi ý ngắn:
Đây là log lỗi khi tôi thao tác [MÔ TẢ THAO TÁC] trên [MÀN HÌNH].
Hãy: (1) tóm tắt log đang báo gì; (2) chỉ ra dòng đáng ngờ nhất;
(3) gợi ý 2-3 hướng nguyên nhân khả dĩ, xếp theo khả năng.
Nếu suy đoán, ghi rõ "GIẢ THUYẾT" — không khẳng định như sự thật.
[DÁN LOG]
Nhưng lưu ý: gợi ý nguyên nhân của AI chỉ là giả thuyết để bạn kiểm chứng, không phải kết luận. Đưa nguyên nhân AI đoán thẳng vào bug report mà chưa xác minh là cách nhanh nhất khiến dev mất niềm tin. Và tuyệt đối không dán log chứa dữ liệu thật của khách vào tool công cộng (xem phần rủi ro bên dưới).
Rủi ro & human-in-the-loop
Dùng AI cho tester tiện, nhưng ba rủi ro dưới đây phải kiểm soát:
- Hallucination (bịa). AI có thể "sáng tác" bước tái hiện hoặc nguyên nhân nghe rất hợp lý nhưng sai. Mọi thông tin AI tạo ra đều phải tester xác minh.
- Rò rỉ dữ liệu / PII. Đừng dán dữ liệu production, thông tin cá nhân khách hàng, token, mật khẩu vào tool AI công cộng. Hãy che (mask) hoặc thay bằng dữ liệu giả trước khi gửi.
- Ỷ lại. Nếu để AI viết hết mà không đọc lại, kỹ năng phân tích lỗi của chính bạn sẽ mai một.
Nguyên tắc xuyên suốt là human-in-the-loop: AI dựng nháp, con người kiểm chứng và chịu trách nhiệm cuối. Sau khi AI dựng xong report, tester cần đối chiếu với lỗi thật, sửa steps và expected cho đúng nghiệp vụ, chốt lại severity/priority, và bỏ mọi thông tin còn "CẦN XÁC MINH". AI hỗ trợ chứ không thay tester — đó cũng là lý do nghề này không bị AI thay thế, mà được nâng cấp.
Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!