Vòng đời lỗi hoặc vòng đời lỗi là một tập hợp các trạng thái cụ thể mà một lỗi sẽ trải qua trong toàn bộ 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à để những 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 xóa hoàn toàn khỏi hệ thống.
Mục tiêu chính của người kiểm tra không chỉ là tìm ra lỗi / lỗi phần mềm mà còn theo dõi lỗi cho đến khi nó được đóng lại. do đó, vòng đời của lỗi là từ khi người đánh giá gặp lỗi cho đến khi đóng lại.
1. sơ đồ vòng đời của lỗi
Sơ đồ vòng đời của bug
mô tả chi tiết từng trạng thái của lỗi trong suốt vòng đời
mới (mới)
Khi người thử nghiệm thực hiện một trường hợp thử nghiệm và kết quả của trường hợp thử nghiệm đó không như mong đợi, họ sẽ gọi đó là lỗi. nghĩa là có sự khác biệt giữa kết quả mong đợi và kết quả thực tế được gọi là lỗi. vì vậy lỗi này cần được khắc phục. nhưng không phải người kiểm tra sửa lỗi mà chính là lập trình viên sẽ sửa lỗi đó.
người thử nghiệm sẽ báo cáo lỗi này như thế nào? Họ sẽ đến gặp nhà phát triển và nói, này, tôi đã tìm thấy một lỗi, hãy sửa nó sớm, được không? câu trả lời là không. người kiểm tra nên ghi lại lỗi này cho trưởng nhóm và trưởng nhóm sẽ chỉ định nhà phát triển sửa lỗi này sau khi phân tích. (có nhiều công ty, người kiểm tra sẽ chỉ định lỗi trực tiếp cho nhà phát triển, không thông qua trưởng nhóm).
→ khi người kiểm tra tìm thấy lỗi, nó sẽ có trạng thái mới.
mở
Lỗi ghi nhật ký của người đánh giá. trưởng nhóm cần kiểm tra bug xem có phải bug hay không, khi đó bug có trạng thái mở. Sơ đồ sau đây cho thấy các hoạt động được thực hiện bởi trưởng nhóm:
các hoạt động do trưởng nhóm thực hiện
bị từ chối
một lỗi được đánh dấu là bị từ chối khi lỗi đó không hợp lệ. nghĩa là đôi khi người kiểm tra có thể hiểu sai chức năng và có thể đánh dấu chức năng đó là lỗi. trong trường hợp này, lỗi sẽ bị loại sau khi trưởng nhóm kiểm tra lại.
→ khi người kiểm tra báo cáo lỗi nhưng đó là một chức năng của ứng dụng, trưởng nhóm sẽ đánh dấu là bị từ chối (h1).
trùng lặp (trùng lặp)
Nếu lỗi hợp lệ, trưởng nhóm sẽ kiểm tra xem có ai khác đã ghi lại lỗi hay không. nếu người khác đã đăng ký nó, trưởng nhóm sẽ đánh dấu nó là một bản sao. và nếu những người thử nghiệm khác chưa báo cáo thì trưởng nhóm sẽ tìm kiếm trong phạm vi.
Như tất cả chúng ta đều biết, chúng tôi làm việc như một nhóm. Có khả năng cùng một phần mềm hoặc mô-đun được chỉ định cho nhiều người thử nghiệm, trong trường hợp đó, nhiều người thử nghiệm có thể tìm thấy cùng một lỗi.
do đó, trưởng nhóm phải đảm bảo rằng cùng một lỗi không được báo cáo hai lần trở lên.
→ nếu hai hoặc nhiều người kiểm tra báo cáo cùng một lỗi, lỗi được báo cáo cuối cùng sẽ được đánh dấu là trùng lặp.
hoãn lại (hoãn lại)
nếu lỗi không phải là bản sao, nhưng không có trong phiên bản hiện tại, nó sẽ được đánh dấu là bị hoãn lại. có nghĩa là giả sử bạn đang theo một mô hình nhanh nhẹn và họ chia yêu cầu dự án thành các lần chạy nước rút, ví dụ: chia thành 10 lần chạy nước rút: sprint 1, sprint 2, …, sprint 10. Hiện đang ở sprint 1, nhưng lỗi tìm thấy có liên quan đến một tính năng sẽ được phát triển trong sprint 2, nó sẽ được đánh dấu là hoãn lại. lỗi hoãn lại là một lỗi, nhưng sẽ được sửa trong bản phát hành trong tương lai.
→ khi một lỗi là một phần của bản phát hành trong tương lai, lỗi đó sẽ được đánh dấu là bị hoãn lại.
được chỉ định (lỗi chuyển nhượng)
khi lỗi được tìm thấy là hợp lệ, duy nhất và thuộc phiên bản hiện tại, trưởng nhóm sẽ chỉ định lỗi cho nhà phát triển.
sửa chữa
Khi nhận được lỗi từ trưởng nhóm, nhà phát triển sẽ thực hiện các thay đổi để sửa lỗi theo yêu cầu và gửi lại cho người thử nghiệm để xác minh lại.
kiểm tra lại
Sau khi lỗi được sửa và chức năng / tính năng đã sẵn sàng để thử nghiệm, người thử nghiệm sẽ chạy lại các trường hợp thử nghiệm bị lỗi và kiểm tra xem nó có đang chạy chính xác hay không. điều này được gọi là kiểm tra lại.
đã đóng cửa
Khi lỗi đã được sửa, kiểm tra lại và chạy theo yêu cầu, người kiểm tra sẽ đánh dấu lỗi là đã đóng.
đã mở lại
Có 2 tình huống mà chúng tôi cần mở lại lỗi:
-
tình huống 1: Khi nhà phát triển sửa lỗi và người kiểm tra thử lại lỗi đó, nhưng sau khi kiểm tra lại lỗi vẫn xảy ra, người kiểm tra sẽ mở lại lỗi và gán nó cho nhà phát triển.
Tình huống 2: Có một trường hợp lỗi đã được sửa và đóng lại. trong trường hợp này, người kiểm tra nên mở lại lỗi đã đóng và gán nó cho nhà phát triển.
2. giải thích về vòng đời lỗi / lỗi
- người kiểm tra đã tìm thấy lỗi / lỗi
- chỉ định trạng thái của lỗi: mới / mới
- gửi lỗi cho người quản lý dự án để phân tích
- quản trị viên 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 “bị từ chối / bị từ chối”.
- nếu lỗi không bị từ chối, bước tiếp theo là kiểm tra xem nó có nằm trong phạm vi không. giả sử chúng tôi có một tính năng khác – tính năng email cho cùng một ứng dụng và bạn thấy vấn đề với điều đó. nhưng nó không nằm trong phạm vi của phiên bản ứng dụng này, trạng thái lỗi có thể chuyển thành “hoãn / hoãn lại”.
- Tiếp theo, quản trị viên cần kiểm tra lỗi. Có điều gì tương tự đã được tìm thấy trước đây không? nếu nó đã tồn tại, lỗi này sẽ thay đổi trạng thái thành “sao chép / nhân bản”.
- nếu không có vấn đề gì phát sinh trong khi nhà phát triển sửa lỗi, thì lỗi sẽ chuyển sang trạng thái “trong”. – tiến trình / đang xử lý “.
- khi mã được sửa. lỗi sẽ được chỉ định trạng thái” đã sửa / đã sửa “
- sau đó người kiểm tra sẽ kiểm tra lại mã có vừa được sửa. nếu các trường hợp thử nghiệm có liên quan vượt qua, lỗi đã đóng hoặc trạng thái chuyển thành “đã đóng”. nếu các trường hợp thử nghiệm không thành công một lần nữa, lỗi sẽ được mở lại / mở lại và được chuyển lại cho nhà phát triển
- Hãy xem xét tình huống trong phiên bản đầu tiên, một lỗi được tìm thấy để bản fax được sửa và chỉ định trạng thái đóng. Trong bản cập nhật 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 sẽ được mở lại và đóng lại.
bản dịch và tài liệu tham khảo từ https://www.guru99.com/defect-life-cycle.html và software-testing-tutorials-automation.com/2016/12/bug-life-cycle.html
