Tại sao không nên đăng một số lỗi trong cùng một vấn đề / vé?

Tôi không chắc đây có phải là nơi để đặt câu hỏi về khái niệm sau không (Stackoverflow chắc chắn là không).

Tôi đã thấy câu hỏi này trong một bài kiểm tra trắc nghiệm (câu trả lời đơn), tương tự như các bài kiểm tra ISTQB :

Tại sao không nên báo cáo một số lỗi trong cùng một vấn đề / vé?

a. Để giữ cho báo cáo ngắn gọn và rõ ràng.

b. Bởi vì các nhà phát triển có thể chỉ sửa một lỗi.

c. Bởi vì những người kiểm tra nhóm thử nghiệm được đánh giá theo số lượng lỗi họ tìm thấy.

d. Hệ thống quản lý lỗi không hỗ trợ tính năng này của nhiều lỗi.

Ý kiến ​​duy nhất của tôi là đó alà câu trả lời chính xác.

b- không thể là vì sửa chữa-phản hồi-giải quyết-đóng nên tránh trường hợp đó. c- Rõ ràng là sai.

d - Các plugin Redmine / Trac hỗ trợ nhiều trường.

Câu trả lời theo phiếu trả lời là b.

Ai đó có thể giải thích tại sao? Bình luận với ý kiến ​​về câu trả lời được chào đón.

Hãy tưởng tượng nếu Stack Overflow có một hướng dẫn: thay vì hỏi một câu hỏi, bạn đến và hỏi, trong cùng một câu hỏi, bất cứ điều gì xuất hiện trong đầu bạn, tất cả các vấn đề bạn gặp phải trong hai tuần qua. Upvote và downvote có nghĩa là gì? Điều gì sẽ là tiêu đề của các câu hỏi? Làm thế nào để chấp nhận câu trả lời tốt nhất? Làm thế nào để gắn thẻ câu hỏi?

Hệ thống theo dõi lỗi được thực hiện để ... theo dõi lỗi. Theo dõi lỗi có nghĩa là:

1. Tạo một bản ghi nói rằng một lỗi có thể tồn tại, với thông tin về cách tái tạo nó,

2. Xác nhận rằng thực sự, lỗi tồn tại và là một lỗi, không phải do thiết kế,

3. Khẳng định rằng lỗi hiện đã được giải quyết,

4. Xác nhận rằng lỗi đã được giải quyết.

Trong một mô hình rất đơn giản, 1 và 4 sẽ được thực hiện bởi khách hàng và 2 và 3 - bởi nhà phát triển.

Hãy tưởng tượng nhật ký sau:

• Ngày 1 [Khách hàng] Khi nhấn vào nút Xóa Loại bỏ trong Cửa hàng chi tiết Sản phẩm Cửa sổ, ứng dụng bị treo. Khởi động lại ứng dụng cho thấy sản phẩm không bị xóa. Hành vi dự kiến ​​là loại bỏ sản phẩm.

• Ngày 4 [Nhà phát triển] <Vấn đề được sao chép>

• Ngày 5 [Nhà phát triển] <Vấn đề được giải quyết trong phiên bản 5031>

• Ngày 12 [Khách hàng] <Vé đã đóng: vấn đề đã được giải quyết>

Nhật ký rất đơn giản và rõ ràng . Bạn có thể dễ dàng theo dõi những gì đã được thực hiện và khi nào , bản sửa đổi nào đã khắc phục lỗi nào, v.v. Ví dụ: nếu hệ thống theo dõi lỗi được tích hợp với kiểm soát phiên bản, khi bạn xem một bản sửa đổi cụ thể, bạn có thể kiểm tra xem lỗi nào đã được khắc phục trong đó.

Thật dễ dàng để tìm thấy thông tin . Thật dễ dàng để thấy trạng thái của nó (nó có được sao chép không? Nếu vé bị đóng, tại sao?). Thật dễ dàng để lọc vé (Tôi muốn hiển thị vé chỉ liên quan đến giao diện người dùng của các plugin, với điều kiện là tôi chỉ muốn vé mở, cũ hơn một tuần và được nhà thiết kế tương tác của chúng tôi gán cho tôi và có mức độ ưu tiên trung bình hoặc cao).

