Hỏi Đáp

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

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

Đối với hầu hết mọi người Báo cáo lỗi Nghe thì có vẻ hơi xa lạ nhưng với dân 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 tìm hiểu ngay các tiêu chí để đánh giá chất lượng của một Báo cáo lỗi.

Báo cáo lỗi là gì?

Báo cáo lỗi là một mô tả về một lỗi xảy ra khi thực hiện kiểm tra phần mềm. Các nhà phát triển (nhà phát triển) còn được gọi là lỗi đăng nhập hoặc lỗi báo cáo. Bug Report thường do tester thực hiện trên phần mềm quản lý.

Báo cáo lỗi là gì?

Tại sao việc viết một Báo cáo lỗi tốt lại quan trọng?

Lý do để viết Báo cáo lỗi
Lý do để viết Báo cáo lỗi

  • Vì vậy, các nhà phát triển có thể tái tạo các lỗi một cách dễ dàng.
  • Tỷ lệ lỗi được sửa sẽ cao hơn.
  • Cung cấp một sản phẩm chất lượng tốt hơn.
  • Cải thiện tinh thần đồng đội.
  • Hạn chế xung đột giữa người kiểm thử và nhà phát triển.
  • Cải thiện kỹ năng viết mã cho các nhà phát triển.
  • Nâng cao kỹ năng của người kiểm thử.

Tiêu chí để đánh giá một Báo cáo lỗi chất lượng

Báo cáo lỗi chất lượng Báo cáo lỗi xấu
Chứa thông tin lỗi đầy đủ. Thiếu thông tin hoặc không rõ ràng.
Có thể lặp lại. Không thể tái tạo.
Tạo tiền đề cho mối quan hệ giữa dev và tester. Tạo ra tranh cãi và xung đột giữa nhà phát triển và người thử nghiệm.
Các lỗi được khắc phục nhanh chóng. Lỗi không được sửa.

Cách viết một báo cáo lỗi hoàn chỉnh

Cách viết một báo cáo lỗi hoàn chỉnh
Cách viết một báo cáo lỗi hoàn chỉnh

Tùy thuộc vào định dạng và công cụ mà người kiểm tra sử dụng, điều quan trọng là phải lưu ý thông tin sau để có Báo cáo lỗi hoàn chỉnh:

Người báo cáo (PV): Tên và email của người kiểm tra.

Sản phẩm (Tên sản phẩm): Tên của sản phẩm mà người thử nghiệm đã tìm thấy lỗi.

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

Các thành phần (Thành phần): Là mô-đun chính hoặc phụ của sản phẩm.

Nền tảng (Nền tảng): Nền tảng phần cứng mà người kiểm tra tìm thấy lỗi. Ví dụ: PC, MAC, v.v.

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

Quyền ưu tiên (Ưu tiên): Khi nào thì nên sửa lỗi? Mức độ ưu tiên thường được chỉ định từ P1 đến P5 theo thứ tự tăng dần.

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

  • Chặn: Không có thử nghiệm nào khác có thể được thực hiện.
  • Phê bình: Ứng dụng bị treo, mất dữ liệu.
  • Chính: Thiếu chức năng chính.
  • Diễn viên phụ: Thiếu các chức năng phụ.
  • Không đáng kể: Cải thiện giao diện người dùng.
  • Cải tiến: Yêu cầu các tính năng mới hoặc nâng cấp chức năng hiện có.

Trạng thái (Trạng thái): trạng thái của lỗi, ví dụ:

  • Mới: Lỗi vừa được kiểm tra
  • Đã giải quyết: Lỗi đã được sửa
  • Xong: Lỗi đã được kiểm tra bởi người thử nghiệm exe
  • Mở lại: Sau khi dev fix, test lại test vẫn báo lỗi,….

Giao cho (Được gán cho): Đính kèm tên của nhà phát triển với lỗi tương ứng nếu người thử nghiệm biết nó.

URL (Liên kết): URL của trang xảy ra lỗi.

Bản tóm tắt (Tóm tắt): Một bản tóm tắt ngắn, dưới 60 từ, để mô tả lỗi. Và hãy đảm bảo rằng bản tóm tắt này mô tả đầy đủ về lỗi và nơi nó đã xảy ra.

