Quá trình phát sinh và giải quyết lỗi, hay còn được gọi là vòng đời lỗi (Defect Life Cycle) là chuỗi các trạng thái mà một lỗi trong kiểm thử phần mềm phải trải qua. Mục đích của việc tạo ra một quy trình cho vòng đời lỗi là để dễ dàng quản lý và thay đổi trạng thái của lỗi cho đến khi nó được khắc phục hoàn toàn.
Mục tiêu chính của người kiểm thử không chỉ là tìm ra lỗi trong phần mềm mà còn là theo dõi lỗi đó cho đến khi nó được khắc phục. Vì vậy, vòng đời của lỗi bắt đầu từ khi người kiểm thử tìm thấy lỗi và kết thúc khi lỗi đó được khắc phục.
1. Sơ đồ vòng đời của lỗi
Mô tả chi tiết các trạng thái của lỗi trong vòng đời
MỚI
Khi người kiểm thử thực hiện test case và kết quả không đúng như kỳ vọng, họ gọi đó là lỗi. Điều này có nghĩa là có sự khác biệt giữa kết quả dự kiến và kết quả thực tế. Lỗi này cần được khắc phục. Tuy nhiên, người kiểm thử không phải là người khắc phục lỗi mà là lập trình viên.
Người kiểm thử sẽ báo cáo lỗi như thế nào? Họ sẽ đến gặp lập trình viên và nói rằng: “Anh ơi, tôi đã tìm thấy một lỗi, hãy khắc phục nó sớm nhé?” Câu trả lời thường là không. Người kiểm thử cần ghi lại lỗi này cho Trưởng nhóm và Trưởng nhóm sẽ giao cho lập trình viên khắc phục lỗi sau khi đã phân tích. (Ở một số công ty, người kiểm thử sẽ giao lỗi trực tiếp cho lập trình viên mà không thông qua Trưởng nhóm).
→ Khi người kiểm thử tìm thấy lỗi, lỗi đó sẽ có trạng thái là MỚI.
MỞ
Lỗi được ghi lại bởi người kiểm thử. Trưởng nhóm cần xác nhận lỗi đó có phải là lỗi không, nếu đúng thì lỗi sẽ có trạng thái MỞ. Các hoạt động cần được thực hiện bởi Trưởng nhóm:
→ Xác nhận lỗi.
TỪ CHỐI
Một lỗi được đánh dấu là TỪ CHỐI khi lỗi đó không hợp lệ. Điều này có nghĩa là đôi khi người kiểm thử có thể hiểu sai chức năng và coi một chức năng là lỗi. Trong trường hợp này, lỗi sẽ bị từ chối sau khi Trưởng nhóm kiểm tra lại.
→ Khi người kiểm thử báo cáo một lỗi nhưng đó lại là một chức năng của ứng dụng, Trưởng nhóm sẽ đánh dấu lỗi đó là TỪ CHỐI.
TRÙNG LẶP
Nếu lỗi là hợp lệ, sau đó Trưởng nhóm sẽ kiểm tra xem lỗi đó đã được ghi lại bởi người khác chưa. Nếu đã có người khác ghi lại lỗi đó, Trưởng nhóm sẽ đánh dấu lỗi đó là TRÙNG LẶP. Nếu lỗi chưa được báo cáo bởi người kiểm thử khác, Trưởng nhóm sẽ tiến hành tìm kiếm lỗi đó trong phạm vi.
Chúng ta biết rằng chúng ta làm việc trong một nhóm. Có khả năng là cùng một phần mềm hoặc cùng một module sẽ được giao cho nhiều hơn một người kiểm thử, trong trường hợp này, lỗi tương tự có thể bị phát hiện bởi nhiều người kiểm thử.
Do đó, Trưởng nhóm cần đảm bảo rằng cùng một lỗi sẽ không được báo cáo 2 lần hoặc nhiều hơn.
→ Nếu cùng một lỗi được báo cáo bởi hai hoặc nhiều người kiểm thử, lỗi được báo cáo sau sẽ được đánh dấu là TRÙNG LẶP.
HOÃN LẠI
Nếu lỗi không bị trùng lặp, nhưng không thuộc về bản phát hành hiện tại, lỗi sẽ được đánh dấu là HOÃN LẠI. Điều này có nghĩa là nếu bạn đang làm theo mô hình Agile và các yêu cầu dự án được chia thành các sprint, ví dụ sprint 1, sprint 2, …, sprint 10. Hiện tại đang ở sprint 1, nhưng bạn tìm thấy một lỗi liên quan đến tính năng sẽ được phát triển ở sprint 2, thì lỗi đó sẽ được đánh dấu là HOÃN LẠI. Lỗi HOÃN LẠI là một lỗi, nhưng nó sẽ được khắc phục trong bản phát hành tương lai.
→ Khi một lỗi là một phần của bản phát hành tương lai, nó sẽ được đánh dấu là HOÃN LẠI.
ĐƯỢC GÁN CHO LẬP TRÌNH VIÊN
Khi lỗi được tìm thấy là hợp lệ, duy nhất và thuộc về bản phát hành hiện tại, Trưởng nhóm sẽ giao lỗi đó cho lập trình viên.
SỬA XONG
Khi nhận được lỗi từ Trưởng nhóm, lập trình viên sẽ tiến hành thay đổi để sửa lỗi theo yêu cầu, sau đó chuyển lại cho người kiểm thử kiểm tra lại lỗi đó.
KIỂM THỬ LẠI
Sau khi sửa lỗi xong và tính năng đã sẵn sàng để kiểm thử, người kiểm thử sẽ tiến hành kiểm thử lại các trường hợp lỗi và xác minh lỗi đã được sửa chữa đúng hay chưa. Việc này được gọi là KIỂM THỬ LẠI.
ĐÓNG LẠI
Khi lỗi đã được khắc phục, đã được kiểm thử lại và chạy đúng theo yêu cầu, người kiểm thử sẽ đánh dấu lỗi đó là ĐÓNG LẠI.
MỞ LẠI
Có 2 tình huống mà chúng ta cần mở lại lỗi:
- Tình huống 1: Khi lập trình viên sửa lỗi và người kiểm thử kiểm tra lại lỗi đó, nhưng sau khi kiểm thử lại, lỗi vẫn xảy ra, người kiểm thử sẽ MỞ LẠI lỗi và giao lại cho lập trình viên.
- Tình huống 2: Có trường hợp lỗi đã được khắc phục và được đóng lại. Trong trường hợp này, người kiểm thử cần MỞ LẠI lỗi đã đóng và giao lại cho lập trình viên.
2. Giải thích về quá trình phát sinh và giải quyết lỗi/defect
- Người kiểm thử tìm thấy lỗi/defect.
- Đặt trạng thái cho lỗi: Mới.
- Chuyển lỗi cho Quản lý dự án để phân tích.
- Quản lý dự án quyết định xem lỗi có hợp lệ không.
- Nếu lỗi không hợp lệ, trạng thái sẽ chuyển thành “Từ chối”.
- Nếu lỗi không bị từ chối, bước tiếp theo là kiểm tra xem lỗi có nằm trong phạm vi không. Ví dụ, có một chức năng khác – chức năng gửi fax cho cùng một ứng dụng và bạn phát hiện một vấn đề với điều đó. Tuy nhiên, nó không nằm trong phạm vi của phiên bản hiện tại của ứng dụng, trạng thái của lỗi đó có thể chuyển thành “Hoãn lại”.
- Tiếp theo, người quản lý cần xác minh xem đã có lỗi tương tự nào được tìm ra trước đó hay chưa. Nếu đã có, lỗi này được chuyển thành “Trùng lặp”.
- Nếu không có vấn đề gì xảy ra trong quá trình lập trình viên sửa lỗi, lỗi này được chuyển sang trạng thái “Đang tiến hành”.
- Khi mã đã được sửa, lỗi được gán trạng thái “Đã sửa xong”.
- Tiếp theo, người kiểm thử sẽ kiểm tra lại phần mã đã được sửa. Nếu tất cả các trường hợp kiểm thử liên quan đều qua, lỗi đó sẽ được đóng hoặc chuyển sang trạng thái “Đóng”. Nếu các trường hợp kiểm thử thất bại lần nữa, lỗi được MỞ LẠI và chuyển giao cho lập trình viên.
- Hãy xem xét một tình huống trong phiên bản phát hành đầu tiên, một lỗi được tìm thấy và đã được sửa và đóng. Trong phiên bả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, lỗi đã được đóng sẽ được mở lại.
Bài dịch và tham khảo từ nguồn https://www.guru99.com/defect-life-cycle.html và software-testing-tutorials-automation.com/2016/12/bug-life-cycle.html