Thật dễ dàng để chỉ định lại một vé hoặc để xác định ban đầu ai là người chịu trách nhiệm về lỗi này.

Bây giờ hãy tưởng tượng nhật ký sau:

• Ngày 1 [Khách hàng] Ứng dụng bị treo khi tôi nhấn nút Xóa Loại bỏ trong Cửa hàng Chi tiết sản phẩm. Ngoài ra, màu nền của bảng điều khiển bên trái là màu xanh đậm, trong khi nó phải là màu tím. Tôi cũng lưu ý rằng văn bản của các chi tiết về Sản phẩm của Cửa sổ không được dịch tốt sang tiếng Đức; nó có được mong đợi không Khi bản dịch cuối cùng sẽ có sẵn? BTW, bạn đã nhận được biểu tượng mới mà tôi đã gửi cho sản phẩm Xuất bản của NXB chưa? Tôi không thấy nó trong cửa sổ dữ liệu của Sync Sync.

• Ngày 6 [Nhà phát triển] Tôi đã thay đổi màu thành màu tím.

• Ngày 7 [Nhà phát triển] Có, việc dịch sang tiếng Đức là không hoàn chỉnh.

• Ngày 8 [Khách hàng] Ok cho tiếng Đức. Ý thì sao? Lucia đã gửi cho bạn tệp XML hai ngày trước.

• Ngày 9 [Nhà phát triển] Bây giờ thì ổn rồi.

• Ngày 10 [Khách hàng] Ok cho nút Xóa Xóa? Lạ thật, ở máy tính của tôi, nó vẫn bị treo.

• Ngày 11 [Nhà phát triển] Không, tôi muốn nói rằng nó ổn đối với bản dịch tiếng Ý.

• Ngày 12 [Khách hàng] Tôi thấy. Cảm ơn bạn. Nhưng có một vấn đề với màu sắc. Bạn đã thay đổi nó thành màu tím đậm, nhưng nó sẽ có màu tím nhạt, giống như bảng trên cùng trên cửa sổ chính.

• Ngày 13 [Nhà phát triển] Tôi đã cập nhật biểu tượng.

• Ngày 14 [Khách hàng] Biểu tượng? Biểu tượng gì?

• Ngày 15 [Nhà phát triển] Biểu tượng bạn yêu cầu tôi cập nhật.

• Ngày 16 [Khách hàng] Tôi chưa bao giờ yêu cầu bạn cập nhật bất kỳ biểu tượng nào.

• Ngày 17 [Nhà phát triển] Tất nhiên bạn đã hỏi. Xem vé này. Bạn đã viết rằng biểu tượng sản phẩm xuất bản nên được cập nhật. Tôi đã làm xong.

  ⁞

• Ngày 100 [Khách hàng] Vậy còn các mục trong nhật ký thì sao?

• Ngày 101 [Nhà phát triển] Tôi không biết bạn đang nói về cái gì. Nó thậm chí không có trong vé này, nhưng vào năm 6199. Tôi sẽ đóng cái này như đã giải quyết. <Vé đã đóng: vấn đề đã được giải quyết>

• Ngày 102 [Khách hàng] Xin lỗi để mở lại, nhưng vấn đề không được giải quyết. Tôi đang nói về các mục trong nhật ký: Tôi đã nói với bạn tuần trước rằng văn bản đôi khi không hợp lệ khi nó chứa các ký tự unicode. Bạn có nhớ? <Vé mở lại>

• Ngày 103 [Nhà phát triển] Tôi mơ hồ nhớ một cái gì đó như thế, nhưng sau khi tìm kiếm ba trang cuối của vé này, tôi không thể tìm thấy bất kỳ dấu vết nào. Bạn có thể viết lại vấn đề là gì không?

  ⁞

• Ngày 460 [Nhà phát triển] Tôi đã dành hai giờ để tìm kiếm dấu vết của những gì bạn đã nói về các tệp được gửi mã hóa qua mạng. Tôi không chắc tôi có thể tìm thấy yêu cầu chính xác.

