Trong đó: * New: Lỗi mới * Assigned: Lỗi đã được gán cho nhân viên phát triển * Resolved: Lỗi đã được xử lý * Confirmed: Lỗi cần được chứng thực, thảo luận lại * Canceled: Lỗi được xác định là không phải lỗi, lỗi được bỏ qua * Next: Lỗi không thuộc phạm vi của dự án, hoặc sẽ được xử lý trong một giai đoạn khác của dự án * Accept: Các lỗi có thể chấp nhận được. Ví dụ: Các lỗi do Framework * Closed: Trạng thái đóng. Lỗi đã được sửa thành công.
Mỗi tổ chức phát triển phần mềm sẽ sử dụng một công cụ quản lý lỗi riêng, trong đó có thể kể đến Mantis là một công cụ được sử dụng khá phổ biến hiện nay. Phần tiếp theo sẽ trình bày một qui trình xử lý lỗi phần mềm hiện đang được sử dụng trong thực tế ở một số tổ chức phát triển và gia công phần mềm:
Sơ đồ 3: Qui trình xử lý lỗi
Theo đó, qui trình xử lý lỗi có thể bao gồm 6 bước chính:
Bước 0_Bắt đầu: Phát hiện phần mềm có lỗi
Bước 1_Đưa lỗi lên hệ thống quản lý lỗi
Bước 2_Gán lỗi cho nhân viên phát triển
Bước 3_Xử lý lỗi
Bước 4_Kiểm thử lại
Bước 5_Đóng lỗi
3.1. Bước 1: Đưa lỗi lên phần mềm quản lý lỗi
Người thực hiện: tất cả các thành viên trong đội dự án như quản trị dự án, nhóm kiểm thử, nhóm giải pháp, nhóm lập trình.
Trạng thái của lỗi là NEW.
*** Một số thông tin cần có về lỗi: **
Category: Thư mục lỗi dùng để phân loại lỗi, lỗi thuộc phần chức năng nào phải chọn đúng phần thư mục lỗi tương ứng để thuận tiện cho việc tra cứu, thống kê lỗi của chức năng.
Severity (trọng số của lỗi): Thông số này biểu hiện độ nghiêm trọng của lỗi, thông thường lỗi sẽ thuộc một trong ba trọng số dưới đây:
Minor: Các lỗi định dạng (font chữ, cỡ chữ, màu sắc của các đối tượng, chiều dài của các đối tượng), lỗi chính tả, lỗi validate dữ liệu.
Major: Các lỗi ràng buộc dữ liệu, lỗi chức năng nghiệp vụ của hệ thống (nhưng chưa gây ra treo hệ thống hay không làm cho hệ thống không xử lý được tiếp).
Crash: Các lỗi chức năng nghiệp vụ của hệ thống gây treo hệ thống, không xử lý được tiếp.
Reproducibility: Khả năng tái tạo lỗi. Khi phát hiện ra lỗi, nhân viên kiểm thử cần thực hiện lại phần chức năng phát hiện ra lỗi để xét khả năng tái tạo lỗi và lựa chọn đúng khả năng tái tạo lỗi.
Priority: Mức độ ưu tiên trong việc sửa lỗi.
Summary: Tóm tắt nội dung lỗi, có thể coi là tiêu đề của lỗi.
Description: Đây là phần mô tả lỗi, phải mô tả rõ 3 phần nội dung:
Các bước thực hiện.
Kết quả trả về từ hệ thống o Kết quả mong muốn
Notes: Dùng để đưa các lưu ý, trao đổi về lỗi của các thành viên trong dự án.
3.2. Bước 2: Gán lỗi cho nhân viên phát triển
Nhân viên kiểm thử thực hiện gán lỗi cho nhân viên phát triển, người sẽ chịu trách nhiệm về phần chức năng bị lỗi.
Trạng thái của lỗi là ASSIGNED.
Lưu ý: Trưởng nhóm kiểm thử, quản trị dự án có thể xem xét lại các lỗi có trạng thái NEW và ASSIGNED trên hệ thống phần mềm quản lý lỗi: o Nếu thấy không phải là lỗi thì đưa lỗi về trạng thái CANCELLED và nêu rõ nguyên nhân đưa lỗi về CANCELLED.
Nếu thấy nhân viên kiểm thử mô tả không rõ ràng, thiếu thông tin thì chuyển lỗi sang trạng thái CONFIRMED và yêu cầu nhân viên kiểm thử bổ sung thêm thông tin.
Nếu thấy lỗi không thuộc phạm vi phát triển của dự án trong giai đoạn hiện tại thì chuyển lỗi về trạng thái NEXT.
Quản trị dự án xem xét lại các lỗi có trạng thái NEW hoặc ASSIGNED, nếu thấy là lỗi nhưng có thể chấp nhận được thì chuyển lỗi sang trạng thái ACCEPTED và nêu rõ nguyên nhân đưa lỗi về trạng thái ACCEPTED.
3.3. Bước 3: Xử lý lỗi
Nhân viên phát triển xem xét các lỗi được gán cho mình:
Nếu thấy đúng là lỗi và đã mô tả lỗi rõ ràng, đầy đủ thông tin, nhân viên phát triển thực hiện sửa lỗi và chuyển lỗi về trạng thái RESOLVED, đồng thời bắt buộc nêu rõ hướng giải quyết và các chức năng bị ảnh hưởng trong phần NOTES.
Các trường hợp khác: Nếu thấy không phải là lỗi của hệ thống, nhân viên phát triển sẽ yêu cầu nhân viên kiểm thử bổ sung thêm thông tin, hoặc thấy là lỗi nhưng có thể chấp nhận được lỗi thì nhân viên phát triển chuyển lỗi sang trạng thái CONFIRMED và nêu rõ lý do chuyển lỗi sang trạng thái CONFIRMED trong phần NOTES.
3.4. Bước 4: Kiểm thử lại
Theo phân công của trưởng nhóm kiểm thử, nhân viên kiểm thử thực hiện kiểm thử lại các chức năng có lỗi đang ở trạng thái RESOLVED:
Nếu lỗi đã được sửa thì chuyển lỗi về trạng thái CLOSED.
Nếu lỗi chưa được sửa hoặc mới chỉ sửa một phần thì chuyển lỗi về trạng thái ASSIGNED và nêu rõ những phần chức năng nào chưa chỉnh sửa để nhân viên phát triển tiến hành sửa tiếp.
Nếu thấy có thể chấp nhận lỗi thì chuyển lỗi về trạng thái ACCEPTED. Đồng thời khi cập nhật kịch bản kiểm thử thì sẽ để kết quả của case đó là fail (vì vẫn là lỗi).
Lưu ý: Nếu phần chức năng bị ảnh hưởng gây ra lỗi mới thì đưa một lỗi mới lên phần mềm quản lý lỗi.
*Tổng kết
Bài viết đã trình bày được những định nghĩa và những vấn đề cơ bản xung quanh phần mềm, công nghệ phần mềm, lỗi phần mềm và xử lý lỗi phần mềm.
Các vấn đề cụ thể bao gồm:
Các định nghĩa về phần mềm, công nghệ phần mềm, chất lượng phần mềm, bảo đảm chất lượng phần mềm, lỗi phần mềm.
Các vấn đề liên quan đến lỗi phần mềm và qui trình xử lý lỗi phần mềm.
