Bug Logging

Duy Văn | 23/12/2024

Log a Bug
Defect Life Cycle
Bug Priority and Severity

Sau khi đã có Low Level Test Case, chúng ta sẽ tiến đến bước Test Execution, tại đây chúng ta sẽ chạy test case. Mục tiêu của việc test chính là tìm ra lỗi, vậy thì ngay sau khi chạy test case, việc của chúng ta là log bug.

Log a Bug

Đầu tiên, trước mắt của tester là một test case đã fail, vậy thì việc của tester chính là trước hết xác định xem test case fail là do đâu. Ở đây chúng ta đang làm manual, tức là nếu tester quan sát được rằng những gì mình đang thấy không như Expected Result, thì chúng ta sẽ log bug.

Thực tế thì cũng cần phải xem lại một số yếu tố trong design và xem lại các bước thực hiện của test case, một ví dụ điển hình là việc xuất hiện prompt hoặc Modal hỏi xác nhận, cần ấn thêm Agree hay gì đấy. Hoặc một ví dụ nữa là khi tính năng chống spam hay DDOS được đưa vào, sẽ ngẫu nhiên xuất hiện captcha, tester cần phải linh động trong việc ứng phó với tình huống Steps thay đổi.

Vậy giả sử đối với test case này:

Test Case ID	Test Case Title	Test Case Description	Precondition	Steps	Expected Result	Test Data	Priority	Status
TC001	Navigate to login page	Environment : Test Browser: Chrome URL: None	None	1. Open browser and navigate to URL https://127.0.0.1:4000	1. User is navigated to login page	Not applied	P0	New
TC002	User successfully login to the system with username ‘admin’ and password ‘admin’	Environment : Test Browser: Chrome URL: htpps://127.0.0.1:4000	TC001	1. Input username ‘admin’ 2. Input password ‘admin’ 3. Click on login button	1. ‘admin’ is filled for username field 2. ‘admin’ is filled for password field 3. User navigate to account dashboard	Not applied	P0	New

Khi thực hiện test case TC002, sau khi ấn nút Login thì không có gì xảy ra, không chuyển hướng. Vậy đây là bug, chúng ta sẽ log bug.

Bug thì có thể có rất nhiều thông tin, nhưng mình sẽ nêu ra một số thông tin cơ bản nhất mà một bug cần phải có:

Bug ID

Created By

Created When

Bug Title

Bug Description

Steps To Reproduce

Expected Result

Actual Result

Attachment Of Evidence

Severity

Priority

Status

Đây là nếu chúng ta đang log bug bằng speadsheet, ngoài ra nếu tham gia các dòng dự án log bug bằng DevOps, thì các thông tin bên trên vẫn sẽ có nhưng sẽ hiện hữu ở đâu đấy với một dạng khác, ví dụ như DevOps sẽ tự động ghi lại người tạo, ngày tạo, ngày sửa, Hay Evidence sẽ chui vào trong Description.

Cũng cần một lưu ý khi sử dụng template để log bug spreadsheet, đấy là :

Thứ nhất, sử dụng một format chung, template chung giữa các thành viên trong team để đảm bảo tất cả hiểu nhau
Thứ hai, log đủ thông tin cần thiết của bug
Thứ ba, log kịp thời, không được để quên mất bug
Cuối cùng là log với đầy đủ dẫn chứng (evidence) để hỗ trợ dev trong việc reproduce bug và fix bug

Ví dụ, mình sẽ log cái bug đã ví dụ ở trên

Bug ID	Created By	Created When	Bug Title	Bug Description	Steps To Reproduce	Expected Result	Actual Result	Attachment Of Evidence	Severity	Priority	Status
BUG001	Duy Van	23/12/2024	User cannot login to the system with ‘admin’/’admin’ credential	Environment: Test Browser: Chrome URL: htpps://127.0.0.1:4000 Build 001	1. Input username ‘admin’ 2. Input password ‘admin’ 3. Click on login button	1. ‘admin’ is filled for username field 2. ‘admin’ is filled for password field 3. User navigate to account dashboard	1. ‘admin’ is filled for username field 2. ‘admin’ is filled for password field 3. User stuck at login page	Image	High	P0	Reported

Một số lưu ý:

Bug Title thì bạn có thể lấy luôn Title của Test Case nhưng đảo phủ định
Attachment Of Evidence thì có thể là một ảnh hoặc video, tuỳ theo việc ảnh có đủ truyền tải thông tin hay không
Ví dụ, nếu xuất hiện một lỗi về UI, mà nó tĩnh, tức là khi gặp lỗi màn hình sẽ ở nguyên trạng thái, thì bạn có thể dùng ảnh
Hay giả sử như lỗi chỉ xuất hiện thoáng chốc sau đó quay trở lại màn hình trước, thì để log được hành vi này, nên dùng video
Một ví dụ khác là khi xuất hiện một lỗi không phải lúc nào cũng xuất hiện, thì bạn phải cung cấp evidence dạng video để chứng minh hành vi