• Ngày 460 [Khách hàng] Các bạn nên thực sự có tổ chức hơn. Tôi đã thông báo cho bạn bốn lần về vấn đề này trong hai tuần qua. Tại sao bạn quên mọi thứ?

  ⁞

Nhật ký này là về cái gì? Nó đã được giải quyết 43 lần và mở lại 43 lần. Điều đó có nghĩa là nhà phát triển ngu ngốc đến mức anh ta không thể giải quyết vấn đề tương tự trong 460 ngày? À, không, chờ đã, vé này đã được chỉ định cho 11 nhà phát triển. Thỏa thuận là gì? Làm thế nào để tìm kiếm một vấn đề cụ thể? Nó thực sự được giao cho Vanessa, nhưng năm đồng nghiệp của cô cũng lo ngại bởi bảy trong số mười một vấn đề trong tấm vé này. Khi nào nên đóng vé? Có phải khi một nửa các vấn đề được giải quyết? Hoặc có thể mười trong số mười một?

Lưu ý: Bạn có thể tin rằng những bản ghi như vậy không tồn tại. Hãy tin tôi, tôi đã nhìn thấy những người nhiều hơn một lần.

Chỉ cần nhận xét về tuyên bố của bạn:

không thể là vì sửa chữa-phản hồi-giải quyết-đóng nên tránh trường hợp đó

Điều này giả định rằng tất cả các lỗi được nêu ra sẽ được sửa chữa cùng một lúc. Hãy tưởng tượng một kịch bản trong đó một vé được nâng lên so với v1 của sản phẩm với hai vấn đề:

1. Nút đặt lại biểu mẫu thực sự gửi biểu mẫu, thay vì xóa các giá trị
2. Kích thước phông chữ trên nút là 110% khi nó phải là 115%.

Cả hai đều đúng cho một người thử nghiệm để nâng cao, vì cả hai đều là lỗi với việc thực hiện. Nhưng hãy nói rằng chủ sở hữu sản phẩm quyết định rằng chương trình con đầu tiên là một trình chặn để phát hành (nghĩa là nó phải được sửa trước khi sản phẩm có thể hoạt động), nhưng nhiệm vụ thứ hai là một vấn đề nhỏ (có thể được khắc phục trong v1. 1 bản phát hành).

Trong trường hợp đó, chúng tôi không có lựa chọn nào khác ngoài việc tách số 2 thành vé riêng của mình (hoặc có nguy cơ quên nó). Nếu chúng ta có thể làm điều này, điều đó có nghĩa là chúng có thể được thực hiện, thử nghiệm và triển khai độc lập với nhau, trong trường hợp đó có ý nghĩa khi có các vấn đề riêng lẻ ngay từ đầu.

Phạm vi:

Câu trả lời này (và câu hỏi) dường như chỉ áp dụng cho việc theo dõi lỗi mã, trong đó mã nguồn không thực hiện theo đặc điểm kỹ thuật hoặc ý định của lập trình viên.

Ngược lại, thông thường, vé khiếm khuyết GUI có chứa nhiều thông số kỹ thuật, bởi vì mỗi vé GUI thực sự là một "thiết kế lại" (lỗi thiết kế), "đặc tả sửa đổi" hoặc "yêu cầu tính năng" (thiếu chức năng).

Một mục đích quan trọng của theo dõi lỗi là giao tiếp và phối hợp giữa nhiều vai trò (lập trình viên, người kiểm tra, khách hàng và người quản lý).

Trong các dự án mà chất lượng mã có ý nghĩa cao (ví dụ như thân thiện với người dùng), theo dõi lỗi có thể bao gồm nhiều khía cạnh, một trong số đó sẽ tập trung vào theo dõi các lỗi mã , tách biệt với theo dõi các cải tiến và yêu cầu hỗ trợ khách hàng.

Mục đích của hệ thống theo dõi lỗi mã là:

• Để cho phép theo dõi độc lập và rõ ràng các khiếm khuyết có thể lặp lại độc lập và
• Để cung cấp xấp xỉ tốt nhất (tương ứng một-một) với nguyên nhân gốc rễ của mỗi khiếm khuyết.

