Vòng đời của bug trong kiểm thử phần mềm là tập hợp các trạng thái cụ thể mà mỗi một bug sẽ trải qua trong toàn bộ vòng đời của nó.

Mục đích của vòng đời này giúp cho tester và developer - những người chịu trách nhiệm về lỗi cập nhật trạng thái và tiến độ thường xuyên, thông báo tình trạng hiện tại của bug đến những người có nhiệm vụ khác nhau, quy trình sửa lỗi sẽ được nhanh chóng và hiệu quả hơn, và dễ dàng quản lý bug hơn cho đến nó được loại bỏ hoàn toàn trong hệ thống phần mềm.

1. Sơ đồ vòng đời của một Bug

Hình ảnh dưới đây sẽ cho ta thấy tổng quan về vòng đời của một Bug:

1. New : Khi tester thực hiện test, với bất kỳ trường hợp nào không đúng với kết quả mong đợi thì sẽ thực hiện log bug. Lỗi được log lên thì trạng thái đầu tiên của nó sẽ là New

2. Assigned: Sau khi log bug xong thì Team lead (TL) dự án của tester sẽ là người review bug, nếu đúng thì sẽ được assign đến TL của team tương ứng ( FE, BE). Bên cạnh đó thì tùy vào mỗi quy trình quản lý của mỗi dự án khác nhau thì cũng sẽ có cách assign khác, như tester sẽ trực tiếp assign đến TL của đội developer luôn.

3. Open: Lỗi sau khi được log lên bởi tester, thì sẽ được đội Dev kiểm tra lại, phân tích đây có đúng là lỗi hay không, ở đây thì bug có trạng tháng Open. Thông thường TL - người được assign sẽ là người thực hiện bước này. Sau khi phân tích rõ ràng thì TL sẽ là người thực hiện chuyển sang trạng thái tiếp theo của Bug, bao gồm một trong các trạng thái sau:

• Fixed (xem thêm tại no.4)
• Duplicate (xem thêm tại no.10)
• Rejected (xem thêm tại no.11)
• Deferred (xem thêm tại no.12)
• Not a bug (xem thêm tại no.13)

4. Fixed: ở bước này, TL sẽ assign đến member để thực hiện thay đổi code, fix bug đúng theo kết quả mong đợi mà tester đã log trong bug. Sau khi hoàn thiện bug thì developer sẽ chuyển trạng thái của bug sang “Fixed”

5. Pending retest / Resolved : Sau khi bug đã được fix, code mới đã được đẩy lên trên hệ thống, đã sẵn sàng cho tester thực hiện test lại thì bug sẽ được TL của team dev chuyển sang trạng thái “Pending retest” hoặc “Resolved”. Tester cũng có thể nhìn vào trạng thái này để hiểu bug đã hoàn thiện để verify lại.

6. Retest: ở bước này tester sẽ test lại bug và những case liên quan đến bug xem bug đã đúng với mong muốn chưa, và những trường hợp liên quan khác có phát sinh ra bug mới hay không.

7. Verified : Tester sau khi kiểm tra lại lỗi. Nếu không có lỗi nào đượ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 ".

8. Reopen : Trong quá trình kiểm tra, nếu lỗi vẫn còn tồn tại ngay cả sau khi developer đã sửa hoặc bug vẫn chưa được fix đúng với mong muốn. Thì tester sẽ chuyển nó sáng trạng thái “Reopen” và một lần nữa bug sẽ lặp lại vòng đời của nó.

9. Closed: Nếu bug đã không còn tồn tại trong hệ thống thì TL của tester sẽ chuyển nó sang trạng thái “Closed”

10. Duplicate : Một module thường sẽ có nhiều tester cùng thực thi test , vì vậy sẽ không tránh khỏi việc log bug trùng lặp, hoặc 2 trường hợp khác nhau nhưng có cùng có khái niệm về lỗi thì TL của team dev sẽ chuyển trạng thái thành “ Duplicate”

11. Rejected: Sau khi log bug, không có nghĩa tester hoàn toàn đúng, trong một số trường hợp như tester hiểu sai về spec của chức năng, hoặc spec được thay đổi ngay sau đó thì những bug này là bug không hợp lệ. Bug sẽ được chuyển sang trạng thái “Reject”

12. Deferred: Nếu bug hoàn toàn đúng nhưng nó không nằm trong phạm vi release hiện tại, hoặc trong trường hợp bug ở mức độ thấp và thời gian release đang gấp rút thì cũng có thể để lại để fix sau, thì những lỗi như vậy sẽ được đánh dấu là “Deferred’

13. 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".

2. Giải thích về vòng đời của Bug

1. tester tìm thấy lỗi và thực hiện log lỗi
   

2. Gán trạng thái cho bug là New
   

3. Chuyển bug sang TL để phân tích bug
   

4. Tl sẽ xem xét đây có phải là bug hợp lệ hay không
   

5. Trong trường hợp bug không hợp lệ thì trạng thái sẽ là “Rejected”
   

6. Nếu bug không bị loại bỏ thì sẽ xem xét nó có nằm trong phạm vi của lần release lần này hay không. Nếu không nằm trong phạm vi thì nó sẽ chuyển đến trạng thái “deferred “
   

7. Nếu bug nằm trong phạm vi release lần này thì thực hiện kiểm tra xem lỗi có đã được log lên trước đó hay chưa, nếu có rồi thì nó sẽ chuyển sang trạng thái “Duplicate”
   

8. Trong trường hợp lỗi không nằm trong bất kỳ trường hợp nào như trên thì nó sẽ được chuyển đến developer để thực hiện fix bug, trong quá trình fix thì bug sẽ có trạng thái “ In-progress”
   

9. Sau khi code đã được fix. Bug sẽ được chuyển sang trạng tháu “Fixed”
   

10. Sau khi được TL review lại code và đẩy code mới lên trên hệ thống, tester sẽ thưc hiện kiểm tra lại, Nếu không có phát sinh gì trong quá trình re-test thì bug sẽ được closed. Nhưng nếu kiểm tra lại thất bại thì bug sẽ được re-opened và được chuyển lại cho dev để thực hiện kiểm tra ại.
    

11. Một lỗi đã được test và closed trong lần release trước nhưng lại phát hiện xảy ra lại trong phạm vi thực hiện các chức năng cho lần release tiếp theo thì lỗi đã closed sẽ được re-opened trở lại và bắt đầu lại vòng đời của nó.

Ngoài ra chúng ta có thể học hỏi thêm thông video bên dưới, nó sẽ có ví dụ cụ thể giúp chúng ta dễ hình dung hơn: https://www.youtube.com/watch?v=NpDZ2NJmDrE

Dịch và tham khảo tại: https://www.guru99.com/defect-life-cycle.html
https://www.softwaretestinghelp.com/bug-life-cycle/