Bug Report là gì? Tiêu chuẩn của một Bug Report chất lượng

Với hầu hết mọi người thì Bug Report có vẻ hơi xa lạ nhưng với những người trong ngành công nghệ thông tin thì đây là một thuật ngữ vô cùng quen thuộc. Hãy cùng Gockhampha.edu.vn.COM tìm hiểu ngay những tiêu chuẩn để đánh giá chất lượng của một Bug Report nhé.

Bạn đang đọc: Bug Report là gì? Tiêu chuẩn của một Bug Report chất lượng

Bug Report là gì?

Bug Report là bản mô tả lỗi xảy ra khi thực thi test phần mềm. Những dev (developer) thì còn gọi vui là log bug hay report bug. Bug Report thường được tester thực hiện trên các phần mềm quản lý.

Lý do cần phải viết Bug Report tốt?

• Để dev có thể tái hiện bug dễ dàng.
• Tỷ lệ bug được fix sẽ cao hơn.
• Đưa ra một sản phẩm chất lượng tốt hơn.
• Nâng cao khả năng teamwork.
• Hạn chế xung đột giữa tester và dev.
• Nâng cao kỹ năng code cho dev.
• Nâng cao kỹ năng của tester.

Tiêu chuẩn đánh giá một Bug Report chất lượng

Cách viết một Bug Report hoàn chỉnh

Tuỳ vào format và công cụ mà tester sử dụng thì cần lưu ý thông tin của một số trường sau để có một Bug Report hoàn chỉnh:

Reporter (Người báo cáo): Tên tester và email.

Product (Tên sản phẩm): Tên sản phẩm mà tester tìm ra bug.

Version (Phiên bản): Phiên bản của sản phẩm (nếu có).

Component (Thành phần): Là module phụ hay chính của sản phẩm.

Platform (Nền tảng): Các nền tảng phần cứng mà tester tìm ra lỗi. Ví dụ: PC, MAC,…

Operating system (Hệ điều hành): Tên các hệ điều hành mà tester tìm ra lỗi. Ví dụ: Windows, Linux, Unix, SunOS, MacOS,…Trong trường hợp bug chỉ xảy ra ở phiên bản cụ thể, tester nên bổ sung thêm phiên bản của hệ điều hành. Ví dụ: Windows NT, Windows 2000, Windows XP,…

Priority (Độ ưu tiên): Khi nào bug nên được fix? Độ ưu tiên thường quy định từ P1 đến P5 theo thứ tự tăng dần.

Severity (Mức độ nghiêm trọng): Mô tả tác động của bug đối với sản phẩm, người dùng. Các loại mức độ nghiêm trọng:

• Blocker: Không thể thực hiện test thêm nữa.
• Critical: Ứng dụng bị crash, mất dữ liệu.
• Major: Thiếu chức năng chính.
• Minor: Thiếu chức năng phụ.
• Trivial: Cải thiện giao diện người dùng.
• Enhancement: Yêu cầu tính năng mới hoặc nâng cấp tính năng của chức năng hiện có.

Status (Trạng thái): trạng thái của bug, ví dụ như:

• New: Bug vừa được test
• Resolved: Bug đã được fix
• Done: Bug đã được tester exe test
• Reopen: Sau khi dev fix, test re-test vẫn còn lỗi, ….

Assign To (Giao cho): Gắn tên của dev vào bug tương ứng nếu tester biết.

URL (Link): Link URL của trang xảy ra lỗi.

Summary (Tóm tắt): Một đoạn tóm tắt ngắn, dưới 60 từ dùng để mô tả về bug. Và đảm bảo rằng phần tóm tắt này mô tả đầy đủ về bug và vị trí xảy ra.

Description (Mô tả): Mô tả chi tiết về bug đang xảy ra. Gồm có:

• Reproduce (Cách tái hiện): Mô tả rõ ràng các bước tái hiện bug.
• Actual result (Kết quả thực tế): Kết quả thực tế của việc chạy các bước tái hiện bug ở trên.
• Expng đúng khi chạy các bước tái hiện bug ở trên.ected result (Kết quả mong muốn): Cách ứng dụng hoạt độ

