NEW
Font size
WorksheetsQUIZ #4: "BÍ KÍP DIỆT BUG – LOG SAO CHO CHUẨN?
Total questions: 14
Worksheet time: 7mins
Cách đặt tiêu đề (Bug Title) nào sau đây được xem là chuẩn tối thiểu nhất khi lỗi xảy ra trên môi trường Staging của khách hàng nhưng không tái hiện được trên môi trường DEV?
-HieuNT-
[STG] Account registration failed.
[STG] Login error on Customer's site.
[STG][Customer] Login fails with 500 error while DEV works normally with same account.
Login issue on staging environment - Cannot reproduce on Local.
Bạn phát hiện bug chỉ xảy ra trên môi trường STG của khách, nhưng môi trường DEV không có dữ liệu tương tự để tái hiện. Hành động nào thể hiện tư duy QA tốt nhất?
-HieuNT-
Đánh dấu bug là “Cannot reproduce” vì môi trường DEV không bị.
Không log bug cho đến khi DEV cấu hình được môi trường giống hệt khách hàng.
Log bug, mô tả rõ sự phụ thuộc về dữ liệu, đính kèm log/sample từ khách và đề xuất họp để tìm cách mock data.
Log bug và yêu cầu DEV tự lên môi trường của khách để tìm nguyên nhân.
Bối cảnh (Context): Bạn đang thực hiện kiểm thử chức năng "Đăng ký tài khoản". Theo tài liệu thiết kế (Spec), hệ thống phải chấp nhận các email hợp lệ. Tuy nhiên, khi bạn nhập email có một dấu cách thừa ở cuối (ví dụ: nguyenvana@gmail.com ), thay vì tự động xóa khoảng trắng (trim) hoặc thông báo "Email không đúng định dạng", hệ thống lại trả về một cửa sổ pop-up ghi lỗi hệ thống không xác định: "System Error (code: 500)".
-NgocDNTT-
[Registration] Không thể đăng ký tài khoản thành công khi người dùng nhập địa chỉ Email có chứa khoảng trắng.
[Registration] Hệ thống báo lỗi "System Error" tại trường Email khi người dùng nhập sai định dạng.
[Registration] Pop-up "System Error" hiển thị khi bấm Đăng ký với Email có chứa khoảng trắng ở cuối (trailing space).
[Registration] Cần tự động trim khoảng trắng ở trường Email để tránh lỗi "System Error" khi đăng ký.
App Ngân hàng lỗi: Chuyển khoản 2 tỷ đúng lúc 23:59:59 thì bị treo, tiền bị trừ nhưng người nhận không nhận được. Tần suất cực thấp (1 giây mỗi ngày). Dev muốn reject vì là edge case.
Câu hỏi: Luận điểm nào "sắc bén" nhất để QA thuyết phục PO phải fix ngay?
-NgocDNTT-
Đây là lỗi chức năng nghiêm trọng, nếu không fix QA sẽ không ký Sign-off cho bản Release.
Dù xác suất thấp nhưng lỗi gây mất tiền và sai lệch dữ liệu, rủi ro pháp lý và uy tín lớn hơn chi phí fix bug.
Người dùng sẽ có trải nghiệm cực tệ và hoang mang nếu tiền bị trừ mà không thấy lịch sử giao dịch.
QA đã tốn rất nhiều công sức để tái hiện lỗi này, nếu không fix sẽ gây lãng phí nguồn lực kiểm thử.
Feature hoạt động đúng theo Specification đã được PO phê duyệt, nhưng qua trải nghiệm thực tế, QA nhận thấy UI/UX rất khó dùng và chắc chắn người dùng sẽ phàn nàn. Bạn nên làm gì?
-HanVH-
Log Bug Functional vì trải nghiệm người dùng là quan trọng nhất.
Close task và không làm gì thêm vì QA phải làm việc dựa trên Spec.
Log một issue dạng Improvement/UX Suggestion kèm phân tích tác động người dùng.
Ép Dev phải sửa lại giao diện trước khi Release vì đây là lỗi nghiêm trọng.
Có 2 bug chưa fix trước giờ Release. Bug A: App bị crash đột ngột nhưng tần suất cực thấp (1/1000). Bug B: Sai lệch số liệu trong báo cáo tài chính của khách hàng. Team chỉ đủ thời gian fix 1 bug. Quyết định nào là đúng đắn?
-HanVH-
Ưu tiên Bug A vì theo tiêu chuẩn, "Crash" luôn có Severity cao nhất (Blocker).
Ưu tiên Bug B vì ảnh hưởng trực tiếp đến nghiệp vụ cốt lõi (Business Impact) và tính toàn vẹn dữ liệu.
Bug A note lại để xử lý sau.
Hoãn Release vì cả hai đều là lỗi không thể chấp nhận được.
Fix Bug A và đính kèm tài liệu hướng dẫn người dùng tự tính lại số liệu cho Bug B.
Hệ thống quy định: Người lao động không thể ứng tuyển (Apply) và thông báo nếu tổng giờ làm việc vượt quá giới hạn. Khi test, bạn thấy hệ thống làm đúng logic này: Nút "Apply" bị xám (disable). Tuy nhiên, giao diện không có bất kỳ dòng thông báo nào giải thích lý do, khiến người dùng nghĩ ứng dụng bị lỗi.
-LinhNTM-
Close ticket test – Not a bug
Log Bug Functional:
Log Bug UX
Log ticket Improve
Tại màn hình "Xác nhận thanh toán", logo công ty bị lệch 1px và sai mã màu nhẹ. Lỗi này hoàn toàn không ảnh hưởng đến chức năng thanh toán. Tuy nhiên, bộ phận Sale báo gấp: Màn hình này sẽ dùng để Demo ký kết hợp đồng triệu đô với khách hàng vào sáng mai.
-LinhNTM-
Severity: Major – Priority: High
Severity: Low – Priority: Urgent/Immediate
Severity: Critical – Priority: Urgent/Immediate
Severity: Low – Priority: Low
Bạn gặp một lỗi "chập chờn" (Intermittent bug), tần suất xuất hiện khoảng 1/10 lần thử. Dev không tái hiện được và yêu cầu Close bug. Cách xử lý chuyên nghiệp nhất?
-SinhVT-
Giữ Open và yêu cầu Dev phải tìm bằng được nguyên nhân mới được đóng.
Chấp nhận Close và theo dõi thêm, nếu sau này bị lại nhiều hơn thì log mới.
Cung cấp Video ghi hình, log file, cấu hình thiết bị chi tiết và đề xuất họp cùng Dev/PO để đánh giá rủi ro dựa trên tần suất.
Re-open để đảm bảo bug không bị quên lãng trong Backlog.
QA log lỗi hình ảnh bị vỡ trên Safari. Dev phản hồi: "Đây là giới hạn của trình duyệt, không fix được". Tuy nhiên, QA kiểm tra các trang đối thủ (Shopee, Lazada) vẫn hiển thị tốt trên Safari. Bạn nên làm gì?
-ViLTK-
Tin tưởng Dev vì họ có chuyên môn kỹ thuật sâu hơn.
Re-open bug, cung cấp ảnh chụp màn hình so sánh giữa web mình và web đối thủ trên cùng trình duyệt Safari để phản biện.
Đánh dấu bug là "Won't fix" và lưu vào tài liệu hướng dẫn người dùng không nên dùng Safari.
Chuyển bug cho PO để PO tự quyết định có fix hay không.
Sau khi Dev xác nhận đã fix bug A, QA tiến hành Retest. Case chính đã OK nhưng lại phát sinh một lỗi khác hoàn toàn mới ở chức năng liên quan (Side effect). Bạn nên xử lý như thế nào?
-ThaoTTT-
Re-open bug A và mô tả lỗi mới vào phần comment.
Close bug A vì lỗi ban đầu đã được fix, sau đó log một bug mới cho lỗi phát sinh.
Close bug A và không log bug mới để tránh làm tăng số lượng bug của Sprint.
Giữ bug A ở trạng thái "In Progress" cho đến khi cả lỗi cũ và lỗi mới đều được fix.
Thông tin nào sau đây được coi là quan trọng nhất của một Bug Report, giúp Dev tiết kiệm thời gian nhất trong việc tìm nguyên nhân?
-LinhNV-
Summary (Tiêu đề ngắn gọn).
Pre-condition
Steps to Reproduce
Evidence
Trạng thái nào KHÔNG thuộc vòng đời lỗi (Bug Life Cycle) cơ bản?
-LinhNV-
New
Assigned
Deployed
Reopened
Lợi ích chính của việc sử dụng công cụ Backlog (Jira, Backlog, Redmine...) là gì?
-LinhNV-
Tự động hóa quy trình báo cáo và thay thế các buổi họp trực tiếp (Daily Stand-up)
Cung cấp một nguồn sự thật duy nhất (Single Source of Truth) để theo dõi, ưu tiên và minh bạch hóa tiến độ công việc
Tự động đánh giá chất lượng code của Lập trình viên và số lượng Test Case của QA để tính hiệu suất (KPI)
Đảm bảo mọi lỗi (Bug) và tính năng (Feature) đều được giải quyết đúng hạn mà không cần sự can thiệp của Quản lý
