Các bước để duy trì cơ sở dữ liệu lỗi tốt

Duy trì cơ sở dữ liệu lỗi là một điều quan trọng cho mọi dự án. Tôi được sử dụng để lưu trữ các nội dung sau tại cơ sở dữ liệu lỗi

• Ngày phát hành
• Ai được phân công
• Cho dù nó đã được giải quyết hay chưa
• Nếu giải quyết xong, ngày giải quyết

Là những người đủ để duy trì một cơ sở dữ liệu lỗi tốt?

Một cơ sở dữ liệu lỗi tốt có thể có những điều sau đây

// Ngày giờ liên quan

• Ngày phát hành lỗi
• Dự kiến ​​sửa chữa / giải quyết thời gian ngày
• Nếu giải quyết xong, ngày giải quyết

// Được gán bởi + To

• Được chỉ định bởi (được phát hiện bởi)
• Phân công

// Hành vi lỗi

• Hành vi quan sát (lỗi)
• Ảnh chụp màn hình (Có thể)
• Hoàn thành các bước để tạo lại lỗi
• Hành vi dự kiến

// Sự ưu tiên

• Ưu tiên của lỗi

// Liên kết, Trạng thái và những người khác

• Liên kết các lỗi liên quan
• Tình trạng lỗi
• Cho dù nó đã được giải quyết hay chưa
• Nếu giải được thì giải quyết thế nào với

EDIT: Tôi cũng muốn giới thiệu

• Trong bản sửa đổi / chi nhánh đã phát hiện ra lỗi
• Trong bản sửa đổi / chi nhánh có lỗi đã được sửa

EDIT: Tôi thích bình luận của @ jgauffin

• Không sửa, Không phải là lỗi, Sao y, Đã giải quyết

EDIT: Một hệ thống cơ sở dữ liệu lỗi tốt cũng duy trì

• Ma trận phân công trách nhiệm

Có thể có một số trường tùy chỉnh mà bạn có thể cần phải đăng nhập, tùy thuộc vào nhu cầu của dự án. Tôi đã đưa ra danh sách sau đây mà bạn có thể cần phải xem xét:

• Vấn đề DateTimelỗi / lỗi
• Mô tả về lỗi - các bước để tạo lại.
• Môi trường nơi nó tìm thấy (Dev, QA, QC, Staging, Prod)
• Ảnh chụp màn hình của vấn đề
• Ai đã đăng nhập nó (được phát hiện bởi)
• Nó được chỉ định (được chỉ định bởi)
• Mức độ nghiêm trọng của lỗi (Thấp, Trung bình, Cao)
• Giải pháp dự kiến DateTime
• Bộ ba Nhà nước (Đề xuất, Đang tiến hành, Đã giải quyết, Đã đóng)
• Lỗi được đóng DateTime- khi một lỗi được giải quyết và đóng
• Được chỉ định để được kiểm tra (được kiểm tra bởi)

Chỉnh sửa: Hầu hết các thông tin phổ biến có giá trị được theo dõi đều được mô tả kỹ trong các phần mềm như Bugzilla . Bugzilla là một công cụ kiểm tra và sửa lỗi đa năng dựa trên web ban đầu được phát triển và sử dụng bởi dự án Mozilla và được cấp phép theo Giấy phép Công cộng Mozilla - và MIỄN PHÍ . Tôi đặc biệt khuyên bạn nên lấy chúng làm ví dụ chính và mở rộng nó theo nhu cầu dự án của bạn.

Hầu hết các lĩnh vực hữu ích dường như đã được bao phủ bởi các câu trả lời khác, nhưng một số lĩnh vực mà tôi thấy hữu ích là:

• Trong những gì sửa đổi / chi nhánh là lỗi được phát hiện.
• Trong những sửa đổi / chi nhánh đã được sửa chữa.

Điều này cụ thể hơn một chút so với thời điểm phát hiện / sửa lỗi.

Nếu phần mềm của bạn chạy trên một số nền tảng (HĐH hoặc phần cứng), bạn cũng có thể muốn một trường liệt kê các nền tảng xảy ra lỗi.

Nhưng có nhiều thứ để duy trì cơ sở dữ liệu lỗi hơn những trường cần chứa. Bạn cũng cần xem xét cách bạn sử dụng cơ sở.

Cố gắng giữ số lượng lỗi mở / chưa được giải quyết càng thấp càng tốt. Điều này có vẻ rõ ràng, nhưng có thể khó khăn hơn dự kiến, ít nhất là đối với các dự án lớn hơn. Tôi thường thấy mọi người quá sợ đóng các vấn đề không thể tái tạo hoặc nơi thiếu thông tin không bao giờ được cung cấp bởi người gửi ban đầu của vấn đề. Ngoài ra, các lỗi đã được đặt xung quanh mãi mãi và được nhìn thấy lần cuối trong các phiên bản cổ của phần mềm không nên để lại xung quanh. Điều này làm cho cơ sở dữ liệu phát triển với các vấn đề có thể hoặc không phải là vấn đề thực sự và làm chậm sự phát triển.

Bạn thường cần xem lịch sử của một lỗi _ nó có thể được giải quyết, sau đó mở lại, sau đó giải quyết lại, v.v. Vì vậy, ngoài những gì đã được đề xuất, tôi khuyên bạn nên có một bảng riêng để theo dõi về lịch sử của một lỗi mỗi lần nó được mở lại. Bảng sẽ có mối quan hệ nhiều-một với bảng lỗi và có thể có các trường như:

• Ngày mở cửa
• Đã mở bởi
• Ngày giải quyết
• Đã giải quyết bằng
• Thời gian đã qua
• Làm thế nào đã được giải quyết
• Vân vân.

Bạn cũng có thể cần một bảng tương tự để theo dõi ai và khi nào lỗi được chỉ định, đặc biệt nếu bạn làm việc trong một nhóm lớn.

Tôi cũng đề nghị bạn hãy xem các hệ thống hiện có. IMHO Jira là một trong những hệ thống theo dõi vấn đề tốt nhất. Nó có các tính năng rất phong phú và bạn có thể sử dụng một số trong số đó làm hướng dẫn cho hệ thống của riêng bạn.

Quá trình theo dõi lỗi cũng quan trọng như dữ liệu. Hãy thử nghĩ về những điều sau đây:

• Làm thế nào để người dùng báo cáo lỗi?
• Ai nhập lỗi vào kho lưu trữ?
• Ai có thể xác nhận lỗi tồn tại?
• Ai có thể xác nhận lỗi được giải quyết?
• Ai thông báo cho người dùng cuối rằng lỗi đã được khắc phục?

Xây dựng Biểu đồ RACI để mọi người trong nhóm của bạn (bao gồm cả người dùng cuối biết trách nhiệm của họ. Kết hợp điều này với các kỹ thuật nhập dữ liệu phù hợp và bạn sẽ thấy nhiều giá trị hơn với nỗ lực nhỏ hơn.