Mở đầu — vì sao bài này quan trọng
Khi còn làm QA/Tester, công cụ mạnh nhất trong tay bạn là cái nút "Create Bug". Bạn thấy hệ thống chạy không đúng spec, bạn gắn severity, viết step-to-reproduce, đính kèm screenshot, gán cho dev và theo dõi nó cho tới khi được fix và verify. Đó là một quy trình rất rõ ràng, rất "đúng/sai", và bạn đã làm nó hàng nghìn lần.
Nhưng khi chuyển sang vai trò BA, bạn sẽ phát hiện ra một sự thật khó chịu: rất nhiều thứ bạn từng coi là "bug" thực ra không phải bug. Đó là Change Request (CR) — yêu cầu thay đổi. Và đây chính là một trong những ranh giới phân biệt rõ nhất giữa người tư duy kiểu tester và người tư duy kiểu BA.
Sự khác biệt này không chỉ là chuyện gắn nhãn cho đúng. Nó liên quan trực tiếp đến tiền bạc, hợp đồng, thời gian sprint, và uy tín của bạn với khách hàng. Một QA gọi nhầm CR thành bug có thể khiến công ty mất hàng chục giờ công không được trả tiền. Một BA phân biệt được bug và CR sẽ bảo vệ được team, bảo vệ được ngân sách, và xây dựng được niềm tin với stakeholder. Bài học này dạy bạn cách "lật" tư duy đó — từ người báo lỗi sang người quản trị thay đổi.
Khái niệm cốt lõi
Bug trong tư duy QA
Trong thế giới QA, định nghĩa của bug rất gọn: bug là khi hệ thống chạy không khớp với spec đã được thống nhất. Nghĩa là phải tồn tại một "baseline" — một tài liệu, một acceptance criteria, một user story — mô tả hành vi mong đợi. Khi thực tế lệch khỏi baseline đó, đó là bug.
Quy trình xử lý bug bạn đã quen thuộc:
- Phân loại severity: Critical (sập hệ thống, mất dữ liệu) → High (chức năng chính hỏng) → Medium (ảnh hưởng một phần) → Low (lỗi nhỏ, cosmetic).
- Workflow: Open → Assigned → In Progress → Fixed → Verify → Closed (hoặc Reopen nếu fix chưa đạt).
- Trách nhiệm: Bug là lỗi của bên phát triển. Việc fix bug không phát sinh thêm chi phí cho khách hàng, vì nó nằm trong phạm vi đã cam kết.
Change Request trong tư duy BA
Change Request thì khác về bản chất. CR là khi yêu cầu thay đổi so với baseline — hệ thống đang chạy đúng với spec, nhưng spec không còn phù hợp với nhu cầu thực tế.
Nói cách khác:
- Bug = "Hệ thống chạy SAI so với cái ta đã thống nhất."
- CR = "Hệ thống chạy ĐÚNG, nhưng giờ ta muốn nó khác đi."
CR có vòng đời riêng, khác hẳn bug:
- Submitted (đề xuất thay đổi) → Impact Analysis (phân tích ảnh hưởng) → Estimation (ước lượng effort, chi phí) → Approval/Rejection (CCB — Change Control Board hoặc khách hàng duyệt) → Implementation → Verification → Closed.
- CR thường phát sinh chi phí và thời gian mà khách hàng phải đồng ý chi trả (đặc biệt trong mô hình outsource).
Ranh giới mờ — nơi QA hay nhầm
Vấn đề là ranh giới giữa bug và CR không phải lúc nào cũng sắc nét. Câu hỏi vàng để phân biệt luôn là:
> "Hành vi mong đợi này đã được định nghĩa ở đâu trong baseline chưa?"
- Nếu có spec rõ ràng và hệ thống lệch khỏi nó → Bug.
- Nếu không có spec, hoặc spec mô tả đúng hành vi hiện tại nhưng người dùng muốn khác → Change Request.
- Nếu spec mơ hồ, mâu thuẫn hoặc thiếu (gap) → đây là vùng xám, cần BA ra quyết định và thường được xử lý như một requirement clarification có thể dẫn tới CR.
Vì sao việc phân loại đúng lại quan trọng đến thế
Trong mô hình hợp đồng cố định (fixed-price) hoặc time & material, ranh giới bug/CR quyết định ai trả tiền. Bug là trách nhiệm của nhà cung cấp (miễn phí sửa). CR là việc mới, khách hàng phải duyệt và trả thêm. Gọi nhầm CR thành bug đồng nghĩa với việc đội phát triển làm không công; gọi nhầm bug thành CR sẽ khiến khách hàng nổi giận vì "bắt tôi trả tiền cho lỗi của các anh". BA đứng đúng ở giữa lằn ranh này.
Tình huống thực tế
Tình huống 1 — Công ty outsource ở TP.HCM và cái "bug" 80 triệu
Công ty FSoft-style (giả định tên là DigiSoft, một công ty outsource khoảng 300 người ở Quận 7) đang làm dự án quản lý kho cho một khách hàng Nhật. Spec ghi rõ: "Khi tồn kho của một SKU xuống dưới 10 đơn vị, hệ thống gửi email cảnh báo cho quản lý kho."
Sau khi go-live, khách hàng Nhật mở một loạt 15 "bug" với severity High: "Hệ thống không gửi cảnh báo SMS khi hàng sắp hết." Bạn Linh — một QA mới chuyển sang vai trò BA junior — ban đầu định gán hết cho dev fix, vì rõ ràng "tính năng cảnh báo không hoạt động đầy đủ".
Nhưng khi Linh truy lại baseline, cô phát hiện spec chỉ ghi email, hoàn toàn không có chữ "SMS" nào. Khách hàng giờ muốn thêm SMS vì đội kho hay ở dưới xưởng, không xem email. Đây không phải bug — đây là CR.
Linh viết một bản Impact Analysis: tích hợp SMS gateway (Twilio hoặc một nhà cung cấp SMS Việt Nam), thêm logic chọn kênh, test, ước lượng khoảng 40 giờ công ≈ 80 triệu đồng. Cô trình bày rõ ràng cho khách hàng rằng email vẫn chạy đúng spec, còn SMS là phạm vi mới.
Bài học: Nếu Linh xử lý đây như bug, DigiSoft mất 80 triệu doanh thu và 40 giờ công không được trả. Việc truy ngược baseline và phân loại đúng đã bảo vệ cả lợi nhuận lẫn mối quan hệ với khách hàng — vì khách hàng cũng hiểu đây là yêu cầu mới, không phải lỗi.
Tình huống 2 — Sàn thương mại điện tử và quy tắc voucher
Một startup e-commerce ở Hà Nội (giả định tên ChợViệt) chạy theo Scrum. Trong sprint review, Product Owner thử đặt đơn và phát hiện: "Khi tôi áp đồng thời voucher freeship và voucher giảm 50K, hệ thống chỉ trừ một cái. Đây là bug nghiêm trọng!"
Bạn Tuấn — BA từ nền QA — không vội tạo bug. Anh mở lại user story của sprint trước: AC ghi rõ "Mỗi đơn hàng chỉ được áp dụng một voucher tại một thời điểm." Hệ thống đang chạy đúng 100% so với AC. Vậy nên đây không phải bug.
Tuy nhiên Tuấn không dừng ở đó như một QA thuần túy ("không phải bug, đóng ticket"). Với tư duy BA, anh nhận ra nhu cầu kinh doanh đằng sau là hợp lý: cho phép stack voucher để kích cầu. Anh chuyển nó thành một CR, đưa vào product backlog, và phối hợp với PO để viết business rule mới về stacking voucher (thứ tự áp dụng, trần giảm giá tối đa, voucher loại trừ lẫn nhau). CR này được ước lượng và đưa vào sprint kế tiếp.
Bài học: QA mindset dừng ở "đúng/sai so với AC". BA mindset đi tiếp một bước: "AC này có còn phục vụ đúng mục tiêu kinh doanh không?" Tuấn vừa tránh đổ oan cho dev, vừa biến một "bug giả" thành cơ hội cải tiến sản phẩm có kiểm soát.
Tình huống 3 — Vùng xám: spec mơ hồ tại một ngân hàng
Một dự án core-banking tại một ngân hàng TMCP ở Việt Nam. Tester báo: "Khi khách chuyển khoản số tiền 0 đồng, hệ thống vẫn cho submit và tạo giao dịch rỗng. Bug!"
BA tên Hà kiểm tra spec. Spec viết: "Người dùng nhập số tiền chuyển khoản hợp lệ." Nhưng không định nghĩa "hợp lệ" là gì — không nói min/max, không nói có cho phép 0 hay không. Đây là vùng xám điển hình: spec thiếu (requirement gap), nên không thể khẳng định chắc chắn là bug.
Hà xử lý theo cách của một BA trưởng thành: cô không tranh cãi nhãn "bug hay CR" mà tập trung vào việc làm rõ requirement. Cô họp nhanh với nghiệp vụ ngân hàng, chốt rule mới: số tiền phải > 0 và ≤ hạn mức ngày của khách. Vì đây là phần spec thiếu sót ngay từ đầu (lỗi của giai đoạn elicitation, không phải khách đổi ý), nội bộ team thống nhất xử lý như defect của requirement và sửa miễn phí, đồng thời cập nhật lại tài liệu để tránh tái diễn.
Bài học: Không phải mọi thứ đều rơi gọn vào ô "bug" hoặc "CR". Khi gặp vùng xám, đừng sa đà tranh cãi nhãn dán — hãy quay về câu hỏi gốc: "Baseline nói gì?" Nếu baseline im lặng, nhiệm vụ của BA là làm cho nó lên tiếng.
Hướng dẫn từng bước
Khi nhận được một báo cáo "có gì đó sai", hãy chạy quy trình phân loại sau thay vì phản xạ tạo bug ngay:
Bước 1 — Tái hiện và xác nhận hiện tượng. Giống QA, bạn vẫn cần biết chính xác chuyện gì đang xảy ra: step to reproduce, dữ liệu đầu vào, kết quả thực tế. Đây là kỹ năng QA của bạn vẫn còn nguyên giá trị.
Bước 2 — Truy ngược baseline. Tìm trong user story, AC, PRD, business rule, hoặc spec đã ký: hành vi mong đợi được định nghĩa ở đâu? Ghi lại trích dẫn cụ thể (số story, số dòng AC).
Bước 3 — Áp câu hỏi vàng. "Hệ thống có chạy lệch khỏi baseline không?"
- Có → Bug. Đi tiếp theo workflow bug quen thuộc.
- Không (hệ thống chạy đúng baseline nhưng người dùng muốn khác) → CR.
- Baseline thiếu/mâu thuẫn → Requirement gap, cần làm rõ trước khi phân loại.
Bước 5 — Ước lượng và định giá. Phối hợp với tech lead để có con số giờ công và chi phí. Trong outsource, đây là cơ sở để báo giá CR cho khách.
Bước 6 — Đưa qua kênh phê duyệt đúng. Bug đi thẳng vào sprint; CR phải qua Change Control Board hoặc Product Owner / khách hàng duyệt. Không bao giờ tự ý làm CR mà chưa được duyệt.
Bước 7 — Cập nhật baseline sau khi CR được duyệt. Đây là bước QA hay quên: khi CR hoàn thành, AC và spec phải được cập nhật. Nếu không, lần sau chính nó lại bị báo nhầm thành bug.
Lỗi thường gặp & mẹo
Lỗi 1 — Phản xạ "Create Bug" trước khi truy baseline. Đây là quán tính mạnh nhất của người từ QA. Mẹo: tự đặt một quy tắc cá nhân — không gắn nhãn "bug" cho bất cứ điều gì nếu chưa trích dẫn được dòng spec/AC mà nó vi phạm.
Lỗi 2 — Dùng "severity" cho CR. Severity là ngôn ngữ của bug (mức độ hỏng hóc). CR dùng ngôn ngữ khác: business value, priority, effort, cost. Đừng hỏi "CR này critical hay high?" — hãy hỏi "CR này đáng làm không, tốn bao nhiêu, ưu tiên thứ mấy?"
Lỗi 3 — Sợ nói "đây là CR" vì sợ làm khách phật lòng. Nhiều BA mới nhân nhượng, nhận hết về làm miễn phí cho "đẹp lòng khách". Hậu quả: team kiệt sức, scope creep, dự án lỗ. Mẹo: trình bày CR một cách trung lập và dựa trên dữ kiện ("spec đã ký ghi X, yêu cầu mới là Y"), không mang tính đổ lỗi. Khách hàng chuyên nghiệp tôn trọng sự rõ ràng này.
Lỗi 4 — Quên cập nhật baseline sau CR. Dẫn tới "bug ma" ở các sprint sau. Mẹo: coi việc update AC/PRD là một phần bắt buộc của Definition of Done cho mọi CR.
Lỗi 5 — Tranh cãi nhãn dán ở vùng xám thay vì làm rõ requirement. Khi spec mơ hồ, đừng biến cuộc họp thành cuộc cãi "bug hay CR". Mẹo: chuyển hướng sang "hành vi đúng nên là gì?" và cập nhật spec — đó mới là giá trị BA.
Mẹo tận dụng nền QA: Chính vì bạn từng là QA, bạn có lợi thế khổng lồ khi viết Impact Analysis. Bạn hiểu hệ thống ở mức chi tiết, biết module nào dễ regression, biết test case nào sẽ bị ảnh hưởng. Hãy biến điểm mạnh này thành vũ khí: Impact Analysis của một BA-từng-QA thường chính xác và đáng tin hơn hẳn người không có nền kỹ thuật.
Bài tập thực hành
Bài 1 — Phân loại nhanh. Cho 6 tình huống sau, hãy gắn nhãn Bug / CR / Requirement Gap và nêu lý do (trích baseline giả định nếu cần):
- Spec ghi "đăng nhập sai 5 lần thì khóa tài khoản", hệ thống khóa sau 3 lần.
- Khách muốn thêm đăng nhập bằng vân tay, app hiện chỉ có mật khẩu (spec không nhắc vân tay).
- Spec ghi "hiển thị giá đã gồm VAT", màn hình hiển thị giá chưa gồm VAT.
- Người dùng muốn xuất báo cáo ra Excel; spec chỉ ghi "xuất báo cáo" không nói định dạng.
- Đối thủ vừa ra tính năng chat, sếp muốn thêm chat vào sản phẩm.
- Spec ghi "email xác nhận gửi trong 1 phút", thực tế gửi sau 5 phút.
Bài 3 — Reflection cá nhân. Nhìn lại 10 bug gần nhất bạn từng tạo khi còn làm QA (hoặc 10 bug bất kỳ trong hệ thống tracking hiện tại). Với mỗi bug, tự hỏi: "Nếu áp câu hỏi vàng, đây thực sự là bug hay là CR/gap?" Đếm xem bao nhiêu cái thực ra là CR. Con số này thường khiến học viên bất ngờ — và đó chính là khoảng cách giữa tư duy QA và BA.
Tóm tắt
- Bug = hệ thống chạy SAI so với baseline đã thống nhất. CR = hệ thống chạy ĐÚNG baseline, nhưng yêu cầu đã thay đổi.
- Câu hỏi vàng để phân biệt: "Hành vi mong đợi này đã được định nghĩa ở đâu trong baseline chưa, và hệ thống có lệch khỏi nó không?"
- Bug dùng ngôn ngữ severity và miễn phí sửa; CR dùng ngôn ngữ business value / cost / priority và phải được duyệt qua CCB hoặc PO trước khi làm.
- Phân loại đúng không phải chuyện hình thức — nó quyết định ai trả tiền, có scope creep hay không, và uy tín của bạn với khách hàng.
- Vùng xám (spec thiếu/mơ hồ) là chuyện thường gặp; đừng tranh cãi nhãn dán, hãy quay về làm rõ requirement và cập nhật baseline.
- Nền QA là lợi thế lớn khi viết Impact Analysis — bạn hiểu hệ thống đủ sâu để ước lượng ảnh hưởng chính xác. Hãy biến điểm mạnh cũ thành giá trị mới.