Tôi đã tham gia vào một số dự án với tư cách là người thử nghiệm hoặc nhà phát triển. Trong nhiều dự án đã có các trạng thái sau cho các khiếm khuyết:
Bạn có sử dụng các trạng thái như vậy và làm thế nào để bạn khác nhau? Tôi hỏi, bởi vì hầu hết mọi người không thể giải thích sự khác biệt. Hiểu biết của tôi là:
KHÔNG CỐ ĐỊNH - nhà phát triển sẽ không sửa lỗi, do đó không phải là lỗi;
Đã hủy - không nên sửa lỗi, vì mức độ ưu tiên thấp nhất
Câu trả lời:
Như những người khác đã lưu ý, những tên trạng thái này không rõ ràng. Tôi muốn tên trạng thái chính xác và chi tiết hơn:
Tôi nghĩ rằng bạn đã có câu trả lời ngược
Không sửa chữa - sẽ áp dụng cho một lỗi nhỏ không ảnh hưởng hoặc có thể ở phiên bản cũ hơn do đó không đáng để bạn dành thời gian để sửa lỗi nhưng họ thừa nhận đó là lỗi.
Đã hủy - Đây có thể là một báo cáo lỗi xấu vì nó không thể tái tạo hoặc có thể nó không phải là một lỗi.
Lấy 2 mô tả của bạn:
KHÔNG CỐ ĐỊNH - nhà phát triển sẽ không sửa lỗi, do đó không phải là lỗi;
Đã hủy - không nên sửa lỗi, vì mức độ ưu tiên thấp nhất
Rõ ràng là sự khác biệt dự định là:
KHÔNG CỐ ĐỊNH - Nó không bị hỏng, chúng tôi cố tình dành cho hành vi này (Ví dụ: tính năng không phải là lỗi);
Đã hủy - Chúng tôi đồng ý rằng nó bị hỏng, nhưng nó quá tầm thường / không quan trọng, chúng tôi sẽ không bao giờ bị làm phiền để sửa nó.
Tại công ty của tôi, chúng tôi không sử dụng các trạng thái như vậy và tôi nghĩ rằng chúng không phải là một lựa chọn tốt về ghi nhãn cho các trạng thái bạn mô tả.
Nhà nước của chúng tôi bao gồm
Mới
Trong Progress
Ready Để thử nghiệm
Closed
mở lại
Và các tiểu bang nên đơn giản. Bất cứ điều gì chi tiết hơn như thể đó là một lỗi hoặc nếu mức độ ưu tiên quá thấp nên được ghi chú.
Hủy bỏ dường như ngụ ý rằng một bản sửa lỗi đã được bắt đầu nhưng sau đó đã dừng lại, có lẽ vì nó hóa ra cần nhiều tài nguyên hơn so với suy nghĩ ban đầu và hơn là khiếm khuyết biện minh hoặc rằng người nhập vé khiếm khuyết đã thay đổi suy nghĩ về việc đó là một khiếm khuyết. Không sửa chữa có vẻ như có một thỏa thuận rằng lỗi tồn tại nhưng có một lý do cho việc không muốn sửa chữa tại thời điểm này (chi phí so với lợi ích, tác động tiềm năng đối với chức năng khác, v.v.).