Những lưu ý cần nắm để viết Bug Report tốt

Chụp lại hình ảnh khi gặp hiện tượng lạ

Khi tester gặp bug hoặc hiện tượng lại thì nên chụp lại ảnh ngay lưu lại để báo cáo sau khi xác nhận bug (tránh được trường hợp bug khó tái hiện).

Xác nhận Bug

• Kiểm tra bug chính xác bằng cách:
  – Xóa bộ nhớ cache (Ctrl +F5)
  – Kiểm tra log server
  – Kiểm tra console log
  – Kiểm tra database
  – Kiểm tra trên module tương tự khác
• Tái hiện bug 3 lần trước khi báo cáo.
• Đảm bảo các bước tái hiện lỗi đầy đủ
• Lưu ý: Nếu lỗi của bạn không thể tái hiện bạn vẫn có thể note lại và sẽ re-test mỗi khi thực hiện test.

Báo cáo lập tức

Tìm hiểu thêm: AirTag là gì? Ưu, nhược điểm và lưu ý khi mua thiết vị AirTag

• Báo cáo ngay khi gặp và đã xác định đó là bug.
• Không chờ viết Bug Report xong hoặc test xong phần đó rồi mới báo cáo.
• Tránh được trường hợp thiếu bug và có thể tái hiện.

Viết tóm tắt lỗi cụ thể

• Mô tả lỗi ngắn gọn.
• Đánh số thứ tự cho các bước.
• Tóm tắt lỗi rõ ràng sẽ giúp dev dễ dàng phân tích lỗi.
• Mục tiêu Bug Report là giúp dev tái hiện để code và test.

Không lạm dụng ngôn ngữ

• Không sử dụng từ ngữ gây tổn thương người đọc.
• Để ý các dùng từ tránh gây hiểu nhầm và mơ hồ.
• Đọc lại tất cả các câu, từ và các bước được dùng trong báo cáo lỗi.

Dùng máy khác để tái hiện lỗi

• Dùng máy thứ ba để tái hiện bug trong trường hợp không thể tái hiện lỗi giống nhau trên máy dev và tester.
• Một module có bug thì các module khác cũng sẽ có bug. Tester có thể sẽ tìm được bug nghiêm trọng hơn ở các module khác.

Công cụ hỗ trợ viết Bug Report

Word/Excel

• Thời gian làm việc của QA trong dự án chủ yếu liên quan tài liệu.
• Dễ dàng thêm/bớt 1 số testcase khi phát sinh thay đổi.
• Thuận tiện đánh số và thống kê testcase.
• Xác nhận testcase đã được test trong một file testcase với số lượng testcase lớn một cách nhanh chóng với Excel.
• Dễ dàng xuất báo cáo trên dữ liệu có sẵn hay tạo dữ liệu test ngẫu nhiên.

Ứng dụng ghi nhớ

>>>>>Xem thêm: 2NE1 profile tiếng Việt | Thông tin, tiểu sử, các thành viên 2NE1

• Ứng dụng ghi nhớ giúp quản lý task tốt hơn trong giai đoạn gấp rút của dự án.
• Ghi chú công việc ở nơi mà bạn có thể xem bất cứ khi nào theo cách dễ dàng nhất có thể.
• Công cụ có thể view được ở nhiều nơi như Google Drive, Google Keep, Evernote, Trello, Microsoft OneNote,…

Ứng dụng chụp màn hình

Khi tester cần chụp lại hiển thị trên toàn bộ màn hình của một trang web dài dằng dặc, hãy tìm đến các addon trên các trình duyệt để có thể chụp toàn bộ màn hình như Snagit, Lightshot,..

Trên đây là những thông tin về Bug Report cho những bạn đang cần. Hy vọng bài viết đem đến những thông tin hữu ích. Chúc các bạn có thể hoàn thiện Bug Report một cách tốt nhất!