Bug & Cách report bug hiệu quả

Hiệu quả, thử suy nghĩ xem như thế nào thì được cho là hiệu quả?

• Là làm sao nêu lên được vấn đề đang gặp phải: tình trạng, mong muốn
• Là làm sao để tất cả mọi người cùng hiểu được vấn đề mà QA đang muốn nói
• Là làm sao để giải quyết được “của nợ” đấy một cách nhanh gọn, chính xác nhất

Hầy, nhiều chuyện cần bàn lắm đây

1. Bug & Report Bug

Trước tiên, để mọi người dễ hình dung, thì tôi xin tự giới thiệu, tôi là QA – tất nhiên rồi, không thể là DEV, vì các bạn ấy chắc không có hứng thú trong việc chia sẻ về việc report bug rồi, các bạn ấy chỉ hứng thú với việc fix bug thôi. Tôi cũng không thể là PO, vì các cụ PO quá bận: từ giao tiếp với khách hàng, viết tài liệu, sát sao team… vân vân và mây mây, cho nên là các cụ ấy cũng không rảnh viết những cái này. Tóm lại, tôi là QA.

Thứ hai, chưa nhắc đến keyword quan trọng nhất của bài viết này: BUG. Bug là gì thì chắc không cần định nghĩa, người người nhà nhà đều có thể hình dung nó là cái gì và nguy hiểm ra sao. Đang làm việc mà nghe loáng thoáng “Có Bug” là tự dưng cảm thấy nhột và hoang mang. Hic

Thứ ba, Report bug: việc làm thường xuyên của QA, ngày ngày tháng tháng miệt mài tìm bug và report bug. Công việc kiếm cơm mà lại, không chăm kiếm cơm thì có mà ăn cám. Bug phát hiện càng sớm, fix càng dễ, càng đỡ tốn nhiều thứ, đặc biệt là “Xiền”. Tìm được bug đã gian nan, report bug sao cho dễ hiểu, dễ tái hiện cũng khoai không kém.

Có một vài mục mà mình nghĩ là cần thiết và quan trọng đối với việc report 1 em bug:

• Summary: Ngắn gọn, xúc tích, dễ hiểu
• Type: Phân loại vấn đề: là lỗi hay cải tiến hay chỉ đơn giản theo DEV đấy là tính năng
• Environment: Để phân loại môi trường xảy ra bug
• Description
  • Precondition: Chuẩn bị abc…xyz để bắt đầu thực hiện
  • Steps: Cụ thể các bước thực hiện
  • Actual: Thực tế kết quả hiện tại đang là như thế nào
  • Expect: Kết quả đúng cho trường hợp này là như thế nào
• Version: Phiên bản phát hiện bug
• Attached files: Bằng chứng (ảnh, video) – “Một bằng chứng bằng cả ngàn lời nói”

Tóm lại, mình nghĩ, để report bug được hiệu quả thì cần chú ý một số điểm sau:

• Có thể tái tạo lại được bởi developer
• Ngắn ngọn, tiết kiệm thời gian
• Đầy đủ thông tin, hình ảnh
• Độc lập, có thể theo dõi được từng lỗi

 2. Cách để DEV vui vẻ fix bug (nhờ vả, nịnh nọt, dụ dỗ, quát nạt, mách PO)

Phát hiện ra bug, QA phấn khởi bao nhiêu thì DEV sẽ ủ rũ bấy nhiêu. Tại sao QA lại phấn khởi à? Vì là nghề mà, hì hục test ngày đêm mà không phát hiện ra bug nào thì liệu có phải là phần mềm quá “perfect” không? KHÔNG, chỉ có thể là do QA quá “Gà mờ” mà thôi, không có cái hệ thống/phần mềm nào mà không có lỗi cả, cho nên test mãi, test hoài, cuối cùng cũng thấy 1 em bug, cho dù là sai text thôi, thì cũng phấn khởi ra mặt. Nói đi thì cũng phải nói lại, cái mà mình (DEV) tốn bao nhiêu noron thần kinh để làm ra, mà tự dưng lại bị người khác soi ra lỗi, thì “cảm giác lúc ấy sẽ ra sao?” Tất nhiên là chả dễ chịu tí nào, không khóc vì ấm ức là may lắm rồi. Hơ hơ. Thế cho nên “quan trong phải là thần thái”

