Defect
Chỗ sai nằm trong code, cấu hình hoặc tài liệu khiến hệ thống không đáp ứng đúng yêu cầu đã chốt. Đây là từ chuẩn dùng trong báo cáo và biên bản nghiệm thu, thay cho chữ bug nói miệng.
Định nghĩa
Làm với khách Nhật hoặc khách châu Âu, bạn sẽ thấy mọi tài liệu đều viết defect chứ không viết bug. Lý do là defect có định nghĩa gắn với yêu cầu: có yêu cầu thì mới có cái để lệch. Và những cuộc cãi nhau về tiền nghiệm thu thường xoay quanh đúng chữ này.
Defect là chỗ lệch giữa hệ thống thực tế và yêu cầu đã chốt, nên muốn khẳng định có defect thì phải chỉ ra được yêu cầu nào.
Defect, change request và enhancement
Đây là bảng đáng dán lên tường trong giai đoạn UAT, vì nó quyết định ai trả tiền cho công sửa.
| Defect | Change Request | Enhancement | |
|---|---|---|---|
| Bản chất | Làm sai so với spec đã chốt | Yêu cầu mới hoặc đổi spec | Muốn tốt hơn, spec không nói gì |
| Ai chịu chi phí | Đội phát triển | Thường là khách hàng | Tùy thương lượng |
| Cần phê duyệt | Không cần khách duyệt về phạm vi, nhưng vẫn phải qua triage để chốt severity/priority và xếp lịch; sau go-live thì bản vá còn cần người có thẩm quyền duyệt mới được đẩy lên | Có, qua quy trình CR | Có, đưa vào backlog |
| Ví dụ | Tính VAT 8% trong khi spec ghi 10% | Thêm xuất hóa đơn định dạng XML | Nút Lưu nên đổi màu cho dễ thấy |
Chỗ mờ nhất là khi tài liệu im lặng. Bên nghiệp vụ coi đó là chuyện đương nhiên không cần viết, bên dev coi cái gì không viết thì không làm. Cả hai đều có lý, và đó là lý do BA phải là người phán. Cách phán nhanh nhất là mở tài liệu ra đọc to lên. Nếu tài liệu thật sự không nhắc tới, đừng cố cãi thắng — ghi nhận là thiếu sót phân tích, đánh giá tác động, rồi quyết định fix luôn hay mở CR.
Một defect report gồm trường nào
Ngoài phần mô tả, các trường sau quyết định defect có được xử lý đúng thứ tự hay không: severity, priority, module, môi trường phát hiện, build, người phát hiện, người được gán, trạng thái, và loại defect.
Trường loại defect hay bị bỏ trống, tiếc, vì nó là thứ giúp bạn phân tích cuối dự án: lỗi do phân tích thiếu, do code, do dữ liệu, do cấu hình hay do môi trường. Cuối dự án mở báo cáo lên, nếu 40% defect thuộc nhóm phân tích thiếu thì vấn đề không nằm ở đội dev.
Ví dụ thực tế
Dự án hệ thống quản lý suất ăn ca cho một khu chế xuất — ba nhà thầu bếp, mỗi bên một cách tính suất. Giai đoạn UAT ghi nhận 63 defect: 28 cái do code, 19 cái do phân tích thiếu quy tắc, 11 cái do dữ liệu master sai từ hệ thống cũ, 5 cái do cấu hình môi trường.
Nhóm 19 cái kia xoay quanh đúng một chuyện: công nhân đổi ca giữa tháng thì suất ăn hôm đó tính về nhà thầu nào. Tài liệu chỉ mô tả ca cố định. BA thừa nhận thiếu, ngồi với phòng hành chính và cả ba nhà thầu đúng hai buổi, viết ra 7 quy tắc bổ sung. Hai buổi đó mà ngồi ngay từ đầu thì dự án khỏi mất ba tuần vòng lặp fix rồi retest.
Vài chỉ số quanh defect
- Defect density: số defect trên một đơn vị quy mô như module hay story point. Dùng để so xem chỗ nào đáng lo.
- Defect leakage: số defect lọt xuống giai đoạn sau. Lọt từ SIT xuống UAT còn đỡ, lọt xuống PROD là chuyện phải giải trình.
- Defect removal efficiency: tỉ lệ lỗi bắt được trước khi phát hành trên tổng số lỗi.
Đừng biến mấy con số này thành KPI cá nhân. Đo defect density để tìm module rủi ro thì tốt; đo để chấm điểm dev thì lập tức có người ngại log defect.
Mẹo khi đi làm
Khi khách gửi một danh sách "lỗi" bằng email dài, đừng trả lời từng dòng ngay. Tách thành ba cột theo bảng trên, gửi lại bản phân loại và xin xác nhận. Làm vậy bạn khỏi phải âm thầm sửa không công. Và khách nhìn bản phân loại cũng biết bên mình không trả lời theo cảm tính. Phần nào đúng là defect thì nhận và hẹn ngày fix, dứt khoát, đừng lấp lửng.
