Cách viết báo cáo lỗi kèm ví dụ

Báo cáo lỗi là gì? Tại sao bạn cần một báo cáo lỗi tốt?

Báo cáo lỗi là một tài liệu quan trọng trong STLC mang lại nhiều lợi ích khác nhau cho nhóm thử nghiệm. Nó theo dõi tất cả các khiếm khuyết, nhiều lỗi, sai sót và những khác biệt khác được tìm thấy trong quá trình kiểm thử phần mềm và báo cáo chúng.

Mục đích của tài liệu sau kiểm tra này là cung cấp thông tin cho nhóm chuyên gia có liên quan về mức độ lỗi gặp phải trong quá trình kiểm tra.

trên màn hình kỹ sư phát triển phần mềm có thể biết được tất cả các khiếm khuyết và vấn đề có trong phần mềm bằng cách sử dụng loại báo cáo này. Nó cũng cho phép bạn tìm ra lỗi xảy ra ở đâu để bạn có thể sử dụng phương pháp tốt nhất để sửa lỗi đó. Nó cũng giúp bạn tiết kiệm thời gian và tiền bạc bằng cách giúp bạn phát hiện lỗi và sự cố.

Tại sao bạn nên quan tâm đến những lời giải thích lỗi tốt?

Giải thích lỗi tốt

Đây là điểm bạn cần cân nhắc để viết một báo cáo lỗi phần mềm hay và chi tiết:

  • Nó hoạt động như một hướng dẫn để giúp tránh lỗi tương tự trong các bản phát hành trong tương lai.
  • Tiết kiệm thời gian giao tiếp (email, cuộc gọi).
  • Less làm việc cho các nhà phát triển (họ sẽ làm chính xác những gì bạn muốn).
  • Bạn sẽ gặp ít nút thắt hơn trong dự án; lỗi sẽ được sửa chữa nhanh hơn và hiệu quả hơn.

Cách viết báo cáo lỗi (Mẫu báo cáo lỗi)

Không có mẫu báo cáo lỗi chính xác vì nó phụ thuộc vào hệ thống theo dõi lỗi của bạn. Mẫu của bạn có thể khác.

Tuy nhiên, các trường thông dụng sau đây luôn cần thiết khi bạn muốn viết báo cáo lỗi:

  • Id lỗi/Tiêu đề.
  • Mức độ nghiêm trọng và ưu tiên.
  • Mô tả
  • Môi trường
  • Các bước để tái tạo.
  • Kết quả mong đợi.
  • Kết quả thực tế.
  • Tệp đính kèm (ảnh chụp màn hình, video, văn bản)

Chúng ta hãy xem xét từng thành phần sửa lỗi này:

1) Tiêu đề/ID lỗi:

Mỗi lỗi phải được cấp một mã số nhận dạng duy nhất. Công cụ báo lỗi phải là những con số duy nhất cho những lỗi mới phát sinh để chúng ta có thể dễ dàng xác định lỗi.

Ví dụ:

❌ Tệ: “Tôi không thể nhìn thấy sản phẩm khi quay lại, đánh máy là không.”

  • Mơ hồ
  • Tích cực
  • Quá dài dòng

yêu cầu một giải pháp được thực hiện.

✅ Tốt: “GIỎ HÀNG – Mặt hàng mới được thêm vào giỏ hàng không xuất hiện”.

  • Loại Tiêu đề này ngay lập tức xác định được vấn đề (GIỎ HÀNG)
  • Nó tập trung vào vấn đề kỹ thuật thực tế.

2) Mức độ nghiêm trọng của lỗi:

Mức độ nghiêm trọng của lỗi là một yếu tố rất quan trọng trong báo cáo lỗi. Nó mô tả ảnh hưởng của lỗi đến hiệu suất của ứng dụng.

  • Chặn: Lỗi này khiến ứng dụng bị lỗi.
  • Thiếu tá: Một lỗi nghiêm trọng cho thấy có sự thay đổi lớn trong logic nghiệp vụ.
  • Diễn viên phụ: Một sự cố không ảnh hưởng đến chức năng của ứng dụng nhưng lại ảnh hưởng đến kết quả mong đợi.
  • Không đáng kể: Nó không ảnh hưởng đến chức năng hoặc hoạt động của ứng dụng. Nó có thể là một lỗi đánh máy.

3) Mức độ ưu tiên của lỗi:

Sau đây là thang điểm chung để quyết định mức độ ưu tiên của lỗi:

  • Cao: Nó bao gồm mọi thứ ảnh hưởng đến luồng hoặc chặn việc sử dụng ứng dụng.
  • Trung bình: Nó ảnh hưởng xấu đến trải nghiệm của người dùng.
  • Diễn viên phụ: Tất cả các lỗi khác như (lỗi chính tả, thiếu biểu tượng, vấn đề về bố cục, v.v.).

4) Môi trường:

Lỗi có thể xuất hiện trong một môi trường cụ thể chứ không phải ở môi trường khác. Ví dụ: đôi khi xuất hiện lỗi khi chạy trang web trên Firefoxhoặc ứng dụng chỉ gặp trục trặc khi chạy trên Android thiết bị và hoạt động tốt trên iPhone.