sự mô tả (Mô tả): Mô tả chi tiết về lỗi đang xảy ra. Bao gồm:

  • Tái sản xuất (Khả năng tái tạo): Mô tả rõ ràng các bước để tái tạo lỗi.
  • Kết quả thực tế (Kết quả thực tế): Kết quả thực tế của việc chạy các bước tái tạo lỗi ở trên.
  • Kết quả mong đợi (Kết quả mong muốn): Cách ứng dụng hoạt động bình thường khi chạy các bước tái tạo lỗi ở trên.

Các lưu ý cần ghi nhớ để viết một Báo cáo lỗi tốt

Các lưu ý cần ghi nhớ để viết một Báo cáo lỗi tốt
Các lưu ý cần ghi nhớ để viết một Báo cáo lỗi tốt

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

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

Ảnh chụp màn hình
Ảnh chụp màn hình

Xác nhận lỗi

Xác nhận lỗi
Xác nhận lỗi

  • Kiểm tra lỗi chính xác bằng cách:
    – Xóa bộ nhớ cache (Ctrl + F5)
    – Kiểm tra nhật ký máy chủ
    – Kiểm tra nhật ký bảng điều khiển
    – Kiểm tra cơ sở dữ liệu
    – Thử nghiệm trên các mô-đun tương tự khác
  • Sao chép lỗi 3 lần trước khi báo cáo.
  • Đảm bảo các bước tái tạo lỗi đã hoàn tất
  • Ghi chú: Nếu lỗi của bạn không thể tái tạo, bạn vẫn có thể ghi chú và kiểm tra lại mỗi khi thực hiện kiểm tra.

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

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

  • Báo cáo nó ngay khi bạn nhìn thấy nó và đã xác định nó là lỗi.
  • Đừng đợi Báo cáo lỗi hoàn thành hoặc kiểm tra phần đó trước khi bạn báo cáo.
  • Tránh bỏ sót lỗi và khả năng tái tạo.

Viết một bản tóm tắt về lỗi cụ thể

Viết một bản tóm tắt về lỗi cụ thể
Viết một bản tóm tắt về lỗi cụ thể

  • Mô tả lỗi ngắn gọn.
  • Đánh số các bước theo trình tự.
  • Một bản tóm tắt lỗi rõ ràng sẽ giúp các nhà phát triển phân tích lỗi dễ dàng hơn.
  • Mục tiêu của Bug Report là giúp các nhà phát triển tái tạo để viết mã và thử nghiệm.

Đừng lạm dụng ngôn ngữ

Đừng lạm dụng ngôn ngữ
Đừng lạm dụng ngôn ngữ

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

Sử dụng máy khác để tạo lại lỗi

Sử dụng máy khác để tạo lại lỗi
Sử dụng máy khác để tạo lại lỗi

  • Sử dụng máy thứ ba để tái tạo lỗi trong trường hợp không thể tái tạo lỗi tương tự trên máy nhà phát triển và máy thử nghiệm.
  • Nếu một mô-đun có lỗi, các mô-đun khác cũng sẽ có lỗi. Người kiểm tra có thể tìm thấy nhiều lỗi nghiêm trọng hơn trong các mô-đun khác.

Công cụ hỗ trợ viết Báo cáo lỗi

Công cụ hỗ trợ viết Báo cáo lỗi
Công cụ hỗ trợ viết Báo cáo lỗi

Word / Excel

Word và Excel
Word và Excel

  • Thời gian làm việc của QA trong dự án chủ yếu liên quan đến tài liệu.
  • Dễ dàng thêm / bớt một số trường hợp kiểm thử khi phát sinh các thay đổi.
  • Đánh số và thống kê các test case một cách tiện lợi.
  • Xác minh testcase đã được kiểm tra trong một tệp testcase với một số lượng lớn các testcase một cách nhanh chóng bằng Excel.
  • Dễ dàng xuất báo cáo về dữ liệu hiện có hoặc tạo dữ liệu thử nghiệm ngẫu nhiên.

Ứng dụng ghi nhớ

Ứng dụng ghi nhớ
Ứng dụng ghi nhớ

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

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

Khi người kiểm tra cần chụp toàn bộ màn hình hiển thị của một trang web dài, hãy tìm kiếm 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à thông tin về Bug Report cho những bạn đang có nhu cầu. Hy vọng bài viết này cung cấp thông tin hữu ích. Chúc các bạn hoàn thành Báo cáo lỗi tốt nhất!

