Log Bug giỏi như một Kỹ sư

Chào mọi người, lại là tui đây. Gumiho :D Hôm nay tui sẽ chia sẻ cho mọi người về kĩ thuật log bug giỏi và siêu giỏi. Hãy đọc, like, share và comment thật nhiều nhé. Arigatou  

Log Bug giỏi như một Kỹ sư

Tester: "Úi bug nhé. Log ngay lên mới được"

Developer: "Ơ ơ bug này là bị gì vậy, đọc chả hiểu gì"

Đây hẳn là những câu chuyện mà ai trong công cuộc làm dev cũng như tester đều gặp phải. Nếu chỉ 1 vài lần thôi thì không sao,  nhưng nếu 1 ngày mà vấp phải thì dù là người điềm đạm đến mấy cũng phải gồng mình lên để cáu thôi nhỉ :D

Vì thế, log bug cũng là 1 kĩ năng vô cùng quan trọng. Vừa giúp mình đỡ tốn thời gian giải thích, cũng vừa giúp dev đỡ phải tốn thời gian để confirm lại.

Vì vậy, hôm nay tui muốn chia sẻ tới toàn bộ anh chị em Tester, 1 số kinh nghiệm xương máu mà tui đúc kết được qua những năm hành nghề trên "mảnh đất" phần mềm nhé.

A. Chắc tui sẽ bỏ qua cái đoạn hỏi "Bug là gì? Log Bug là gì?" nhé :D

B. Nguyên tắc Log Bug

Dưới đây là 1 số nguyên tắc mà Tester nên lưu ý trước khi Log Bug:

  1. Tránh log trùng bug: khi dự án có từ 2 tester trở lên, hãy nhớ teamwork và check lại trước khi log bug lên
  2. Tránh viết gộp nhiều bug nhỏ thành 1 bug lớn: việc viết gộp nhiều bug nhỏ thành bug lớn thường gặp ở các em có ít kinh nghiệm, với những trường hợp bug có liên quan mật thiết với nhau thì mới nên gộp, còn không, hãy tách riêng chúng ra, để việc kiểm soát bug của bạn là tốt nhất
  3. Bug viết phải dễ hiểu, dễ tái hiện: đây chính là vấn đề tui vừa nói ở trên, Tester ít kinh nghiệm thường hay mắc lỗi này, diễn đạt những gì mình hiểu ra văn nên sẽ thường bị mất chữ, dẫn đến sự khó hiểu cho người đọc. Vì vậy việc viết phải thật rõ ràng, phân tách các bước dễ hiểu, để bên developer có thể đọc mà tự tái hiện lại được
  4. Quản lý được bug: việc log bug sẵn đâu log đó, or sẵn đâu bảo đó cũng là 1 vấn đề cần được đưa vào nguyên tắc. Khi tham gia bất kì dự án nào, bạn cần check và quản lý bug lên 1 công cụ, tránh log lên nhiều công cụ dẫn đến việc không thể kiểm soát được bug, từ đó gây ảnh hưởng đến chất lượng dự án
  5. Bằng chứng cụ thể: có những bug bạn chỉ cần ghi các bước tái hiện thôi thì bên developer có thể tái hiện được, nhưng có những bug hơi "khoai" or khá phức tập, ví dụ như bug về UI mà khó diễn đạt bằng lời, thì bạn hãy nên chụp ảnh và khoanh vùng chỗ lỗi, còn phức tạp hơn nữa, hãy quay lại video để có thể diễn tả được 1 cách chân thực nhất nhé.
  6. Bug được tái hiện ít nhất 2-3 lần trước khi quyết định log bug: có những bug rất "dị". Nó còn kiểu "ăn may" nữa cơ :D nên trước khi log bug lên, bạn hãy chắc chắn là tái hiện nó ít nhất 2-3 lần để đảm bảo đó là bug nhé, vì đôi lúc nó bị lỗi là do bạn chưa clear cache or 1 số lý do khách quan nào đó khiến bạn nhầm đó là bug.
  7. Kiểm tra sự xuất hiện của bug trên các module tương tự khác: ví dụ như bạn đang check màn tạo sản phẩm, bạn thấy nó bị lỗi validate ở 1 trường nào đó, bạn log bug lên. Sau đó bạn lại check màn edit sản phẩm, bạn cũng thấy lỗi giống bên màn tạo, bạn log thêm 1 bug mới. Ơ khoan, dừng lại chừng lại 2 giây :D Bạn chỉ cần log 1 bug và note nó ở màn nào là được nhé. Với những bạn ít kinh nghiệm or mới vào nghề sẽ hay gặp phải trường hợp này, vì khi gặp phải rồi bạn sẽ được sự "nhắc nhở" bởi developer để rút kinh nghiệm lần sau đó :D Nói nôm na phía bên dev thì họ sẽ dùng chung các màn này với nhau, nên khi sửa 1 màn thì màn khác cũng sẽ được "ăn" theo, nên chỉ cần log vào 1 bug là được nhé hihi
Làm gì khi dev cãi không phải là bug??

C. Nội dung cần có của 1 thông tin BUG

  • Testcase ID: <Sheet_Name>_<ID>
  • Bug ID: (cái này thì cũng tuỳ nha)
  • Nội dung/ Tiêu đề của BUG: <content>
  • Device: PC | Laptop (MAC, ….)
  • OS Version : 14.4.1
  • Browser: Chrome | Edge |….
  • Các bước tái hiện:
     [Điều kiện tiền đề]
     [Actions/Steps]
  • Kết quả thực tế: <content>
  • Kết quả mong đợi: <content>
  • Priority/ Severity: High/Medium/Low
  • Assignee: <developer>
  • Start Date/ End Date: (cái này thì cũng tuỳ nha)
  • Status: Open/ InProgress/ Resolved/ Deployed/ Closed/ Rejected/Pending…
  • Note:

D. Nguyên tắc đặt tên BUG

  1. Cấu trúc tên BUG
Too much Browser Privacy could impact Security, says Researcher

Web: [Browser][Function] <content>
VD: [Chrome][Login] <content>

Nền tảng platforms là gì? Các nền tảng platforms phổ biến hiện nay

Mobile: [Platform][Browser][Function] <content>
VD: [IOS][Edge][Profile] <content>

2. Nội dung tên BUG

CÔNG THỨC:
(ĐANG) BỊ KHI thao tác gì Ở ĐÂU

HY VỌNG NHỮNG CHIA SẺ TRÊN SẼ ÍT NHIỀU GIÚP MỌI NGƯỜI CẢI THIỆN ĐƯỢC NHỮNG VẤN ĐỀ TRONG VIỆC LOG BUG CỦA MÌNH TRỞ NÊN TỐT HƠN!!! THÂN ÁI :D