Những tính năng quan trọng đối với phần mềm theo dõi lỗi tốt?

8

Những tính năng quan trọng đối với phần mềm theo dõi lỗi tốt và tại sao chúng quan trọng? Điều gì đặc biệt là cần thiết để bạn xem xét các tính năng này được thực hiện phải không?

issue-tracking

— Casebash
nguồn

19

Sự đơn giản. Nếu quá phức tạp hoặc quá lâu để nhập hoặc sắp xếp các lỗi, sẽ không ai muốn sử dụng nó.

— Guillaume
nguồn

Bạn có bất kỳ ví dụ về những gì bạn cho là quá phức tạp?

— Casebash

Sản phẩm mới nhất tôi phải sử dụng: Thần chú. Cách quá nhiều bước cần thiết để chỉnh sửa và gán lại hoặc đóng vé. Tuyên bố miễn trừ trách nhiệm: phiên bản đang sử dụng đã không được cập nhật trong một thời gian dài. Có lẽ mọi thứ được cải thiện kể từ đó.

— Guillaume

Chà, tôi đã sử dụng rộng rãi Thần chú và phiên bản của chúng tôi (cũng khá cũ) đã mất hai lần nhấp để gán lại lỗi và ba lần nhấp để đóng (cộng với nhập lý do). Vì vậy, tôi không thể thực sự phàn nàn.

— sleske

@Casebash - Bugzilla quá phức tạp.

— mouviciel

4

Tích hợp với SCM, để mọi sửa lỗi có thể được truy ngược lại mã và các thay đổi mã có thể được truy ngược lại thành một vấn đề. Điều này không đòi hỏi sự cảnh giác để chỉ kiểm tra mã liên quan đến vấn đề đang được thúc đẩy / kiểm tra. tức là không có "Tính năng xyz đã thêm và đã sửa lỗi ngẫu nhiên ở 4 vị trí khác nhau và bộ tái cấu trúc nhanh tính năng zyx".

Một tính năng tốt khác là quản lý quy trình công việc, để quy trình kinh doanh được tuân theo mã. Ví dụ: có thể có đường dẫn quy trình công việc giống như sau: Lỗi được báo cáo -> Được xử lý ưu tiên và hợp lệ -> được gán cho dev -> làm việc trên -> gán cho QA -> vượt qua kiểm tra -> đánh dấu là đã đóng.

— Hugo
nguồn

2

Quyền sở hữu của các lỗi. Không nên có một vấn đề mở không phải là trách nhiệm của ai đó. Khác hơn thế, đơn giản là tốt hơn.

— Dan Dyer
nguồn

1

Mục theo dõi thực sự có thể là trách nhiệm của không ai.

— David Thornley

Làm thế nào để bạn thấy rằng làm việc? Có thể có một độ trễ thời gian trước khi nó được chỉ định? Hoặc sẽ có một số cách để xác định ai là có sẵn?

— JeffO

Khi một lỗi được tạo, nó được chỉ định cho người mặc định quyết định phải làm gì với nó (có thể là người lãnh đạo dự án hoặc người quản lý dự án).

— Dan Dyer

Điều này phụ thuộc vào quá trình của bạn. Nếu ví dụ, các lỗi được xử lý khi đến nơi, và sau đó được đưa vào một hồ sơ tồn đọng ưu tiên, thì không cần phải có chủ sở hữu. Thực tế, việc có một chủ sở hữu đối với tôi dường như có phần mâu thuẫn với ý tưởng về một nhóm chức năng chéo, và có thể giới thiệu một cổ chai nhân tạo.

— sleske

2

Khả năng báo cáo tốt / nhanh. Quản lý muốn theo dõi xu hướng lỗi.
API để tự động hóa, thông báo email tự động, tích hợp với kiểm soát nguồn, v.v.

— Grokus
nguồn

2

