Bugzilla quản lí bug như thế nào

Tìm hiểu Bugzilla
Bugzilla là một hệ thống quản lý bug miễn phí và rất thông minh hiện nay. Bugzilla được
phát triển và sử dụng bởi tổ chức Mozzila (cũng là tổ chức phát triển Firefox có tiền thân từ
công ty Netspace Communications vào năm 1998)
- Bugzilla là một mã nguồn mở, được đưa ra bởi Terry Weissman vào năm 1998
- Bugzilla 2.0 là phiên bản đầu tiên được phát hành ra công chúng vào tháng Tư năm 2000
- Bugzilla 3.0 phát hành vào ngày 09/05/2007 với những tính năng nổi bật sau:
+ Fields tùy chỉnh
+ Hỗ trợ các mod_perl cải thiện hiệu suất
+ Giao diện XML _ RPC
+ Tạo và sửa bug bằng email
- Bugzilla 3.4 được phát hành vào ngày 20/07/2009 bao gồm nhiều cải tiến đáng kể so với phiên bản
trước:
+ Các tùy chỉnh được cải tiến
+ URL cho các tìm kiếm ngắn hơn, vì vậy nó có thể dễ dàng chia sẻ hơn
+ Địa chỉ email của người dùng có thể được ẩn (ngăn chặn thư rác)
- Bugzilla 4.0 được cho là phiên bản tốt nhất trong lịch sử bugzilla , nó được phát hành vào ngày
15/02/2011 và được sử dụng phổ biến cho đến tận bây giờ với các tính năng tuyệt vời sau:
+ Phát hiện trùng lặp khi nộp lỗi
+ Kiểm soát hoàn toàn và thu hồi lỗi thông qua Webservices, bao gồm cả lỗi cập nhật hiện tại
+ Những cải tiến trong khả năng sử dụng
+ Trang tìm kiếm nâng cao được thiết kế lại hoàn toàn
- Bugzilla 4.2 được phát hành vào ngày 22/02/2012 . Phiên bản này đi kèm với một số tính năng và
cải tiến mới.
- Bugzilla 4.2 chứa đựng những cải tiến lớn để tìm kiếm , hỗ trợ cho SQLite, cải thiện Webservices
và nhiều cải tiến khác.
Lịch sử phát triển Bugzilla qua từng giai đoạn

1. Khá niệm:
Quy trình : Input(thông tin lỗi) -> Process (Bugzilla) -> Output(Trạng thái của lỗi : đã sửa hay chưa)

2. Chức năng:
- Quản lí qui trình sửa lỗi phần mềm miễn phí
- Quản lí hoạt động, tiến độ test lỗi của từng dự án
- Cho phép nhiều user làm việc cùng lúc
- Tìm lỗi và phân bố công việc cho từng thành viên
- Cập nhật thông tin cho từng thành viên tham gia dự án qua thư điện tử
3. Quy trình hoạt động

4. Vòng đời quản lý Bug
4.1 Vòng đời của Bug

4.2.1 NEW

Trạng thái NEW là bug mới vừa được post lên hệ thống quản lý bug. Sau khi post bug thành
công thì hệ thống Bugzilla sẽ gửi mail tới những thành viên liên quan như DEV (người được
phân công fix bug này), PJ Leader.
Từ trạng thái NEW, có thể chuyển sang trạng thái ASSIGNED hoặc RESOLVED

4.2.2
ASSIGNED Trạng thái này là bug được phân công cho DEV nào đó fix, lúc này bug vẫn
chưa được fix.
Từ trạng thái này, bug có thể được chuyển sang trạng thái NEW (chuyển cho người khác fix
bug) hoặc RESOLVED (đã fix xong bug).

4.2.3 RESOLVED
Trạng thái này là bug đã được sửa xong, kết quả có thể là FIXED, INVALID, WONTFIX,
DUPLICATE, LATER hoặc REMIND.