xem thêm thông tin chi tiết về Bug Report là gì? Tiêu chuẩn của một Bug Report chất lượng

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

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

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

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

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

Đối với hầu hết mọi người Báo cáo lỗi Nghe thì có vẻ hơi xa lạ nhưng với dân 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 tìm hiểu ngay các tiêu chí để đánh giá chất lượng của một Báo cáo lỗi.

Báo cáo lỗi là gì?

Báo cáo lỗi là một mô tả về một lỗi xảy ra khi thực hiện kiểm tra phần mềm. Các nhà phát triển (nhà phát triển) còn được gọi là lỗi đăng nhập hoặc lỗi báo cáo. Bug Report thường do tester thực hiện trên phần mềm quản lý.

Báo cáo lỗi là gì?

Tại sao việc viết một Báo cáo lỗi tốt lại quan trọng?

Lý do để viết Báo cáo lỗi
Lý do để viết Báo cáo lỗi

  • Vì vậy, các nhà phát triển có thể tái tạo các lỗi một cách dễ dàng.
  • Tỷ lệ lỗi được sửa sẽ cao hơn.
  • Cung cấp một sản phẩm chất lượng tốt hơn.
  • Cải thiện tinh thần đồng đội.
  • Hạn chế xung đột giữa người kiểm thử và nhà phát triển.
  • Cải thiện kỹ năng viết mã cho các nhà phát triển.
  • Nâng cao kỹ năng của người kiểm thử.

Tiêu chí để đánh giá một Báo cáo lỗi chất lượng

Báo cáo lỗi chất lượng Báo cáo lỗi xấu
Chứa thông tin lỗi đầy đủ. Thiếu thông tin hoặc không rõ ràng.
Có thể lặp lại. Không thể tái tạo.
Tạo tiền đề cho mối quan hệ giữa dev và tester. Tạo ra tranh cãi và xung đột giữa nhà phát triển và người thử nghiệm.
Các lỗi được khắc phục nhanh chóng. Lỗi không được sửa.

Cách viết một báo cáo lỗi hoàn chỉnh

Cách viết một báo cáo lỗi hoàn chỉnh
Cách viết một báo cáo lỗi hoàn chỉnh

Tùy thuộc vào định dạng và công cụ mà người kiểm tra sử dụng, điều quan trọng là phải lưu ý thông tin sau để có Báo cáo lỗi hoàn chỉnh:

Người báo cáo (PV): Tên và email của người kiểm tra.

Sản phẩm (Tên sản phẩm): Tên của sản phẩm mà người thử nghiệm đã tìm thấy lỗi.

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

Các thành phần (Thành phần): Là mô-đun chính hoặc phụ của sản phẩm.

Nền tảng (Nền tảng): Nền tảng phần cứng mà người kiểm tra tìm thấy lỗi. Ví dụ: PC, MAC, v.v.

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

Quyền ưu tiên (Ưu tiên): Khi nào thì nên sửa lỗi? Mức độ ưu tiên thường được chỉ định từ P1 đến P5 theo thứ tự tăng dần.

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

  • Chặn: Không có thử nghiệm nào khác có thể được thực hiện.
  • Phê bình: Ứng dụng bị treo, mất dữ liệu.
  • Chính: Thiếu chức năng chính.
  • Diễn viên phụ: Thiếu các chức năng phụ.
  • Không đáng kể: Cải thiện giao diện người dùng.
  • Cải tiến: Yêu cầu các tính năng mới hoặc nâng cấp chức năng hiện có.

Trạng thái (Trạng thái): trạng thái của lỗi, ví dụ:

  • Mới: Lỗi vừa được kiểm tra
  • Đã giải quyết: Lỗi đã được sửa
  • Xong: Lỗi đã được kiểm tra bởi người thử nghiệm exe
  • Mở lại: Sau khi dev fix, test lại test vẫn báo lỗi,….

Giao cho (Được gán cho): Đính kèm tên của nhà phát triển với lỗi tương ứng nếu người thử nghiệm biết nó.

URL (Liên kết): URL của trang xảy ra lỗi.

