Quy trình quản lý bug

MIỄN TRỪ TRÁCH NHIỆM: Mọi sự trùng hợp về quy trình trong bài viết này với bất kỳ công ty nào (bao gồm cả công ty hiện tại của mình) hoàn toàn là do... trùng hợp. Bài viết chỉ mang tính chất trao đổi học thuật và chia sẻ góc nhìn kỹ thuật/quản trị dự án. Ngoài ra, do tính chất đặc thù của ngành phần mềm, mình xin phép giữ nguyên các thuật ngữ tiếng Anh chuyên ngành (Defect type, UAT, Production, Bug, Workflow...) để đảm bảo tính trực quan và chính xác.

Gần đây mình có dịp được xem quy trình quản lý bug của một số team và thấy một cách định nghĩa “khá lạ” về Defect Type (Loại lỗi) như thế này:

• Bug Testing: Close tại bước Ready for testing

• Bug UAT: Close tại bước Ready for UAT

• Bug Production: Close tại bước Ready for Production

• Bug Review: Close tại bước Ready for review

Dưới góc nhìn cá nhân mình thì có vẻ như họ đang nhầm lẫn giữa “bản chất của bug” và “nơi phát hiện ra bug”.

Defect Type sinh ra để trả lời cho câu hỏi mang tính chất kỹ thuật: Lỗi này thuộc về khía cạnh nào của hệ thống?

Về cơ bản, nó sẽ bao gồm một số loại sau:

• Functional bug (Lỗi chức năng): Đây là loại lỗi phổ biến nhất. Phần mềm không hoạt động đúng như yêu cầu thiết kế (Requirement).

• Logical bug (Lỗi logic): Code vẫn chạy, không làm sập ứng dụng, nhưng kết quả cho ra lại sai vì thuật toán hoặc tư duy logic của lập trình viên bị lỗi.

• UI/UX bug (Lỗi giao diện/trải nghiệm người dùng): Lỗi liên quan đến những gì người dùng nhìn thấy và tương tác.

• Security bug (Lỗi bảo mật/lỗ hổng): Những lỗi nghiêm trọng mở đường cho tin tặc tấn công, đánh cắp dữ liệu hoặc phá hoại hệ thống.

• Performance bug (Lỗi hiệu năng): Phần mềm chạy đúng chức năng nhưng tốc độ xử lý quá chậm, ngốn quá nhiều tài nguyên (CPU, RAM).

• Integration bug (Lỗi tích hợp): Xảy ra khi các thành phần/module riêng lẻ chạy rất tốt, nhưng khi ghép nối lại với nhau hoặc kết nối với bên thứ ba (API) thì phát sinh lỗi.

Trong khi đó, những khái niệm như Testing, UAT, Production thực chất là Môi trường (Environment) hoặc Giai đoạn phát hiện (Detected phase).

Việc gán môi trường vào làm type của bug có thể gây ra nhiều hệ luỵ:

1. Không đo lường được chất lượng code và sản phẩm:

Thử tưởng tượng, cuối sprint hoặc cuối dự án, quản lý dự án mở báo cáo lên và thấy: “Dự án có 50 bug Testing, 20 bug Production”.

Số liệu này không giúp ích cho việc cải tiến kỹ thuật. Bạn không biết được team đang yếu phần nào (Yếu UI? Yếu Logic? Hay hệ thống đang hổng bảo mật?). Việc gom tất cả vào chữ “Bug Testing” đã xóa nhòa hoàn toàn bản chất cốt lõi để đội ngũ nhìn lại và tối ưu (Retrospective).

2. Quy trình đóng bug (close condition) nhiều rủi ro:

Định nghĩa “Bug Production: Close tại bước Ready for Production” hay “Bug UAT: Close tại bước Ready for UAT” rất dễ gây tranh cãi về mặt quy trình (Workflow). Khi một bug Production được sửa xong, QC test pass, trạng thái chuyển thành Ready for Production. Nếu lúc này bạn bấm Closed (Đóng ticket), hệ thống sẽ gặp các rủi ro sau:

• Chưa deploy đã đóng: Ready for Production nghĩa là code đã sẵn sàng để lên môi trường chạy thật, nhưng nó chưa thực sự nằm trên đó. Có một khoảng cách rất lớn từ lúc code “sẵn sàng” cho đến lúc “deploy thành công” (ví dụ: lỗi xung đột cấu hình server, lỗi merge code lúc release...).

• Thiếu quy trình Verify lại trên Production: Nếu ticket đã đóng từ bước Ready, đội ngũ sẽ dễ bỏ qua bước kiểm tra lại (sanity test) trên Production sau khi đợt release hoàn tất. Đến khi người dùng cuối tiếp tục báo lỗi, bạn sẽ phải mở lại (Reopen) một ticket đã Closed - đây là một “bad practice” trong quản lý dự án.

Nguyên tắc kinh điển: Bug sinh ra ở đâu, phải được verify và close ở chính môi trường đó sau khi đã deploy thành công. Chưa lên Production, chưa khách hàng nào test lại mà đã đóng ticket thì lỡ deploy lên vẫn lỗi, ai chịu trách nhiệm?

(Trong lúc đang phân tích rủi ro này mình lại nhận ra ngay bản thân cái bug status workflow cũng sai nghiêm trọng. Nhưng chắc có lẽ để khi khác mổ xẻ)

3. Xung đột trong cách gọi tên:

Hãy tưởng tượng một lỗi sai công thức tính mã giảm giá (Logical Bug):

• Nếu tester tìm thấy ở local thì gọi là “Bug testing”.

• Nếu tester sót, khách hàng tìm thấy thì gọi là “Bug UAT”.

• Nếu khách hàng cũng không thấy, lên live mới thấy thì gọi là “Bug Production”.

Về mặt kỹ thuật, nó vẫn là một dòng code lỗi do Dev viết sai thuật toán. Tại sao một lỗi code lại phải thay tên đổi họ liên tục dựa vào việc “ai là người bắt được nó”?

Thêm vào đó, việc định nghĩa “Bug Review” cũng là 1 dấu hỏi chấm lớn ở đây. “Ready for review” thường là trạng thái của một task/feature sau khi làm xong và chờ Techlead/BA lead/QC lead review, chứ bản thân nó không phải là một loại bug.

KẾT LUẬN

Quy trình sinh ra là để phục vụ con người và làm cho sản phẩm tốt hơn, chứ không phải để tạo ra sự phức tạp mang tính hình thức. Nếu vẫn cố áp dụng một cách cứng nhắc thì sẽ bị phản tác dụng: trói buộc con người & ép họ phải phục vụ lại các thủ tục máy móc.