Defect Life Cycle

Để điền được Status thì phải hiểu rõ về Defect Life Cycle. Tuỳ dòng dự án nhưng thường Defect Life Cycle sẽ có các trạng thái như sau:

%%{init: {'theme': 'base', 'themeVariables': { 'background': '#ffffff' }}}%%
flowchart LR
    rp((Reported)) --accepted--> as((Assigned))
    as --fixed--> fi((Fixed))
    fi --pass_retest--> cl((Closed))
    fi --fail_retest--> ro((Reopened))
    ro --assign_to_dev--> as

Cụ thể

Ban đầu, khi được xác nhận bởi tester là bug là log lên, status sẽ là Reported
Sau đó, bug sẽ được chuyển cho bên dev, bên dev làm việc nội bộ và gán việc cho một dev nào đó, status sẽ là Assigned
Sau khi người dev này sửa xong bug, nó sẽ là Fixed
Tester theo dõi khi bug được sửa xong, nhảy vào làm Retest, nếu bug pass được Retest, thì status sẽ là Closed, nếu không thì sẽ Reopened và đợi gán lại cho dev quay trở lại Assigned

Việc nắm và theo dõi vòng đời của bug rất quan trọng do nó giúp những người liên quan tham gia và thực hiện các đầu việc một cách có khuôn khổ về mặt thời gian. Giả sử như dev sửa xong bug rồi im ỉm, tester không retest kịp thì mọi thứ sẽ dồn ứ lại, rất mệt về sau. Theo dõi kịp thời khi bug được sửa và lao vào retest theo kết hoạch là ổn nhất, tương tự cho dev, bug được log mà không theo dõi, để phải nhắc thì mệt thôi.

Bug Priority and Severity

Đầu tiên, Severity nghĩa là mức độ nghiêm trọng của bug, nó thể hiện ảnh hưởng của bug lên sản phẩm phần mềm. Mức độ nghiêm trọng tuân theo logic nên sẽ được xác định bởi tester:

Critical	Bug làm crash sản phẩm, gây ra mất mát dữ liệu, lộ dữ liệu hay ảnh hưởng đến tính bảo mật của sản phẩm hoặc dữ liệu, không có cách nào vượt qua
High/Major	Bug làm hỏng các tính năng chính, các tính năng lớn, có rất ít hoặc không có cách vượt qua
Medium	Bug làm hỏng các tính năng nhỏ, các tính năng lớn không bị ảnh hưởng và flow vẫn đảm bảo toàn vẹn nhưng những tính năng ngoài lề không hoạt động, có cách vượt qua
Low/Cosmetic	Bug không ảnh hưởng đến tính năng nào mà ảnh hưởng đến UI, UX hoặc liên quan đến hiệu suất, có cách vượt qua

Còn Priority tức là ưu tiên mà một bug cần được sửa, cái này thì không phụ thuộc vào logic mà vào nhu cầu của khách hàng nếu làm outsource, hoặc làm inhouse thì là nhu cầu ucra Product Owner. Priority có thể là, tuỳ dòng dự án, ví dụ:

Urgent Cần phải được sửa trong vòng 1 - 2 ngày
High Cần phải được sửa trong vòng 2 - 4 ngày
Medium Cần phải được sửa trong vòng 3 - 5 ngày
Low Cần phải được sửa trong vòng 6 - 8 ngày

Bên trên chỉ là ví dụ thôi, tuỳ dòng dự án mà có thể có quy chuẩn khác nhau. Tuy nhiên có thể hiểu chung chung là:

Một bug có Priority cao có thể là bug phá hỏng sản phẩm mà còn lại rất dễ gặp, gây thiệt hại kinh tế lớn hay làm mất hình ảnh của chủ thể sở hữu sản phẩm, hay là các bug về an ninh gây lộ dữ liệu khách hàng.
Một bug có Priority thấp là bug không gây ảnh hưởng nhiều đến hoạt động của chủ thể, nó thậm chí có thể là một bug nghiêm trọng gây crash nhưng nếu điều kiện để trigger nó khó xảy ra thì cũng có thể được ưu tiên thấp

Có thể có những bug có độ nghiêm trọng cao nhưng ưu tiên thấp, ví dụ: Một bug có thể gây tràn bộ nhớ của app và làm app crash trên điện thoại nhưng cần phải sử dụng app trong khoảng thời gian dài, bug được tìm thấy khi endurance test, thì bug này có thể được ưu tiên thấp mặc dù nghiêm trọng cao do crash hẳn

Hay một bug có thể có độ nghiêm trọng thấp nhưng ưu tiên cực cao, ví dụ như một app ngân hàng đẩy banner quảng cáo sự kiện nhưng banner lỗi và bị trắng nền, các nút ấn banner vẫn hoạt động. Không có tính năng nào bị ảnh hưởng nhưng lại gây ảnh hưởng đến hoạt động marketing và hình ảnh của ngân hàng, bug này có ưu tiên rất cao