Bản tóm tắt (Tóm tắt): Một bản tóm tắt ngắn, dưới 60 từ, để mô tả lỗi. Và hãy đảm bảo rằng bản tóm tắt này mô tả đầy đủ về lỗi và nơi nó đã xảy ra.

sự mô tả (Mô tả): Mô tả chi tiết về lỗi đang xảy ra. Bao gồm:

  • Tái sản xuất (Khả năng tái tạo): Mô tả rõ ràng các bước để tái tạo lỗi.
  • Kết quả thực tế (Kết quả thực tế): Kết quả thực tế của việc chạy các bước tái tạo lỗi ở trên.
  • Kết quả mong đợi (Kết quả mong muốn): Cách ứng dụng hoạt động bình thường khi chạy các bước tái tạo lỗi ở trên.

Các lưu ý cần ghi nhớ để viết một Báo cáo lỗi tốt

Các lưu ý cần ghi nhớ để viết một Báo cáo lỗi tốt
Các lưu ý cần ghi nhớ để viết một Báo cáo lỗi tốt

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

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

Ảnh chụp màn hình
Ảnh chụp màn hình

Xác nhận lỗi

Xác nhận lỗi
Xác nhận lỗi

  • Kiểm tra lỗi chính xác bằng cách:
    - Xóa bộ nhớ cache (Ctrl + F5)
    - Kiểm tra nhật ký máy chủ
    - Kiểm tra nhật ký bảng điều khiển
    - Kiểm tra cơ sở dữ liệu
    - Thử nghiệm trên các mô-đun tương tự khác
  • Sao chép lỗi 3 lần trước khi báo cáo.
  • Đảm bảo các bước tái tạo lỗi đã hoàn tất
  • Ghi chú: Nếu lỗi của bạn không thể tái tạo, bạn vẫn có thể ghi chú và kiểm tra lại mỗi khi thực hiện kiểm tra.

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

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

  • Báo cáo nó ngay khi bạn nhìn thấy nó và đã xác định nó là lỗi.
  • Đừng đợi Báo cáo lỗi hoàn thành hoặc kiểm tra phần đó trước khi bạn báo cáo.
  • Tránh bỏ sót lỗi và khả năng tái tạo.

Viết một bản tóm tắt về lỗi cụ thể

Viết một bản tóm tắt về lỗi cụ thể
Viết một bản tóm tắt về lỗi cụ thể

  • Mô tả lỗi ngắn gọn.
  • Đánh số các bước theo trình tự.
  • Một bản tóm tắt lỗi rõ ràng sẽ giúp các nhà phát triển phân tích lỗi dễ dàng hơn.
  • Mục tiêu của Bug Report là giúp các nhà phát triển tái tạo để viết mã và thử nghiệm.

Đừng lạm dụng ngôn ngữ

Đừng lạm dụng ngôn ngữ
Đừng lạm dụng ngôn ngữ

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

Sử dụng máy khác để tạo lại lỗi

Sử dụng máy khác để tạo lại lỗi
Sử dụng máy khác để tạo lại lỗi

  • Sử dụng máy thứ ba để tái tạo lỗi trong trường hợp không thể tái tạo lỗi tương tự trên máy nhà phát triển và máy thử nghiệm.
  • Nếu một mô-đun có lỗi, các mô-đun khác cũng sẽ có lỗi. Người kiểm tra có thể tìm thấy nhiều lỗi nghiêm trọng hơn trong các mô-đun khác.

Công cụ hỗ trợ viết Báo cáo lỗi

Công cụ hỗ trợ viết Báo cáo lỗi
Công cụ hỗ trợ viết Báo cáo lỗi

Word / Excel

Word và Excel
Word và Excel

  • Thời gian làm việc của QA trong dự án chủ yếu liên quan đến tài liệu.
  • Dễ dàng thêm / bớt một số trường hợp kiểm thử khi phát sinh các thay đổi.
  • Đánh số và thống kê các test case một cách tiện lợi.
  • Xác minh testcase đã được kiểm tra trong một tệp testcase với một số lượng lớn các testcase một cách nhanh chóng bằng Excel.
  • Dễ dàng xuất báo cáo về dữ liệu hiện có hoặc tạo dữ liệu thử nghiệm ngẫu nhiên.

Ứng dụng ghi nhớ

