Vòng đời của Bug bạn phải hiểu

944

26-05-2018

Vòng đời của bug là từ lúc tester tìm thấy bug đó đến khi close nó. Hãy cùng tìm hiểu kĩ hơn về sơ đồ vòng đời của bug trong bài viết dưới đây cùng Bizfly Cloud nhé!

Mục tiêu chính của tester không chỉ là tìm ra bug/ khiếm khuyết của phần mềm mà còn phải theo dõi lỗi đó cho đến khi close nó. Vì vậy, vòng đời của bug là từ lúc tester tìm thấy bug đó đến khi close nó.

Dưới đây là sơ đồ vòng đời của bug:

Sơ đồ vòng đời của bug

Mô tả chi tiết từng trạng thái của Bug:

NEW (Mới)

Khi tester thực thi test case và đầu ra của test case đó không đúng như kết quả mong đợi, thì họ sẽ gọi đó là bug. Nghĩa là có sự khác biệt giữa kết quả mong đợi và kết quả thực tế thì gọi là bug. Do đó bug này cần phải được fix. Nhưng tester không phải là người fix bug mà là lập trình viên sẽ fix nó.

Tester sẽ báo bug này như thế nào? Họ sẽ đi đến chỗ của lập trình viên và nói rằng: Này anh, tôi đã tìm thấy 1 bug, hãy fix nó sớm nhé? Câu trả lời là không. Tester cần log bug này lên cho Team Lead và Team Lead sẽ assign cho developer fix bug này sau khi đã phân tích. (Có nhiều công ty, tester sẽ trực tiếp gán bug cho developer chứ không thông qua Team Lead).

→ Khi tester tìm thấy bug thì nó sẽ có trạng thái là NEW.

OPEN

Lỗi được log lên bởi tester. Team lead cần xác minh lại bug đó xem có đúng là bug hay không, thì bug có trạng thái OPEN. Sơ đồ dưới đây là những hoạt động cần được thực hiện bởi team lead:

Hoạt động cần được thực hiện bởi team lead

REJECTED (Từ chối)

Một bug được đánh dấu là Rejected khi bug đó không hợp lệ. Nghĩa là thỉnh thoảng tester có thể hiểu sai chức năng và có thể đánh dấu chức năng là bug. Trong trường hợp này, bug sẽ bị reject sau khi team lead kiểm tra lại.

→ Khi tester báo cáo một bug nhưng nó lại là chức năng của ứng dụng thì team lead sẽ đánh dấu nó là REJECTED (H1).

DUPLICATE (Trùng lặp)

Bug Life Cycle

Nếu bug là hợp lệ, thì sau đó team lead sẽ kiểm tra xem lỗi đó đã được log người khác hay chưa. Nếu đã có người khác log nó, thì team lead sẽ đánh dấu nó là DUPLICATE. Còn nếu nó chưa được báo cáo bởi tester khác thì team lead sẽ thực hiện tìm kiếm nó trong scope.

Như chúng ta đã biết, chúng ta làm việc trong một team. Có khả năng rằng cùng một phần mềm hoặc một module sẽ được gán cho nhiều hơn một tester, trong trường hợp này lỗi tương tự có thể được tìm thấy bởi nhiều tester.

Vì vậy, team lead 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 thế.

→ Nếu cùng một bug dược báo cáo bởi hai hay nhiều tester thì lỗi được báo cáo sau sẽ được đánh dấu là DUPLICATE.

DEFERRED (Hoãn lại)

Nếu bug không bị duplicate, nhưng lại không thuộc bản release hiện tại thì sẽ được đánh dấu là Deferred. Nghĩa là giả sử bạn đang làm theo mô hình agile, và họ chia yêu cầu dự án thành các sprint, ví dụ chia thành 10 sprint: sprint 1, sprint 2, ..., sprint 10. Hiện tại đang ở sprint 1, nhưng bug bạn tìm thấy lại có liên quan đến tính năng sẽ được phát triển ở sprint 2, thì bug này sẽ được đánh dấu là DEFERRED. Deferred bug là một bug, nhưng nó sẽ được sửa chữa trong bản release tương lai.

→ Khi một bug là một phần của bản release tương lai thì nó sẽ được đánh dấu là DEFERRED.

ASSIGNED (Gán bug)

Khi bug tìm thấy là hợp lệ, duy nhất và thuộc bản release hiện tại, thì team lead sẽ gán bug đó cho developer.

FIX

Khi nhận được bug từ team lead, developer sẽ thực hiện thay đổi để fix bug cho đúng với yêu cầu, và đẩy lại cho tester kiểm tra lại lỗi đó.

RE-TESTING (Test lại)

Sau khi fix xong bug, và chức năng/tính năng đã sẵn sàng để kiểm thử, thì tester sẽ thực hiện lại những test case lỗi và xác minh lại xem nó đã chạy đúng hay chưa. Việc này gọi là RE-TESTING.

CLOSED

Khi bug đã được fix, đã được kiểm thử lại và nó chạy đúng như yêu cầu thì tester sẽ đánh dấu nó là CLOSED.

RE-OPENED

Có 2 tình huống mà chúng ta cần phải re-open lại bug:

- Tình huống 1: Khi developer fix bug và tester thực hiện test lại nó, nhưng sau khi re-test, bug đó vẫn xảy ra thì tester sẽ RE-OPEN lại bug và assign cho developer.

- Tình huống 2: Có trường hợp lỗi đã fix và được close xuất hiện lại. Trong trường hợp này, tester cần RE-OPEN lại bug đã close và gán nó cho developer.

Trên đây là tất cả của vòng đời của bug. Bạn có thể tìm thấy nhiều mô hình vòng đời của bug khác nhau từ những nguồn khác nhau, tuy nhiên có thể thấy sơ đồ đã được trình bày phía trên khá là dễ hiểu cho tất cả mọi người. Cảm ơn các bạn đã theo dõi!

Link bài gốc: software-testing-tutorials-automation.com/2016/12/bug-life-cycle.html

Nguồn: Bizfly Cloud chia sẻ