Vòng đời của Bug/Defect trong Kiểm thử phần mềm

Trong kiểm thử phần mềm chắc hẳn các bạn Tester phải làm một công việc cơ bản nhất là bắt Bug. Thế Bug ở đây nó có những trạng thái như thế nào hay còn gọi là vòng đời của Bug khi mà Tester note lại cho team để các anh bạn Dev hiểu rõ về nó và xử lý theo thứ tự cho phù hợp.

Bài viết này Anh Tester sẽ giới thiệu cho bạn vòng đời của Bug hay trạng thái của các phần lỗi mà phần mềm còn thiếu sót.

Vòng đời của bug/defect là gì?

Bug Life Cycle hoặc Defect Life Cycle là tập hợp các trạng thái cụ thể mà Bug trải qua trong toàn bộ vòng đời của nó. Mục đích tạo ra quy trình cho một vòng đời bug/defect là để những người chịu trách nhiệm cho bug/defect đó dễ dàng quản lý và thay đổi trạng thái cho đến khi bug/defect được loại bỏ hoàn toàn khỏi hệ thống.

Các trạng thái của Bug

Các trạng thái của một bug/defect thường sẽ thay đổi tùy từng dự án. Dưới đây là sơ đồ vòng đời của một bug/defect, bao gồm tất cả các trạng thái có thể:

1. New: Khi một lỗi mới được ghi lại và đăng lần đầu tiên. Nó được gán một trạng thái là “New”
2. Assigned: Một khi bug đã được đăng bởi tester thì test leader sẽ phê duyệt lỗi và chuyển giao lỗi cho nhóm phát triển
3. Open: Dev bắt đầu phân tích và thực hiện sửa lỗi. Cũng có khả năng vấn đề có vẻ không phù hợp, trong trường hợp đó thì Dev có thể chuyển vấn đề sang bốn trạng thái sau dựa trên các lý do cụ thể:
   – Duplicate: 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 được thay đổi thành “Duplicate/trùng lặp”.
   – Rejected: Nếu dev cảm thấy lỗi không phải là khiếm khuyết thực sự thì nó sẽ thay đổi lỗi thành “Rejected/Loại bỏ”.
   – Deferred: Nếu lỗi hiện tại không phải là ưu tiên chính và nếu dự kiến sẽ được sửa trong bản phát hành tiếp theo, thì trạng thái “Deferred/Trì hoãn” được gán cho các lỗi đó
   – Not a bug: 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à “Not a bug/Không phải là lỗi”.
4. Fixed: Khi Dev hiện đã sửa xong lỗi bằng cách sửa code và đã xác nhận là sửa xong, bug có thể được chuyển sang trạng thái “Fixed/Đã sửa”.
5. Pending Retest: Sau khi sửa lỗi, dev bàn giao lại bug cho bên tester. Vì quá trình kiểm thử vẫn đang được diễn ra bởi các tester nên trạng thái được chỉ định là “”pending retest/kiểm tra lại đang chờ xử lý”.
6. 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”.
7. Verified: Tester kiểm tra lại lỗi sau khi dev đã fixed. Nếu không có lỗi được phát hiện trong phần mềm, thì lỗi đã được sửa và trạng thái được gán là “Verified/đã được xác minh”.
8. Reopen: Nếu lỗi vẫn tồn tại ngay cả sau khi dev đã sửa lỗi, tester sẽ thay đổi trạng thái thành “Reopen/mở lại”. Bug 1 lần nữa quay lại chu kỳ mới.
9. Closed: Nếu lỗi không còn tồn tại thì tester sẽ gán trạng thái “Closed/Đã đóng”.

You need to login in order to like this post: click here