Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là QA của một startup fintech ở TP.HCM. Sáng thứ Hai, mở bug tracker lên, bạn thấy 47 bug mới được tạo trong ba ngày cuối tuần. Có bug làm sập màn hình thanh toán, có bug chỉ là chữ bị lệch 2 pixel, có bug lập trình viên bảo "cái này là feature chứ không phải bug". Đội dev thì chỉ có 4 người, sprint còn 6 ngày. Câu hỏi sống còn: fix cái nào trước, cái nào để sau, cái nào không fix?
Đó chính là lý do tồn tại của Bug Triage (phân loại và sàng lọc lỗi). "Triage" là thuật ngữ mượn từ y khoa — trong phòng cấp cứu, bác sĩ không chữa theo thứ tự bệnh nhân đến, mà chữa theo mức độ nguy kịch. Bug triage cũng vậy: đây là cuộc họp định kỳ để đội ngũ cùng nhau ra quyết định về từng lỗi — fix ngay, fix sau, hay không fix — dựa trên mức độ ảnh hưởng và nguồn lực hiện có.
Nếu không có triage, bạn sẽ rơi vào một trong hai cái bẫy. Bẫy thứ nhất: dev tự chọn bug dễ để fix trước (vì fix nhanh, cảm giác năng suất), còn bug khó nhưng nghiêm trọng thì né. Bẫy thứ hai: backlog bug phình to đến vô nghĩa — 300, 500 bug tồn đọng mà không ai biết cái nào còn giá trị. Triage biến một đống hỗn loạn thành một danh sách có thứ tự ưu tiên rõ ràng, có người chịu trách nhiệm, có deadline. Đây là kỹ năng phân biệt một QA biết "tìm bug" với một QA biết "quản lý bug" — và chính năng lực thứ hai mới đưa bạn lên vị trí Lead.
Khái niệm cốt lõi
Bug triage là gì và không phải là gì
Bug triage là một quy trình ra quyết định tập thể: nhìn vào từng bug và gán cho nó ba thứ — mức độ ưu tiên (priority), người xử lý (assignee), và thời điểm xử lý (sprint/release nào). Bug triage không phải là nơi để tranh cãi cách sửa lỗi kỹ thuật (đó là việc của dev sau khi nhận bug), cũng không phải là nơi để đổ lỗi ai gây ra bug. Triage tốt là triage nhanh, mỗi bug được xử lý trong 1–3 phút.
Ai tham gia và ai quyết định
Một buổi triage hiệu quả cần đúng người, không thừa không thiếu:
- QA Lead — người dẫn dắt buổi họp. Trình bày các bug mới, đọc bối cảnh, đề xuất mức priority ban đầu dựa trên severity và ảnh hưởng người dùng.
- Tech Lead / Dev Lead — đánh giá độ phức tạp kỹ thuật, ước lượng công sức fix, cảnh báo rủi ro (ví dụ: "bug này đụng vào module thanh toán, fix vội dễ gây regression").
- Product Owner / Product Manager — người có tiếng nói cuối cùng về priority. PO nhìn từ góc độ giá trị kinh doanh và trải nghiệm khách hàng. Khi QA và Dev bất đồng, PO là người "chốt".
- (Tùy chọn) Đại diện Support/CS — cực kỳ giá trị khi có bug đang gây khiếu nại từ khách hàng thật, vì họ mang tiếng nói từ chiến trường.
Ba quyết định đầu ra của mỗi bug
Sau khi bàn về một bug, nó phải rời buổi họp với một trong các trạng thái sau:
- Fix ngay (Immediate/Blocker) — bug chặn release hoặc gây thiệt hại nghiêm trọng. Kéo vào sprint hiện tại, gán người ngay.
- Fix sau (Backlog/Later) — bug thật nhưng chưa cấp bách. Đưa vào backlog với priority cụ thể (P2, P3) để sắp lịch ở sprint sau.
- Không fix (Won't Fix / Deferred) — có nhiều dạng: Won't Fix (chấp nhận sống chung), By Design (đúng thiết kế, không phải bug), Duplicate (trùng bug khác), Cannot Reproduce (không tái hiện được), Out of Scope (không thuộc phạm vi sản phẩm hiện tại).
Phân biệt triage với severity/priority
Bài này giả định bạn đã nắm severity (mức nghiêm trọng kỹ thuật) và priority (mức ưu tiên xử lý) từ bài trước. Điểm cần nhớ: severity do QA gán khi tạo bug, priority được chốt tại buổi triage. Một bug có thể severity cao nhưng priority thấp (ví dụ: crash ở tính năng mà 0.01% người dùng dùng), và ngược lại. Triage chính là nơi "hòa giải" hai con số này thành một quyết định hành động.
Nhịp độ triage
Tần suất phụ thuộc vào lượng bug và giai đoạn dự án:
- Hàng ngày (daily triage) — dùng khi gần release hoặc đang có khủng hoảng, họp nhanh 15–20 phút.
- 2–3 lần/tuần — nhịp phổ biến cho đội đang phát triển tích cực.
- Hàng tuần — cho sản phẩm đã ổn định, ít bug mới.
Tình huống thực tế
Ví dụ 1: Cuộc chiến "severity cao, priority thấp" tại một sàn TMĐT
Một sàn thương mại điện tử tầm trung ở Việt Nam (giả định tên ChoNhanh) chuẩn bị release phiên bản 3.2 sau 2 ngày nữa. Buổi triage chiều thứ Tư, QA đưa lên một bug: "Ứng dụng crash hoàn toàn khi người dùng đổi ngôn ngữ sang tiếng Nhật trong lúc đang xem giỏ hàng." Severity: Critical (crash toàn app).
QA đề xuất P1, fix ngay. Nhưng Tech Lead phản biện: fix đúng cần refactor cơ chế load ngôn ngữ, tối thiểu 2 ngày và rủi ro regression cao ngay trước release. PO hỏi một câu quyết định: "App của mình có bao nhiêu người dùng chọn tiếng Nhật?" Dữ liệu analytics trả lời: 11 người trong 90 ngày qua, trên tổng 400.000 người dùng.
Kết quả triage: hạ xuống P3, defer sang sprint sau, đồng thời làm một workaround nhanh 30 phút — tạm ẩn tùy chọn tiếng Nhật trong dropdown cho tới khi fix triệt để. Release đúng hạn.
Bài học: Severity là thuộc tính kỹ thuật của bug và không đổi; priority là quyết định kinh doanh và phụ thuộc bối cảnh. Đừng để "Critical" tự động thành "fix ngay". Buổi triage tốt luôn hỏi "ảnh hưởng bao nhiêu người thật?" và cân với chi phí + rủi ro fix. Workaround thường là cứu cánh giúp cân bằng cả hai.
Ví dụ 2: Đống backlog 380 bug và buổi "triage tổng vệ sinh"
Một công ty SaaS ở Singapore phục vụ khách hàng Đông Nam Á tích lũy 380 bug trong backlog sau 18 tháng. Không ai dám nhìn vào danh sách này nữa. QA Lead mới về đề xuất một buổi backlog grooming triage kéo dài 3 buổi chiều, mỗi buổi 2 tiếng, với quy tắc "bug nào cũ hơn 6 tháng và chưa từng ai nhắc lại thì mặc định đề xuất Close".
Kết quả sau 3 buổi: 214 bug bị đóng (Won't Fix hoặc Cannot Reproduce — nhiều bug đã tự biến mất qua các lần refactor), 90 bug được gán priority rõ ràng và đưa vào roadmap, 76 bug đánh dấu duplicate gộp lại còn 20. Backlog từ 380 xuống còn 110 bug "sống", tất cả có chủ.
Bài học: Backlog bug không được triage định kỳ sẽ mục ruỗng — chứa đầy bug đã lỗi thời, trùng lặp, không còn tái hiện. Một bug tồn 6 tháng không ai đụng tới là tín hiệu mạnh rằng nó không quan trọng. Đóng bug không phải là thất bại; giữ một backlog sạch quan trọng hơn giữ một backlog to. Hãy lên lịch "tổng vệ sinh backlog" định kỳ (ví dụ mỗi quý).
Ví dụ 3: Khi Support mang tiếng nói khách hàng vào phòng họp
Một ví bán điện tử (giả định PayViet) có buổi triage hằng tuần vốn chỉ gồm QA, Dev, PM. Một bug bị xếp P3 suốt hai tuần: "Số dư hiển thị chậm 3–5 giây sau khi nạp tiền, nhưng cuối cùng vẫn đúng." Về mặt kỹ thuật, tiền không mất — nên bị coi là minor.
Đến buổi triage thứ ba, lần đầu có đại diện CS tham gia. Bạn CS đưa con số: trong 2 tuần đó có 143 ticket khiếu nại "nạp tiền không thấy vào", 6 khách dọa report lên trang mạng xã hội, 2 khách yêu cầu khóa tài khoản. Dù tiền không thực sự mất, nỗi sợ mất tiền của người dùng là thảm họa cho một ví điện tử.
Bug lập tức được nâng lên P1 và fix trong sprint đó.
Bài học: Priority không chỉ đo bằng "hệ thống có sai không" mà còn bằng "người dùng cảm thấy thế nào và điều đó tốn bao nhiêu cho doanh nghiệp". Tiếng nói từ Support/CS là dữ liệu vàng mà QA và Dev ngồi trong văn phòng thường không có. Khi có thể, mời họ vào triage — hoặc ít nhất, kéo dữ liệu ticket vào cuộc họp.
Hướng dẫn từng bước
Bước 1 — Chuẩn bị trước buổi họp (QA Lead). Đừng bao giờ đi vào triage với một danh sách chưa lọc. Trước buổi họp, QA Lead sàng bug mới: gộp duplicate, đóng ngay các bug rõ ràng "not a bug", kiểm tra bug nào còn tái hiện được. Chuẩn bị sẵn một bộ lọc trong tool (Jira/Azure DevOps/YouTrack) hiển thị đúng "bug mới, chưa triage".
Bước 2 — Sắp xếp bug theo severity giảm dần. Vào buổi họp, xử lý Critical/High trước để nếu hết giờ thì ít nhất những bug quan trọng đã được quyết. Đừng để buổi họp chết chìm ở các bug cosmetic ngay từ đầu.
Bước 3 — Với mỗi bug, đọc nhanh 3 dữ kiện. QA Lead trình bày: (a) bug làm gì / ảnh hưởng ai, (b) severity đề xuất, (c) tần suất và phạm vi (bao nhiêu user, có workaround không). Giữ trong 60–90 giây.
Bước 4 — Cả nhóm cân nhắc và chốt priority. Dev cho ước lượng công sức và rủi ro. PO cân giá trị kinh doanh. Chốt một priority (P1/P2/P3/P4). Nếu tranh cãi quá 3 phút, PO ra quyết định tạm và đánh dấu "cần điều tra thêm" — không để một bug làm nghẽn cả buổi.
Bước 5 — Gán 3 thuộc tính bắt buộc. Mỗi bug rời cuộc họp phải có: priority (đã chốt), assignee (ai chịu trách nhiệm — dù chỉ là "điều tra"), target (sprint/release/backlog nào). Không có "để đó tính sau".
Bước 6 — Ghi lại quyết định "không fix" kèm lý do. Bug bị đóng phải ghi rõ vì sao (By Design / Won't Fix vì chi phí > lợi ích / Duplicate của #123). Điều này tránh việc bug đó bị mở lại và tranh cãi lần nữa sau ba tháng.
Bước 7 — Cập nhật tool ngay trong buổi họp. Đừng để "cập nhật Jira sau" — nó sẽ không bao giờ xảy ra chính xác. QA Lead hoặc thư ký cập nhật trạng thái ngay khi chốt từng bug.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến triage thành phiên debug. Cả nhóm sa đà bàn cách sửa một bug suốt 20 phút. Sai. Triage chỉ quyết có fix không và khi nào, không quyết fix thế nào. Mẹo: đặt một "parking lot" — thấy cuộc bàn kỹ thuật sâu thì ghi lại và hẹn bàn riêng với dev sau.
Lỗi 2 — Ai cũng đẩy priority của mình lên P1. Khi mọi bug đều "khẩn cấp" thì không bug nào khẩn cấp cả. Mẹo: giới hạn hạn ngạch — ví dụ tối đa 20% bug được phép là P1. Bắt buộc so sánh tương đối: "Bug này quan trọng hơn hay kém bug kia?"
Lỗi 3 — Không mời đúng người quyết. Triage mà thiếu PO thì priority không có thẩm quyền, thiếu Tech Lead thì ước lượng công sức chỉ là đoán mò. Mẹo: nếu người chốt vắng, hoãn hoặc chỉ triage phần không cần họ.
Lỗi 4 — Bug ra khỏi phòng mà không có assignee. Đây là lỗi giết chết mọi buổi triage. Không chủ = không ai làm. Mẹo: quy tắc cứng "no bug leaves unassigned".
Lỗi 5 — Không tôn trọng timebox. Buổi triage kéo 90 phút khiến mọi người mệt và ra quyết định ẩu ở nửa sau. Mẹo: giữ 30–45 phút, xử lý theo severity giảm dần, bug còn dư đẩy sang buổi sau.
Lỗi 6 — Không bao giờ dọn backlog. Mẹo: mỗi quý một buổi grooming để đóng bug lỗi thời (xem Ví dụ 2).
Mẹo vàng: Chuẩn bị sẵn "định nghĩa priority" viết ra giấy dán tường phòng họp (P1 = chặn release / mất tiền / mất dữ liệu; P2 = ảnh hưởng lớn có workaround; P3 = ảnh hưởng nhỏ; P4 = cosmetic). Khi cả nhóm dùng chung một thước đo, tranh cãi giảm hẳn.
Bài tập thực hành
Bài tập 1 — Chạy một buổi triage mô phỏng. Dưới đây là 5 bug mới của một app đặt đồ ăn. Với mỗi bug, hãy gán priority (P1–P4), quyết định (fix ngay / fix sau / không fix), và viết một câu lý do:
- App crash khi người dùng có tên chứa ký tự tiếng Việt "Nguyễn" trong địa chỉ giao hàng — xảy ra với ~35% đơn hàng.
- Nút "Đánh giá tài xế" bị lệch 3px trên iPhone SE (màn hình nhỏ).
- Khi mất mạng giữa chừng, người dùng bị trừ tiền nhưng đơn không được tạo — 4 ca báo cáo tuần này.
- Logo hiển thị mờ trên máy Android đời cũ chạy phiên bản hệ điều hành 3 năm trước.
- Ô tìm kiếm không tự xóa dấu tiếng Việt, gõ "pho" không ra "phở".
Bài tập 3 — Thiết kế agenda. Viết một agenda buổi triage 30 phút cho đội của bạn: mở đầu bao lâu, xử lý bug theo thứ tự nào, quy tắc timebox mỗi bug, và ai chốt priority. Ghi rõ 3 thuộc tính bắt buộc mỗi bug phải có khi kết thúc.
Gợi ý đáp án bài 1: Bug 1 và 3 là P1 fix ngay (ảnh hưởng rộng / liên quan tiền). Bug 5 là P2 (ảnh hưởng lớn nhưng có thể có workaround gõ không dấu). Bug 2 là P4. Bug 4 là P3 hoặc Won't Fix tùy tỉ lệ người dùng thiết bị đó.
Tóm tắt
Bug triage là cuộc họp định kỳ, có kỷ luật, nơi đội ngũ cùng quyết định số phận mỗi bug: fix ngay, fix sau, hay không fix. Nó biến một đống bug hỗn loạn thành một danh sách có ưu tiên, có chủ, có deadline.
Những điều cốt lõi cần nhớ:
- Đúng người: QA Lead dẫn dắt và cung cấp dữ liệu, Tech Lead ước lượng công sức và rủi ro, PO/PM chốt priority. Support mang tiếng nói khách hàng khi cần.
- Severity là kỹ thuật, priority là quyết định kinh doanh — triage là nơi hòa giải hai con số này bằng câu hỏi "ảnh hưởng bao nhiêu người thật và tốn bao nhiêu để fix?".
- Ba đầu ra bắt buộc mỗi bug: priority đã chốt, assignee, và target sprint/release. Không bug nào rời phòng mà chưa có đủ ba thứ.
- Giữ kỷ luật: timebox chặt, không debug trong triage, ghi rõ lý do khi đóng bug, và dọn backlog định kỳ.