Ở trạng thái này, bug có thể chuyển sang trạng thái REOPEN, VERIFIED, CLOSED hoặc
UNCONFIRMED (trường hợp này ít dùng, thường dùng trong trường hợp vấn đề này còn
đang tranh cãi không biết phải xử lý như thế nào)
Các kết quả của RESOLVED bao gồm:
- FIXED: Bug đã fix xong.
- INVALID: Vấn đề này không phải là bug.
- WONTFIX: Vì lý do nào đó, bug này sẽ không fix (có thể do không có thời gian hoặc bug
không quan trọng – cải tiến hoặc không sửa được).
- DUPLICATE: Post bug bị trùng với một bug nào đó đã post trước đây. Nếu chọn trạng thái
này thì phải nhập thêm bug id của bug bị trùng.
- WORKSFORME: Mình không dùng trạng thái này.
- LATER: Vì lý do nào đó bây giờ chưa thể fix được, chờ fix sau (có thể do chờ Q/A khách
hàng).
- REMIND: Giống như LATER
Chỉ có tester/QC mới có quyền thay đổi trạng thái từ RESOLVED sang các trạng thái khác
sau khi đã test lại.

4.2.4 REOPENED
Trạng thái này là do TESTER/QC chuyển từ trạng thái RESOLVED sang, do sau khi test lại
thì bug vẫn còn bị lỗi hoặc gây ra lỗi khác khi thao tác tương tự như bug cũ. (ví dụ, lần trước
nhập hai số 1 và 3 vào hai ô trên màn hình, click nút = thì kết quả là 6, sau khi sửa bug xong,
làm tương tự như trên, click nút = thì kết quả là 5; kết quả vẫn sai nhưng không giống như lúc
đầu).
Ở trạng thái này bug có thể chuyển sang trạng thái RESOLVED hoặc ASSIGNED.

4.2.5 5 VERIFIED
Trạng thái này là TESTER đã test lại xong và xác nhận bug này đã được fix. (trong trường
hợp TESTER không có quyền đóng bug, do QC Leader đóng).

Từ trạng thái này có thể chuyển sang trạng thái UNCONFORMED, REOPEN hoặc CLOSED
4.2.6 CLOSED
Trạng thái này là bug đã được fix và được test lại xong. Kết thúc vòng đời của một bug.
Trong trường hợp bug đã đóng rồi mà khi fix bug khác, gây ra lỗi bug này nữa thì sẽ chuyển
từ trạng thái CLOSED sang REOPEN
5.Sử dụng Bugzilla
5.1 Tạo bug

5. Ưu điểm và Nhược Điểm
- Ưu điểm :
+ Là công cụ tracking được sử dụng bởi nhiều yếu tổ chức
+ Khả năng hoạt động nhanh nhẹn, nhẹ nhàng

+ Độ an toàn cao
+ Hệ thống phân quyền tuyệt vời, hoàn toàn miễn phí
- Nhược điểm:
+ Hạn chế trong việc tích hợp với các công cụ khác
+ Để add một bug mất nhiều thao tác
+ Đòi hỏi sự liên lạc, trao đổi thường xuyên giữa test leader với các thành viên trong
nhóm
+ Thông tin về Bug rất đơn thuần
6. Các phần mềm quản lý lỗi khác
6.1 Mantis
// để logo Mantis vào
- Hỗ trợ bất kỳ nền tảng nào chạy PHP
- Sử dụng đơn giản, dễ dàng cài đặt
- Không giới hạn số lượng người dùng, dự án
- Hỗ trợ thông báo email toàn diện
- Có mức độ truy cập khác nhau cho mỗi dự án

6.2
BugNet
// để logo Bugnet vào
- Hỗ trợ nhiều co sở dữ liệu
- Hỗ trợ nhiều dự án
- Có cộng đồng hỗ trợ trực tuyến
- Quản lý vấn đề tốt
- Dễ dàng chuyển hướng và quản lý
6.3 Jira
//Để logo Jira vào
- Giao diện người dùng mạnh mẽ, dễ sử dụng

- Dễ dàng mở rộng và tích hợp với các hệ thống khác
- Có thể chạy trên hầu hết các hệ điều hành
- Quản lý lỗi, tính năng, công việc
- Tương thích quy trình, nghiệp vụ theo luồng công việc
6.4 So sánh Bugzilla và Jira

Nguồn tham khảo :
[1] www.bugzilla.org/news
[2] en.wikipedia.org/wiki/Bugzilla
[3] testingvn.com