Trong khi làm như vậy, nó sẽ tối đa hóa các phẩm chất mong muốn sau đây:

• Quy mô hiệu quả khi số lượng khuyết tật tăng theo thời gian.
• Ngăn ngừa hội chứng mục tiêu di chuyển.

Tuyên bố từ chối trách nhiệm: cụm từ này là từ kinh nghiệm cá nhân của tôi. Nó có thể không đủ hoặc không chính xác cho mục đích thi chứng chỉ.

Theo dõi độc lập và rõ ràng có nghĩa là:

1. Mỗi khiếm khuyết hợp lệ có thể được giải quyết hoặc không được giải quyết , không có sự mơ hồ.

   • Lý do 1: để đơn giản hóa việc quản lý,
     • Ví dụ: nó cho phép sử dụng "số lượng vé chưa được giải quyết" làm số liệu.
   • Lý do 2: để dịch thành mục hành động
     • Ví dụ: nếu nó không được giải quyết, trách nhiệm thuộc về lập trình viên được chỉ định. Nếu nó được giải quyết nhưng không bị đóng, trách nhiệm thuộc về người kiểm tra được chỉ định (người xác minh).
   • Hậu quả: Trong phương pháp này, một khiếm khuyết được giải quyết một phần xứng đáng được chia thành một số khiếm khuyết phụ thuộc.

2. Khiếm khuyết tái sản xuất độc lập nên được theo dõi độc lập.

   • "Tái sản xuất độc lập" có nghĩa là chúng có thể có các trạng thái khác nhau. Một cái có thể được sửa chữa trong khi cái còn lại bị hỏng.
   • Lý do: để giảm thiểu sự không phù hợp giữa theo dõi lỗi và phân tích nguyên nhân gốc rễ.
     • Mỗi nguyên nhân gốc có thể bắt nguồn từ lỗi mã được cho là cần ít nhất một thay đổi mã.
     • Nếu hai lỗi có thể tái tạo độc lập, thì sẽ cần nhiều thay đổi mã.
     • Nếu hai lỗi có thể lặp lại độc lập, cả hai đều phải được kiểm tra (xác minh), bởi vì việc vượt qua một thử nghiệm không có nghĩa là thử nghiệm kia sẽ vượt qua.
   • Ví dụ 2: nếu hai triệu chứng ban đầu được cho là có cùng nguyên nhân gốc và do đó được phân loại thành cùng một vé, và sau đó chúng được chứng minh là có thể tái tạo độc lập, thì chúng nên được chia thành hai vé.

Nhìn vào nó từ quan điểm của một người khác sử dụng hệ thống, hiển thị một vài tháng sau đó. Họ tìm thấy một lỗi trong chương trình. Họ Google xung quanh và thấy rằng có một vé hỗ trợ phù hợp với vấn đề họ gặp phải. Và này, nó đã đóng cửa! Tuyệt vời! Nó đã được sửa trong phiên bản mới nhất! Vì vậy, họ cập nhật ... và lỗi vẫn còn đó? Có chuyện gì với những nhà phát triển ngu ngốc này?!?

Không có gì, thực sự. Hóa ra có điều gì đó không đúng với người gửi báo cáo lỗi. Họ đã gửi hai lỗi trong cùng một vé. Một cái thì dễ sửa, và được sửa nhanh, còn cái kia thì không. Ngay cả khi bạn sử dụng một cái gì đó như sửa chữa-phản hồi-giải quyết-đóng, nó vẫn có thể ít rõ ràng hơn những gì đang xảy ra, đặc biệt là đối với một người quan sát bên ngoài.

Sẽ tốt hơn nhiều khi cung cấp cho mỗi lỗi một vé riêng và nếu bạn có nhiều lỗi có liên quan nhưng rõ ràng khác biệt, hầu hết các hệ thống theo dõi lỗi đều có một tính năng cho phép bạn liên kết một lỗi với nhau. (Và nếu không, bạn chỉ có thể đưa nó vào báo cáo. "Xem thêm lỗi # 12345.")