Những báo cáo lỗi này chỉ có thể được xác định bằng thử nghiệm trên nhiều trình duyệt hoặc trên nhiều thiết bị. Vì vậy, khi báo cáo lỗi, QA sẽ có thể chỉ định xem lỗi có nên được quan sát trong một hoặc nhiều môi trường cụ thể hay không.

5) Tóm tắt:

Tuy nhiên, việc chỉ thêm Tiêu đề vào báo cáo lỗi không phục vụ được mục đích. Vì vậy, nếu Tiêu đề của bạn chưa đủ, bạn có thể thêm một bản tóm tắt báo cáo ngắn.

Bản tóm tắt của bạn càng ít từ càng tốt, bao gồm cả thời điểm và cách thức xảy ra lỗi. Tiêu đề và mô tả lỗi của bạn cũng nên được sử dụng trong các tìm kiếm, vì vậy bạn phải đảm bảo rằng bạn đã bao gồm các từ khóa quan trọng.

Các ví dụ:

  • Xấu: “Tôi đang cố gắng thêm nội dung vào bài kiểm tra nhưng không có gì hiển thị khi tôi làm điều đó hoặc nhấp vào nút.”
  • Tốt: “Khi tôi thử thêm [SẢN PHẨM] vào giỏ hàng nhưng không có gì xảy ra khi tôi nhấp vào nút 'thêm' trên trang web tổng quan về sản phẩm cụ thể.”

6) Các bước sao chép:

Khi báo cáo một lỗi, điều quan trọng là phải chỉ rõ các bước để tái hiện lỗi đó. Bạn cũng nên bao gồm các hành động có thể gây ra lỗi. Ở đây, đừng đưa ra bất kỳ tuyên bố chung chung nào.

Hãy cụ thể hóa các bước cần thực hiện:

Đây là một ví dụ về thủ tục được viết tốt:

Bước sau:

  1. Chọn sản phẩm X1.
  2. Bấm vào Thêm vào giỏ hàng.
  3. Nhấn Remove để xóa sản phẩm khỏi giỏ hàng.

7) Kết quả mong đợi:

Trong các báo cáo lỗi, việc mô tả kết quả mong đợi theo nhiệm vụ kỹ thuật, thiết kế kết quả của trường hợp kiểm thử hoặc theo ý kiến ​​của người kiểm thử là quan trọng. Tất cả điều này giúp các nhà phát triển tập trung vào việc nhanh chóng tìm kiếm thông tin cần thiết.

Ví dụ:

Các trường bắt buộc phải được đánh dấu màu đỏ sau khi nhấp vào nút “Gửi”.

8) Kết quả thực tế:

Đúng như tên gọi, trường này mô tả tác động thực tế của lỗi. Điều rất quan trọng là viết một mô tả rõ ràng về kết quả thực tế.

Ví dụ:

Các trường bắt buộc được đánh dấu bằng màu xanh lục sau khi nhấp vào nút “Gửi”.

9) Tệp đính kèm (ảnh chụp màn hình và video):

Trong báo cáo lỗi, cách tốt nhất là đính kèm tệp vào báo cáo lỗi để giúp bạn dễ dàng nhận biết thông tin hơn khi bạn cần hiển thị nó một cách trực quan:

Ví dụ:

  • ảnh chụp màn hình: Ảnh chụp màn hình có thể dễ dàng chỉ ra các lỗi trong chương trình; Thật thuận tiện khi lỗi được đánh dấu bằng chú thích, hình ảnh hình tròn hoặc mũi tên cụ thể).
  • Video: Đôi khi, rất khó để diễn tả lỗi bằng lời, vì vậy tốt hơn nên tạo một video để nhà phát triển có thể khắc phục lỗi trong chương trình).

10) Phiên bản bị ảnh hưởng:

Đây là phiên bản phần mềm bị ảnh hưởng và lỗi được báo cáo.

11) Phiên bản sửa lỗi:

Đây là phiên bản phần mềm đã giải quyết được lỗi. Vì vậy, khi QA báo cáo lỗi, kiểm tra xem lỗi đã được sửa chưa, anh ta sử dụng đúng phiên bản phần mềm.

12) Target phiên bản:

Phiên bản mục tiêu mà lỗi cần được nhắm mục tiêu để sửa. Vì vậy, khi nhóm phát triển tiến hành sửa lỗi, họ chủ yếu nhắm mục tiêu vào một phiên bản ứng dụng cụ thể.

13) Ngày đóng cửa:

Đó là ngày mà lỗi được nhóm kiểm thử phần mềm đóng lại. Việc khắc phục lỗi là một phần quan trọng và không thể thiếu trong quá trình kiểm thử phần mềm.

14) Tình trạng:

Khi một lỗi mới được tạo ra, trạng thái của nó sẽ là mở. Sau đó, nó trải qua các giai đoạn như Đang tiến hành, Đã sửa, Đang chạy, Mở lại, v.v.

Mẹo viết báo cáo lỗi

