Vòng đời của lỗi hoặc vòng đời của lỗi là một tập hợp các trạng thái cụ thể mà một lỗi trải qua trong suốt vòng đời của nó. Mục đích của việc tạo quy trình cho vòng đời của lỗi/lỗi là để cho phép người chịu trách nhiệm về lỗi/lỗi đó dễ dàng quản lý và thay đổi trạng thái cho đến khi lỗi/lỗi được loại bỏ hoàn toàn khỏi hệ thống
Trạng thái lỗi trong suốt vòng đời
Trạng thái của lỗi/lỗi thường khác nhau giữa các dự án. Dưới đây là sơ đồ vòng đời của một lỗi/lỗi, bao gồm tất cả các trạng thái có thể xảy ra:
- mới: Khi một lỗi mới được ghi lại và xuất bản lần đầu tiên. Nó được gán trạng thái là “Mới”
- Nhiệm vụ: Sau khi người thử nghiệm phát hành một lỗi, trưởng nhóm thử nghiệm sẽ phê duyệt lỗi đó và chuyển giao lỗi đó cho nhóm phát triển
- Mở: Nhà phát triển bắt đầu phân tích và sửa lỗi
- Đã sửa: Khi nhà phát triển đã sửa lỗi bằng cách sửa mã và xác nhận rằng nó đã được sửa, lỗi có thể được chuyển sang trạng thái “Đã sửa/Đã sửa”.
- Đang chờ kiểm tra lại: Sau khi lỗi được sửa, nhà phát triển sẽ chuyển lỗi đó cho người kiểm tra. Bởi vì người kiểm tra vẫn đang làm bài kiểm tra, nên trạng thái được chỉ định là “Đang chờ kiểm tra lại/Đang kiểm tra lại”.
- Retest: Tester thực hiện test lại chương trình ở giai đoạn này để kiểm tra xem lỗi đã được fixed hay chưa và thay đổi trạng thái thành “Re-test/Kiểm tra lại”.
- Đã xác minh: Người kiểm tra kiểm tra lại lỗi sau khi nhà phát triển sửa chúng. Nếu không có lỗi nào được phát hiện trong phần mềm, lỗi sẽ được sửa và trạng thái được gán là “Đã xác minh/Đã xác minh”.
- Mở lại: Nếu lỗi vẫn còn sau khi nhà phát triển khắc phục, người kiểm tra sẽ thay đổi trạng thái thành “Mở lại/Mở lại”. Lỗi 1 đã trở lại cho một chu kỳ mới.
- Đã đóng: Nếu lỗi không còn tồn tại, người kiểm tra sẽ gán trạng thái “Đã đóng/Đã đóng”.
- trùng lặp: Nếu lỗi lặp lại hai lần hoặc lỗi tương ứng với cùng một khái niệm lỗi, trạng thái sẽ trở thành “trùng lặp/trùng lặp”.
- rejected: Nếu nhà phát triển quyết định rằng lỗi không phải là một lỗi thực sự, nó sẽ thay đổi lỗi thành “rejected/bị từ chối”.
- deferred: Chỉ định trạng thái “hoãn lại/hoãn lại” cho các lỗi hiện tại nếu chúng không phải là ưu tiên chính và chúng dự kiến sẽ được sửa trong bản phát hành tiếp theo
- Không phải lỗi: Trạng thái được gán cho lỗi là “Không phải lỗi/Không phải lỗi” nếu nó không ảnh hưởng đến chức năng của ứng dụng.
- Người kiểm tra tìm lỗi/lỗi
- Trạng thái lỗi phân bổ: Mới/Mới
- Gửi lỗi cho người quản lý dự án để phân tích
- Người quản lý dự án quyết định xem lỗi đó có hợp lệ hay không
- Nếu lỗi không hợp lệ, trạng thái sẽ thay đổi thành “bị từ chối/bị từ chối”.
- Nếu lỗi không bị từ chối thì bước tiếp theo là kiểm tra xem lỗi đó có nằm trong phạm vi không. Giả sử chúng ta có một tính năng khác – tính năng email của cùng một ứng dụng và bạn sẽ thấy rằng nó có lỗi. Nhưng nó nằm ngoài phạm vi của phiên bản ứng dụng này, trạng thái của lỗi có thể thay đổi thành “hoãn/hoãn”.
- Tiếp theo, quản trị viên cần xác minh xem có bất kỳ lỗi tương tự nào đã được tìm thấy trước đó hay không. Nếu nó đã tồn tại, lỗi này sẽ được đánh dấu là “trùng lặp/trùng lặp”.
- Nếu không có vấn đề gì trong khi nhà phát triển sửa lỗi, hãy chuyển lỗi sang trạng thái “đang xử lý/đang xử lý”.
- Khi mã được sửa. Lỗi sẽ được gán trạng thái “Đã sửa/Đã sửa”
- Tiếp theo, người kiểm tra sẽ kiểm tra lại mã đã sửa đổi. Nếu trường hợp thử nghiệm liên quan vượt qua, hãy đóng lỗi hoặc thay đổi trạng thái thành “Đã đóng”. Nếu trường hợp thử nghiệm lại thất bại, hãy mở lại/mở lại lỗi và gửi lại cho nhà phát triển
- Hãy xem xét một tình huống trong lần phát hành đầu tiên, một lỗi đã được tìm thấy trong đơn đặt hàng fax, lỗi này đã được sửa và chỉ định là đã đóng. Trong lần nâng cấp thứ hai, lỗi tương tự lại xuất hiện. Trong trường hợp này, lỗi đã đóng sẽ được mở lại.
Ở trên là toàn bộ vòng đời của lỗi, vui lòng xem liên kết bên dưới để xem video giải thích
Link tham khảo: https://www.guru99.com/defect-life-cycle.html
