Trang chủ
QA Learning Hub
Chương 05 · Defect Management
Chương 05 Cơ Bản

Defect Management

Viết bug report chuẩn quốc tế, quản lý vòng đời defect và giao tiếp hiệu quả với developer.

🐞 Bug Report Anatomy Required
  • TitleFormat: [Module] Action/State — Impact. Ngắn gọn, cụ thể, không mơ hồ. Dev phải hiểu ngay bug là gì chỉ từ title.
  • EnvironmentBrowser + version, OS + version, test environment URL, app version/build number, test account used. Dev phải reproduce được ngay.
  • Steps to ReproduceNumbered steps, cực kỳ cụ thể. Không có "go to the page" — phải là "Navigate to https://app.com/checkout". Mỗi step là một action duy nhất.
  • Expected ResultHệ thống nên làm gì theo spec/AC. Đây là "tiêu chuẩn" — reference tới requirement nếu có.
  • Actual ResultĐiều gì thực sự xảy ra. Cụ thể: "Error message 'undefined' displayed" không phải "lỗi hiện ra".
  • SeverityCritical / Major / Minor / Trivial — mức độ ảnh hưởng kỹ thuật (QA quyết định).
  • PriorityP1 / P2 / P3 / P4 — mức độ business urgency (PM/BA quyết định sau khi nghe QA).
  • AttachmentsScreenshot (annotated), screen recording (.mp4/.gif), browser console log, HAR file, log file từ server. Càng nhiều evidence càng tốt.
  • Test DataAccount credentials, specific data used (order ID, product SKU). Dev cần reproduce với cùng data.
  • ReproducibilityAlways / Sometimes / Rarely / Once. Nếu intermittent, ghi số lần reproduce / số lần thử.
⚖️ Good vs Bad Bug Report
Field❌ Bad✅ Good
Title Login is broken [Login] Authentication fails for users with "+" in email address — HTTP 500 returned
Steps 1. Go to login page
2. Login
3. Error appears		 1. Navigate to https://app.com/login
2. Enter email: user+test@gmail.com
3. Enter password: Test1234!
4. Click "Sign In" button
Expected Should work User is authenticated and redirected to /dashboard (per AC-001)
Actual Doesn't work, shows error HTTP 500 Internal Server Error returned. Console shows "Invalid email format" — API rejects "+" character
Evidence None Screenshot of error, HAR file showing 500 response, browser console log
🔄 Bug Life Cycle
  1. New — QA tìm và log bug vào JIRA. Status: New/Open.
  2. Assigned — PM/Tech Lead assign cho developer phù hợp.
  3. In Progress — Dev đang investigate và fix.
  4. Fixed / Resolved — Dev đã fix và deploy lên test environment. Dev update comment với fix details.
  5. Retest — QA verify lại bug. Chạy exact steps to reproduce + regression around the fix.
  6. Closed — Bug verified fixed. QA close với comment "Verified fixed on [env] build [version]."
  7. Reopen — Bug chưa fix đúng hoặc fix gây bug khác. QA reopen với detailed comment: "Fix not working because..."
  8. Deferred — PM quyết định không fix trong sprint này, move sang backlog. Phải có PM approval.
  9. Won't Fix — PM quyết định vĩnh viễn không fix: cost quá cao, low impact, by design. Document lý do.
  10. Duplicate — Bug đã được report rồi. Link đến original bug và close.
⚠️ Khi Reopen Bug
Luôn reopen với comment cụ thể: "Reopening because: [exact reason]. Tested on [env]/[build]. Steps: [exact steps]. Expected: X. Actual: Y. Screenshot attached." Không được reopen với comment "still broken" — dev cần biết chính xác điều gì vẫn sai.
📊 Severity vs Priority Matrix

Đây là câu hỏi phỏng vấn phổ biến nhất. Phải hiểu sự khác biệt rõ ràng.

Severity ↓ / Priority →High Priority (P1/P2)Low Priority (P3/P4)
High Severity 🔴 Fix ngay. Ví dụ: Payment processing crash — mất doanh thu mỗi phút 🟠 Fix khi có thể. Ví dụ: System crash khi upload file 10GB (edge case, ít user gặp)
Low Severity 🟡 Fix sớm. Ví dụ: Typo trên landing page, triệu người thấy mỗi ngày ⚪ Fix sau. Ví dụ: Alignment pixel nhỏ trong admin dashboard ít người dùng

