Defect Life Cycle hay Bug Life Cycle trong kiểm thử phần mềm

 Defect Life Cycle hay Bug Life Cycle trong kiểm thử phần mềm là tập hợp các trạng thái cụ thể mà lỗi hoặc lỗi phải trải qua trong suốt vòng đời của nó. Mục đích của vòng đời Khiếm khuyết là để dễ dàng điều phối và truyền đạt trạng thái hiện tại của khiếm khuyết thay đổi đối với những người được giao khác nhau và làm cho quá trình sửa lỗi có hệ thống và hiệu quả.

Quy trình làm việc của các trạng thái lỗi

Số lượng trạng thái mà một lỗi trải qua sẽ khác nhau tùy theo từng dự án. Dưới đây là sơ đồ vòng đời, bao gồm tất cả các trạng thái có thể có

• Mới: Khi một lỗi mới được ghi lại và đăng lần đầu tiên. Nó được gán trạng thái là MỚI.
• Đã chỉ định: Sau khi người kiểm tra đăng lỗi, trưởng nhóm kiểm thử sẽ phê duyệt lỗi và giao lỗi cho nhóm nhà phát triển
• Mở : Nhà phát triển bắt đầu phân tích và tiến hành sửa lỗi
• Đã sửa lỗi : Khi nhà phát triển thực hiện thay đổi mã cần thiết và xác minh thay đổi đó, họ có thể đặt trạng thái lỗi là “Đã sửa”.
• Đang chờ kiểm tra lại : Sau khi lỗi được khắc phục, nhà phát triển sẽ đưa ra một mã cụ thể để kiểm tra lại mã cho người kiểm tra. Vì quá trình kiểm thử phần mềm vẫn đang chờ xử lý từ cuối người kiểm tra nên trạng thái được chỉ định là “đang chờ kiểm tra lại”.
• Kiểm tra lại : Người kiểm tra thực hiện kiểm tra lại mã ở giai đoạn này để kiểm tra xem lỗi đã được nhà phát triển sửa hay chưa và thay đổi trạng thái thành “Kiểm tra lại”.

• Đã xác minh : Người kiểm tra sẽ kiểm tra lại lỗi sau khi nhà phát triển đã sửa lỗi. Nếu không phát hiện thấy lỗi nào trong phần mềm thì lỗi đó đã được sửa và trạng thái được chỉ định là “đã xác minh”.
• Mở lại : Nếu lỗi vẫn tồn tại ngay cả sau khi nhà phát triển đã sửa lỗi, người kiểm tra sẽ thay đổi trạng thái thành “đã mở lại”. Một lần nữa lỗi lại trải qua vòng đời.
• Đã đóng : Nếu lỗi không còn tồn tại thì người kiểm tra sẽ gán trạng thái “Đã đóng”. 
• Trùng lặp : Nếu lỗi được lặp lại hai lần hoặc lỗi tương ứng với cùng một khái niệm về lỗi, trạng thái sẽ được thay đổi thành “trùng lặp”.
• Bị từ chối : Nếu nhà phát triển cảm thấy lỗi không phải là lỗi thực sự thì họ sẽ thay đổi lỗi đó thành “bị từ chối”.
• Trì hoãn : Nếu lỗi hiện tại không được ưu tiên hàng đầu và nếu nó được mong đợi sẽ được sửa trong bản phát hành tiếp theo thì trạng thái “Trì hoãn” sẽ được gán cho các 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 thì trạng thái được gán cho lỗi là “Không phải lỗi”.

Giải thích vòng đời lỗi/khiếm khuyết

1. Người kiểm tra tìm thấy lỗi
2. Trạng thái được gán cho lỗi- Mới
3. Một lỗi được chuyển tiếp đến Người quản lý dự án để phân tích
4. Người quản lý dự án quyết định xem lỗi có hợp lệ hay không
5. Ở đây lỗi không hợp lệ - trạng thái được đưa ra là “Bị từ chối”.
6. Vì vậy, người quản lý dự án gán trạng thá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 nó có nằm trong phạm vi hay không. Giả sử chúng ta có một chức năng khác - chức năng email cho cùng một ứng dụng và bạn thấy có vấn đề với chức năng đó. Nhưng nó không phải là một phần của bản phát hành hiện tại khi những lỗi như vậy được chỉ định là trạng thái bị hoãn hoặc bị trì hoãn .
7. Tiếp theo, người quản lý xác minh xem lỗi tương tự có xuất hiện trước đó hay không. Nếu có lỗi sẽ được gán trạng thái trùng lặp .
8. Nếu không, lỗi sẽ được giao cho nhà phát triển, người bắt đầu sửa mã. Trong giai đoạn này, lỗi được gán trạng thái đang tiến hành.
9. Sau khi mã được sửa. Một lỗi được gán trạng thái cố định
10. Tiếp theo, người kiểm tra sẽ kiểm tra lại mã. Trong trường hợp Test Case vượt qua lỗi được đóng lại. Nếu các trường hợp thử nghiệm lại thất bại, lỗi sẽ được mở lại và gán cho nhà phát triển.
11. Hãy xem xét tình huống trong lần phát hành đầu tiên của Đặt chỗ chuyến bay, người ta đã tìm thấy một lỗi trong đơn hàng Fax đã được khắc phục và được gán trạng thái đã đóng. Trong lần nâng cấp thứ hai, lỗi tương tự lại xuất hiện. Trong những trường hợp như vậy, một lỗi đã đóng sẽ được mở lại.

Đó là tất cả về Vòng đời lỗi