báo cáo tùy chỉnh : khả năng nhanh chóng tạo và lưu các truy vấn về vé, bởi tất cả người dùng không chỉ là quản trị viên. tất cả mọi người thích quan điểm riêng của họ về các lỗi. nếu điều này được thực hiện đúng, không cần thông báo, chỉ cần đăng nhập vào chế độ xem 'vé trên đĩa của tôi'
liên kết với kiểm soát phiên bản : nên dễ dàng tìm thấy các thay đổi mã liên quan đến vé.
lưu lượng thông minh : hệ thống không nên cho phép vé ở trạng thái mà chúng sẽ rơi vào vết nứt - vì vậy nếu trạng thái thay đổi thành 'Bị từ chối', hệ thống sẽ thực thi việc gán cho ai đó trong dev
tùy biến : mỗi dự án là khác nhau, mỗi nhóm là khác nhau. một số nhóm cần 8 trạng thái khác nhau, một số chỉ cần 3. nhưng, GUI vẫn còn
đơn giản : giữ các yếu tố chính của vé lớn và trả trước và đơn giản. phiên bản, tiêu đề, mô tả, trạng thái, chủ sở hữu
lịch sử : điều này thực sự nổi bật khi nó làm sai (tôi đang nhìn bạn, Unfuddle); vì vậy nó cần được chỉ ra lịch sử thay đổi của vé cần được hiển thị trong nhật ký theo thời gian tốt đẹp.

— Alex Fairchild
nguồn

1

Tôi thấy nó khá quan trọng để có thể liên kết các vấn đề (và chỉ định một loại liên kết, ví dụ: Phụ thuộc vào). Ngoài những nghi ngờ thông thường về phiên bản mà lỗi được tìm thấy, phiên bản nào chúng tôi đang nhắm đến để sửa nó (để chúng tôi có thể lái bản đồ đường bộ), một trường ước tính phù hợp cho việc lập kế hoạch dự án / nhanh.

Rất vui khi tôi bỏ phiếu từ công chúng, khả năng thông báo cho người dùng về các thay đổi đối với vấn đề và có một hệ thống khá linh hoạt để phân loại các vấn đề.

Trên thực tế, mọi thứ mà JIRA hỗ trợ rất nhiều :)

— Martijn Verburg
nguồn

0

Bất kỳ tính năng nào làm một nhiệm vụ cho lập trình viên. Nó không thực sự là một phần của IDE? Có danh sách các lỗi. Chọn một để làm việc và tất cả các tem trạng thái và thời gian được chăm sóc. Các thay đổi mã được liên kết. Các xét nghiệm cần thiết có liên quan. Kiểm tra nó như là cố định, cập nhật trạng thái và cho mọi người khác biết về nó.

— Jeff
nguồn

2

Có thể là một phần của IDE nhưng cũng nên có một phần có thể được truy cập mà không có IDE vì có thể có những người khác tham gia vào dự án không sử dụng IDE.

— Victor Hurdugaci

@Victor Hurdagaci - điểm tốt. Nó cần phải được truy cập cho tất cả những người cần nó trong một hình thức thích hợp.

— JeffO

0

Khả năng xác định điểm tương đồng trên các vé đã đóng.

Có thể được sử dụng algoritms khai thác dữ liệu, có lẽ.

— Pagotti
nguồn

0

Truy vấn mạnh mẽ
Phần mềm theo dõi lỗi sẽ giúp quản lý các dự án bằng cách thực thi quy trình phát triển nghiêm ngặt ở từng giai đoạn giải quyết vấn đề.

— Biển Catherine
nguồn

1

Câu trả lời này có thể hữu ích hơn nếu bạn cung cấp thêm chi tiết. Ngoài ra, hãy xem Câu hỏi thường gặp tại lập trình viên.stackexchange.com / faq để được tư vấn về cách trả lời tốt nhất các câu hỏi với không quá ít, không có nhiều thông tin.

— Nhà phát