Hướng dẫn 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 quy trình STLC, mang lại nhiều lợi ích cho nhóm kiểm thử. Nó giúp lưu giữ thông tin về lỗi. tracK liệt kê tất cả các khiếm khuyết, nhiều lỗi, sai sót và các điểm không nhất quán 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 can be made aware of all the defects and issues present in the software using this type of report. It also lets you figure out what is wrong with a bug, so you can use the best method to fix it. It also helps you to save your time and money by helping Bạn sẽ phát hiện ra 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?

Đâ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.
• Modern teams using Jira, Linear, or Azure DevOps can also link bug reports to sprint tickets and release pipelines, ensuring traceability across QA and DevOps workflows.

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 cụ thể nào, vì nó phụ thuộc vào lỗi bạn gặp phải.tracHệ thống vua. 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ả Chi tiế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)

Let us look at all these bug-tracking components one by one:

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:

However, adding only the Title in the bug report does not serve the purpose. So, if your Title is not enough, you can add a short report summary.

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 cửa hàngping Giỏ hàng đã được thêm vào, nhưng không có gì xảy ra khi tôi nhấn vào nút 'thêm' trên trang tổng quan sản phẩm cụ thể.”

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

When reporting a bug, it is important to specify the steps to reproduce it. You should also include actions that may cause the bug. Here, do not make any generic statements.

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: Sometimes, it is difficult to describe the bug in words, so it is better to create a video so that developer can rectify the defect in the program).

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

• Be specific when creating bug reports. Make sure you do not include any useless or irrelevant facts.
• 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ì đó.
• Use AI-assisted triage features in Jira or Linear to auto-classify severity, suggest duplicates, and route the report to the right component owner.

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.

• Jira
• tuyến tính
• Azure DevOps
• Lỗi Zoho Tracker
• 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.	Do not only describe what is wrong
Ví dụ: Để bắt đầu, bạn cần mở trình duyệt và nhập địa chỉ trang web. URL. You will find the first field, ‘username,’ misspelled.	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 đỏ, '!',
I do not think that the home page Ul design is good.	Do not use your judgment.
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.	The golden rule: Do not use the word ‘Sometimes’.

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:

• Do not write about your dissatisfaction, and never include your personal feelings.
• 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 đề.

Câu Hỏi Thường Gặp