Ứng dụng ghi nhớ
Ứng dụng ghi nhớ

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

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

Khi người kiểm tra cần chụp toàn bộ màn hình hiển thị của một trang web dài, hãy tìm kiếm 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à thông tin về Bug Report cho những bạn đang có nhu cầu. Hy vọng bài viết này cung cấp thông tin hữu ích. Chúc các bạn hoàn thành Báo cáo lỗi tốt nhất!

[rule_{ruleNumber}]

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

[rule_3_plain]

#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 tìm hiểu ngay những tiêu chuẩn để đánh giá chất lượng của một Bug Report nhé.

Nội dung bài viết

Bug Report là gì?Lý do cần phải viết Bug Report tốt?Tiêu chuẩn đánh giá một Bug Report chất lượngCách viết một Bug Report hoàn chỉnhNhững lưu ý cần nắm để viết Bug Report tốtChụp lại hình ảnh khi gặp hiện tượng lạXác nhận BugBáo cáo lập tứcViết tóm tắt lỗi cụ thểKhông lạm dụng ngôn ngữDùng máy khác để tái hiện lỗiCông cụ hỗ trợ viết Bug ReportWord/ExcelỨng dụng ghi nhớỨng dụng chụp màn hình
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ý.

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

Lý do cần viết Bug Report
Để 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
Bug Report chất lượng
Bug Report kém
Chứa đầy đủ thông tin về bug.
Thiếu thông tin hoặc thông tin không rõ ràng.
Có thể tái hiện được.
Không thể tái hiện được.
Tạo tiền đề cho mối quan hệ giữa dev và tester.
Tạo tranh cãi và mâu thuẫn giữa dev và tester.
Bug được sửa nhanh chóng.
Bug không được sửa.
Cách viết một Bug Report hoàn chỉnh

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.
Expected result (Kết quả mong muốn): Cách ứng dụng hoạt động đúng khi chạy các bước tái hiện bug ở trên.
Những lưu ý cần nắm để viết Bug Report tốt

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).

Chụp lại màn hình
Xác nhận Bug

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

Báo cáo lập tức
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ể

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 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 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

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

Word và 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ớ

Ứng dụng ghi nhớ
Ứ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!

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

[rule_2_plain]

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

[rule_2_plain]

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

[rule_3_plain]

#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 tìm hiểu ngay những tiêu chuẩn để đánh giá chất lượng của một Bug Report nhé.

Nội dung bài viết

Bug Report là gì?Lý do cần phải viết Bug Report tốt?Tiêu chuẩn đánh giá một Bug Report chất lượngCách viết một Bug Report hoàn chỉnhNhững lưu ý cần nắm để viết Bug Report tốtChụp lại hình ảnh khi gặp hiện tượng lạXác nhận BugBáo cáo lập tứcViết tóm tắt lỗi cụ thểKhông lạm dụng ngôn ngữDùng máy khác để tái hiện lỗiCông cụ hỗ trợ viết Bug ReportWord/ExcelỨng dụng ghi nhớỨng dụng chụp màn hình
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ý.

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

Lý do cần viết Bug Report
Để 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
Bug Report chất lượng
Bug Report kém
Chứa đầy đủ thông tin về bug.
Thiếu thông tin hoặc thông tin không rõ ràng.
Có thể tái hiện được.
Không thể tái hiện được.
Tạo tiền đề cho mối quan hệ giữa dev và tester.
Tạo tranh cãi và mâu thuẫn giữa dev và tester.
Bug được sửa nhanh chóng.
Bug không được sửa.
Cách viết một Bug Report hoàn chỉnh

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.
Expected result (Kết quả mong muốn): Cách ứng dụng hoạt động đúng khi chạy các bước tái hiện bug ở trên.
Những lưu ý cần nắm để viết Bug Report tốt

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).

Chụp lại màn hình
Xác nhận Bug

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

Báo cáo lập tức
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ể

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 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 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

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

Word và 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ớ

Ứng dụng ghi nhớ
Ứ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!

Chuyên mục: Hỏi đápt
#Bug #Report #là #gì #Tiêu #chuẩn #của #một #Bug #Report #chất #lượng

Xem thêm:   Đừng chia tay khi vẫn còn yêu

Related Articles

Back to top button