Định nghĩa Severity:

  • CriticalHệ thống crash/unresponsive, data loss, security breach. Không có workaround. Ví dụ: Không thể checkout, data corruption.
  • MajorTính năng chính bị sai, ảnh hưởng lớn, có thể có workaround khó. Ví dụ: Filter không hoạt động, calculations sai.
  • MinorTính năng phụ bị ảnh hưởng, workaround dễ dàng. Ví dụ: Sorting không đúng thứ tự, UI misalign.
  • TrivialCosmetic only, không ảnh hưởng functionality. Ví dụ: Typo, màu sắc sai nhẹ, spacing.
💬 Giao Tiếp Với Developer
  • Dev nói "Not a bug / By design": Kiểm tra requirement/AC. Nếu spec không rõ → họp 3 amigos. Nếu spec rõ → giữ nguyên bug và escalate với evidence.
  • Dev nói "Cannot reproduce": Review steps, kiểm tra test environment, provide thêm evidence (video, HAR file, logs). Cùng dev pair-debug nếu cần.
  • Dev nói "Low priority, fix later": Ghi nhận, nhưng hỏi PM confirm. Nếu PM agree → deferred. Không để QA unilaterally decide priority.
  • Giữ thái độ chuyên nghiệp: Bug report là về hệ thống, không phải về người. Tránh blame language. "The system does X" không phải "You broke X".
  • Pair testing: Khi bug khó reproduce, ngồi cùng dev để reproduce live. Tiết kiệm thời gian hơn nhiều comment qua lại.
💡 Xây dựng quan hệ với Dev
QA không phải "kẻ thù" của Dev. Mục tiêu chung là sản phẩm tốt. Trao đổi informal (Slack, coffee chat) giúp giải quyết nhanh hơn nhiều so với formal bug report qua lại. Senior QA hiểu code đủ để nói chuyện tech với dev.
📈 Defect Metrics
  • Defect Leakage(Bugs in production / Total bugs found) × 100. Mục tiêu: <5%. Cao → testing process có vấn đề.
  • Defect DensityBugs per feature hoặc per KLOC. High density modules → cần thêm attention/testing.
  • Reopen Rate(Reopened bugs / Total closed) × 100. >10% → dev fix quality hoặc QA verify không kỹ.
  • Mean Time to ResolveAvg thời gian từ report đến close. Track per severity: Critical <4h, Major <2 ngày.
  • Defect AgeThời gian bug tồn tại chưa được fix. Old bugs = kỹ thuật nợ, risk tăng dần.
✏️ Bài Tập
📝 Bài Tập: Rewrite Bug Reports

Rewrite các bug report dưới đây thành dạng chuẩn, cụ thể và actionable:

  1. Bad report 1: "Cart doesn't work. I added items but they disappeared."
  2. Bad report 2: "Search is slow and sometimes shows wrong results."
  3. Bad report 3: "Admin page broken after login."

Với mỗi bad report: (a) Identify tất cả vấn đề, (b) Viết lại title theo format chuẩn, (c) Liệt kê những thông tin còn thiếu cần thu thập.

💼 Interview Q&A
What is the difference between Severity and Priority in defect management?
Severity measures the technical impact of a bug on the system — how badly it affects functionality. It's determined by QA/dev based on technical criteria (Critical/Major/Minor/Trivial). Priority measures how urgently the business needs it fixed — it's determined by the PM/Product Owner based on business impact, user visibility, and release schedule. A classic example: a typo on the homepage has Low Severity (cosmetic only) but High Priority (millions of users see it daily). Conversely, a system crash when uploading a 10GB file has High Severity but Low Priority (almost no users do this).
How do you handle a situation where a developer disagrees with your bug report?
First, I stay calm and objective — it's about the system, not personalities. I go back to the requirement/AC to verify my expected result is correct. If I have a spec reference, I share it. If the spec is unclear, I suggest we schedule a quick 3 Amigos with BA/PO to clarify. If the dev says "cannot reproduce," I provide additional evidence — video recording, HAR files, logs — and offer to pair-debug together. I never close a bug just because a dev disagrees; if there's genuine disagreement, it gets escalated to the team lead or PM.