Dưới đây là một số mẹo quan trọng mà bạn nên nhớ khi viết báo cáo lỗi hiệu quả:

  • Hãy cụ thể khi tạo báo cáo lỗi. Đảm bảo rằng bạn không đưa vào bất kỳ thông tin vô ích hoặc không liên quan nào.
  • Bạn phải báo cáo lỗi ngay khi phát hiện được.
  • Chuẩn bị báo cáo chi tiết để trao quyền cho nhà phát triển sử dụng dữ kiện và thông tin để khắc phục sự cố.
  • Bạn nên kiểm tra lỗi xảy ra tương tự trên các mô-đun tương tự khác để xác thực.
  • Review báo cáo lỗi ít nhất một lần trước khi gửi nó.
  • Bạn nên đảm bảo rằng báo cáo lỗi chỉ chứa mô tả của một lỗi.
  • Cuối cùng, bạn đừng ngại yêu cầu Người quản lý dự án giúp đỡ nếu bạn cảm thấy không rõ ràng về điều gì đó.

Công cụ báo cáo lỗi

Quy trình báo cáo lỗi, được thực hiện thủ công, hiện đang được thực hiện bằng nhiều công cụ báo cáo lỗi khác nhau có sẵn trên thị trường.

  • CHUYẾN DU LỊCH
  • Trình theo dõi lỗi Zoho
  • bugzilla

Bạn có thể kiểm tra đánh giá chi tiết của chúng tôi về công cụ báo cáo lỗi tốt nhất.

Vấn đề thường gặp và giải pháp khi viết báo cáo lỗi:

Dưới đây là một số vấn đề thường gặp và giải pháp khắc phục khi viết báo cáo lỗi:

Ví dụ về báo cáo lỗi Vấn đề
Khi nhân 2 với 3, câu trả lời sẽ là số dương. Báo cáo mẫu chứ không phải ví dụ.
Danh sách sẽ được sắp xếp theo thứ tự bảng chữ cái khi thêm một mục mới để tránh điều này. Đừng chỉ mô tả những gì sai
Ví dụ:
Để tồn tại, bạn sẽ cần mở trình duyệt của mình và nhập URL của trang web. Bạn sẽ tìm thấy trường đầu tiên, 'tên người dùng', sai chính tả.
Luôn đi thẳng vào vấn đề (Không bao giờ kể câu chuyện!).
Tên khách hàng trong báo cáo bị sai chính tả. Ưu tiên: Cao, Mức độ nghiêm trọng: Cao Không bao giờ trộn lẫn mức độ ưu tiên và mức độ nghiêm trọng.
Công thức tính thuế SAI!!?? Không sử dụng CAPS, chữ màu đỏ, vòng tròn màu đỏ, '!',
Tôi không nghĩ rằng thiết kế trang chủ Ul là tốt. Đừng sử dụng sự phán xét của bạn.
Ví dụ về mô tả không rõ ràng: Về cuộc thảo luận của chúng ta ngày hôm nay, vui lòng thực hiện hành động cần thiết cho trang này. Làm cho mô tả của bạn dễ hiểu đối với mọi người.
Nền trang phải có màu xanh lam, cam hoặc xanh lục hoặc bạn có thể chọn màu đen hoặc trắng.

Điều này không tốt vì không rõ nhóm thiết kế và phát triển web cần những gì

Giảm thiểu các tùy chọn
Công thức tính thuế đôi khi không hoạt động như mong đợi. Nguyên tắc vàng: Không sử dụng từ 'Thỉnh thoảng'.

Ví dụ về Báo cáo lỗi

Đây là một ví dụ nhỏ về báo cáo lỗi:

[TÀI KHOẢN CỦA TÔI] Phần gạch chân được hiển thị khi di chuột qua nút Cập nhật.

Description: Chúng ta cần bỏ phần gạch chân khi rê chuột vào nút Cập nhật trong phần Tài khoản của tôi.

Link: http://test.com/mv-account/

Trình duyệt/HĐH: Chrome 25. OSX Yosemite 10.10.2

Các bước để tái tạo:

1. Truy cập www.test.com

2. Đăng nhập thông qua thông tin đăng nhập

3. Điều hướng đến Tài khoản của tôi

4. Di chuột vào nút Cập nhật

Kết quả thực tế: có gạch chân.

Kết quả mong đợi: không có gạch chân.

Dữ liệu đăng nhập: test@test.com / mysecretpass12

Phải tránh sai sót khi viết báo cáo lỗi

Dưới đây là một số lỗi quan trọng mà bạn nên tránh khi viết báo cáo lỗi:

  • Đừng viết về sự không hài lòng của bạn và đừng bao giờ đề cập đến cảm xúc cá nhân của bạn.
  • Nó gây khó chịu cho những người muốn tập trung vào công việc khi bạn làm quá tải bài đăng của mình với quá nhiều biểu tượng cảm xúc.
  • Đừng bao giờ làm bài viết của bạn quá tải với các dấu chấm than; nó không tăng tốc công việc.
  • Không ai muốn cảm thấy bị xúc phạm. Nó phá hủy động lực và làm chậm việc nhận ra vấn đề.