Khi gặp 1 cái gì đó, cho là Bug đi, thì hay có mấy viễn cảnh có thể xảy ra như sau:

Cảnh 1(khung cảnh bình yên phi thực tế)

• QA: Phát hiện thấy 1 em (cho là Bug) âm thầm report lên công cụ quản lý lỗi (Jira, Mantis, Redmine, Google spreadsheet…) Sau đó nhỏ nhẹ thông báo: “Có bug, mình vừa report bug, các bạn DEV vào xem đi nhé”
• DEV: Lên xem bug gì, mặt mũi ra sao, thấy đúng thì gật gù fix rồi chuyển trạng thái, chờ QA test lại. Nếu thấy không phải thì nhẹ nhàng comment: “…….” Rồi sau đó ới lại: “Bạn ơi xem lại đi nhé, hình như không phải bug”

Cảnh 2 (Một góc chợ)

• QA: Ôi dồi ôi, lỗi kìa, lêu lêu, ra mà xem này
• DEV: Lỗi gì, đâu đâu, ai bảo lỗi, vớ vẩn, đấy là do người dùng cố tình làm cho nó sai đấy chứ !!
• QA: Liên thiên, fix đi, code lởm rồi lại còn lắm chuyện
• DEV: Chê chứ gì, giỏi thì đi mà tự fix
• QA: Mách PO
• PO: Gì thế, đau đầu quá, thôi cả team vào phòng họp bàn tiếp

Cảnh 3 (Tình thương mến thương – Khuyến cáo nên dùng)

• QA: Có bug
• DEV: Đâu, để xem lại…. Ờ, bug thật, nhưng cái này khó quá, research lâu đấy…Hay thôi, tip trick nhá
• QA: Thôi không, làm người ai làm thế, cố đi, chiều mua cho cốc trà sữa
• DEV: Ờ…

Trong thực tế sẽ còn n viễn cảnh khác nhau về cách làm việc trong cùng team, về thái độ của mọi người trước một vấn đề nào đó. Trong giới IT có câu nói là “QA  là kẻ thù của DEV” – Chuẩn luôn, chuyên gia đi soi mói, bắt bẻ, bới lông tìm vết mà lại không “cắn” nhau vài lần thì có mà trời sập. Nhưng mà “cho đi cái gì, nhận lại cái nấy” thế cho nên là cứ củ từ mà nói chuyện với nhau, từ từ rồi khoai sẽ nhừ, đừng sồn sồn như cồn gặp lửa thì có mà hỏng bét,hỏng bét.

Là QA thì đừng bao giờ quên châm ngôn:

                   “Bình tĩnh, tự tin, không cay cú

                    Âm thầm, chịu đựng, log bug sau………………..”

3. Bài học rút ra khi gặp Bug

• Xác định chắc chắn đó là bug (thử lại vài lần để kiểm chứng trước khi thông báo)
• Report bug một cách chính xác, đầy đủ, dễ hiểu
• Thái độ phải luôn nhã nhặn, tử tế như hoa hậu thân thiện (mặc dù lúc đấy bạn đang sôi như cái nồi cơm điện), để tránh gây ức chế, xích mích nội bộ
• Kiểm tra lại thật kĩ kết quả sau khi Dev nói là: “xong rồi đấy” – Quan trọng nhất là không được tin lời DEV nói, hãy tự mình kiểm chứng
• Nếu đến lúc release rồi mà vẫn còn có Bug, thì hãy nấp sau lưng PO, vì khách hàng không biết bạn là ai để mà mắng đâu. HAHA
• Hãy yêu thương, trân trọng bug, nếu chúng ta tỏ ra ghét bỏ, hắt hủi chúng, thì chúng sẽ buồn và sẽ kéo đến ngày càng đông hơn đấy.

P/s: Thần chú:

                  “Không được đánh DEV

                                    Không được đánh DEV

                                                      Không……được……đánh……DEV…..”

Nguồn: labs.flinters.vn