Cách đóng một lỗi không còn phù hợp

Tôi hiện đang ở trong một nhóm các nhà phát triển web cỡ trung bình. Chúng tôi đang sử dụng jira để theo dõi lỗi.

Chúng tôi đang làm việc trên một sản phẩm với sự thay đổi bố cục thường xuyên. Rất nhiều lần lỗi được đệ trình về một lỗi trong bố cục trong một số trình duyệt. Đôi khi, vào thời điểm chúng ta phải xử lý một lỗi ưu tiên thấp, bố cục đã thay đổi và nó không còn phù hợp nữa.

• Chúng ta nên đóng nó như thế nào?
  Ý tôi là làm thế nào chúng ta nên đối xử với những vấn đề này? Mặc dù Jira là phần mềm theo dõi lỗi mà chúng tôi sử dụng, tôi quan tâm nhiều hơn đến cách xử lý các loại vấn đề này nói chung.
• Nó thậm chí còn quan trọng? (Chúng tôi có thể quay lại bố cục sau, nhưng điều đó rất khó xảy ra)

Các vấn đề như thế có vấn đề nếu bạn coi bộ theo dõi vấn đề như một phương tiện để truyền đạt trạng thái của các vấn đề được báo cáo trong dự án. Với mục đích đó, thật hợp lý khi đầu tư một số nỗ lực để đảm bảo rằng báo cáo lỗi dễ đọc và dễ hiểu.

Tình huống này sẽ bớt khó hiểu hơn nhiều nếu bạn nhìn nó từ góc độ của một người thử nghiệm. Nếu nhóm của bạn không có người kiểm tra, hãy tưởng tượng một (hoặc tốt hơn nữa, hãy thuê một người ^{1 , 2 , 3} ).

Được rồi, do đó, đã có một lần lỗi, người kiểm tra có thể sao chép nó bằng các bản phát hành cũ hơn của ứng dụng của bạn (lưu ý phụ trong trường hợp không chắc là bạn không giữ bản sao của bản phát hành cũ hơn, sau đó bạn gặp vấn đề khó khăn hơn nhiều đội hơn lỗi lỗi). Người kiểm tra có thể nhìn thấy nó và có thể nói những gì sai, điều gì làm cho nó trở thành một lỗi.

Bây giờ bạn nói, "bố cục đã thay đổi và nó không còn phù hợp nữa" - trán cao không còn phù hợp trong suy nghĩ của người thử nghiệm thành tuyên bố đơn giản hơn nhiều: vấn đề đã biến mất .

• Điều quan trọng cần lưu ý ở đây là người kiểm tra chuyên nghiệp nên thoải mái khi nghĩ hệ thống là một hộp đen . Từ quan điểm đó, vấn đề đã xảy ra chính xác đến mức nào, vấn đề đã xảy ra, đó có thể là thay đổi bố cục hoặc ma thuật đen hoặc thiết kế lại toàn bộ, hoặc thay đổi mã cụ thể, bất cứ điều gì.

Từ quan điểm hộp đen, tình huống của bạn là khá đơn giản. Có một vấn đề, nó vẫn có thể tái tạo trong bản phát hành cũ hơn, bây giờ bạn cho rằng bản phát hành mới hơn không còn vấn đề như vậy nữa. Đối với một người kiểm tra, điều này dẫn đến một tuyên bố rằng lỗi đã được sửa và tương ứng với nhu cầu xác minh xem khiếu nại đó có đúng không.

Người kiểm tra chuyên nghiệp sẽ lấy bản phát hành cũ hơn của bạn, xem xét vấn đề hiện diện ở đó như thế nào, sau đó lấy bản phát hành mới hơn và kiểm tra xem nó đã biến mất hay vẫn còn đó.

Từ trên, cách chính xác nhất để xử lý các lỗi như bạn mô tả, sẽ là đóng những lỗi này như đã giải quyết, sửa chữa . Tất nhiên sẽ không hại gì nếu bạn làm rõ trong các ý kiến ​​rằng việc khắc phục xảy ra như một tác dụng phụ ngoài ý muốn của việc thay đổi bố cục.

Một trong những JIRA tùy chỉnh mà tôi từng làm việc trong một dự án trước đây có độ phân giải "Fixed By Design" để truyền đạt những thay đổi khá sâu sắc có nhiều hậu quả, một số cố ý, một số thì không. Đối với trường hợp như bạn mô tả, điều đó cũng có thể được xem xét thay vì "Đã sửa" đơn giản, vì nó gợi ý người đọc vé rằng đó là một tác dụng phụ hơn là thay đổi mã có chủ ý.

Chúng tôi giải quyết các vấn đề như 'Lỗi thời'. Đây không phải là một tùy chọn độ phân giải mặc định trong JIRA nhưng nó đủ dễ để thêm.

JIRA (và tôi chắc chắn rằng các trình theo dõi lỗi khác) cho phép bạn chỉ định độ phân giải tùy chỉnh để bạn có thể thiết lập độ phân giải "Overtaken By Events" hoặc "Irrelavant" hoặc tương tự để cho phép bạn thể hiện việc đóng theo cách bạn muốn

Có vấn đề gì không? điều đó phụ thuộc, đối với chúng tôi, tôi sẽ nói đồng ý vì khách hàng của chúng tôi quá quan tâm đến số lượng sự cố mở trong trình theo dõi của chúng tôi, vì vậy đối với chúng tôi, có thể nói những điều này đã bị đóng vì chúng không còn phù hợp mà không xóa hoàn toàn vấn đề .

Ngay cả khi không có khách hàng quan tâm bởi các số phát hành, việc cắt xén các vấn đề mở cũ không còn phù hợp chắc chắn chỉ hữu ích để giảm sự lộn xộn trong trình duyệt.

Chúng tôi sử dụng FogBugz, nhưng tôi chắc chắn điều tương tự (hoặc tương tự) được áp dụng ở đây:

Chúng tôi chỉ sử dụng "Đã giải quyết (Đã sửa)" và nhận xét trong độ phân giải chỉnh sửa nội dung như "Đã sửa trong trường hợp 12345".

FogBugz khớp với "case \ d +" và liên kết cả hai với nhau trong Các trường hợp liên quan, nhưng nếu Jira không làm điều đó, thật đơn giản chỉ cần thêm một liên kết.

Đây là IMO tốt hơn so với biến thể "Quá cục bộ" vì đây là một lỗi thực tế và tốt hơn là chỉ là "Lỗi thời" vì nó đã được sửa, tính năng đó chưa bị xóa.