Bug report là gì

     

Đối với mỗi Tester, bài toán kiểm tra sản phẩm và report lỗi là vấn đề làm liên tục và tiếp tục nhưng không phải ai cũng biết giải pháp tự thẩm tra lại kia có đúng là Bug không và làm biện pháp nào viết Bug report một biện pháp hiệu quả.

Bạn đang xem: Bug report là gì

Dưới trên đây mình sẽ chia sẻ một số kinh nghiệm tay nghề của phiên bản thân hi vọng có thể giúp ích cho các bạn.

1. Bug report là gì? 

Bug report là diễn đạt lỗi xảy ra khi triển khai test phần mềm, thường tuyệt được Dev nhà mình hotline vui là log Bug tốt report Bug. Bug report thường xuyên được Tester thực hiện trên những phần mềm thống trị tasks như Redmine, Jira,…


*

Bug report là gì?


2. Tại sao phải viết Bug report tốt?

Để Dev rất có thể tái hiện tại Bug dễ dàngTỷ lệ Bug được fix vẫn cao hơnĐưa ra một sản phẩm quality tốt hơnNâng cao kĩ năng Teamwork. Lúc Tester viết Bug report “chất lượng” vô hình làm cho Dev một ấn tượng, sự tin yêu về tác dụng test của Tester và gần như Bug cơ mà Tester log lên. Khi đó, sẽ tránh được một vài xung hốt nhiên không xứng đáng có giữa Dev và Tester khi Tester trả về bug.Nâng cao khả năng code của Dev. Sau từng Bug bị trả về, Dev sẽ sở hữu thêm kinh nghiệm tay nghề cover code của chính mình hơn.Nâng cao khả năng của Tester.

3. Làm cụ nào để review được Bug report có xuất sắc hay không?

Ai cũng hoàn toàn có thể viết Bug report nhưng lại không phải người nào cũng viết report kết quả để Dev hoàn toàn có thể tái hiện tại được, đồng ý Bug và thực hiện fix.

Vậy làm thế nào để rất có thể phân biệt được Bug report có quality tốt và chất lượng trung bình? Dưới đây là một vài ba tiêu chí đánh giá tiêu biểu để xác định:

Bug report quality tốtBug report quality trung bình
Chứa không thiếu thốn thông tin về sự việc cần sửaThiếu tin tức hoặc tin tức không rõ ràng
Có thể tái hiện đượcKhông thể tái hiện
Tạo cần được chi phí đề phối kết hợp giữa Dev cùng TesterGây tranh cãi hoặc không hợp tác giữa Dev và Tester
Bug được sửa nhanhBug không được sửa

4. Vậy, làm núm nào để viết được một Bug report tốt?

Các chúng ta có thể tham khảo các nội dung sau:

Bug title: ngắn gọn, súc tích mà bao trọn được nội dung. Tất cả thể bao hàm các thông tin sau: ScreenID – Function Description – UTCaseID_IndexHiện tượng: tất cả cái nhìn tổng quan tiền về hiện tại tượng xảy ra của Bug, hoàn toàn có thể có ảnh chụp màn hình kèm theo nhằm Dev bao gồm cái nhìn trực quan tiền hơnMôi trường: Nên viết mô tả đầy đủ, đúng chuẩn hiện tượng xẩy ra ở môi trường nào (như môi trường thiên nhiên local, môi trường xung quanh staging,…) nhằm Dev hoặc người đọc xác thực được Bug nhanh và đúng chuẩn hơn Kỳ vọng về công dụng sau lúc fix của bug là gì? Để Dev và Tester gồm tiếng nói chung cũng giống như Dev đọc được mong ước về quality phần mượt của Tester thì Tester đề nghị ghi rõ phần này.Các cách tái hiện: ghi thành quá trình rõ ràng, từng bước khớp ứng với một làm việc cụ thể.Trạng thái của Bug: lúc Tester vừa tạo Bug report -> trạng thái của Bug là “New”. Tiếp nối sẽ có các trạng thái khớp ứng như: Resolved – Bug đã làm được fix; Done – Bug đã làm được Tester test; Reopen – sau khi Dev fix, Tester re-test vẫn còn đấy lỗi;…Mức độ ưu tiên của Bug: Khi làm sao Bug đề xuất được fix? Độ ưu tiên thường cách thức từ P1 cho P5 theo máy tự tăng dần. Trường đúng theo Bug chỉ chạm mặt trên 1 số máy cầm thể, hoặc tất cả độ ưu tiên thấp thì nên cần đánh độ ưu tiên của Bug phải chăng để cách xử lý sau.

Xem thêm: Biên Bản Nghiệm Thu Hợp Đồng Tiếng Anh Là Gì, Vậy Các Anh Chị

Assign: nếu Tester biết ai sẽ sửa thì gắn tên của Dev vào Bug tương ứng.Phiên bản (nếu có)Tác vụ cha (nếu có)Ngày bắt đầu: Ngày Dev bắt đầu thực hiện nay fixNgày không còn hạn: Ngày kết thúc việc sửa thực tế

5. Một số mẹo cùng thủ thuật dành cho bạn.

Chụp lại hình ảnh ngay khi chạm mặt Bug hoặc hiện tượng lạ lạ: để tránh sự cố Bug cực nhọc tái hiện tại thì ta yêu cầu chụp tức thì lại ảnh màn hình giữ lại để báo cáo sau khi chứng thực Bug. Xác nhấn lại Bug: để không xẩy ra log Bug “nhầm” thì trước khi report nên kiểm soát xem đó có chính xác là Bug xuất xắc không bằng cách xóa bộ lưu trữ cache (Ctrl +F5), đánh giá log server, kiểm tra console log, kiểm soát database, chất vấn trên module giống như khác …và từ tái hiện nay Bug 3 lần trước khi báo cáo.Báo cáo ngay lập tức lập tức: có tức thị sau khi gặp mặt và đã xác định đó là Bug thì nên báo cáo luôn, không ngóng viết Bug report chấm dứt hoặc test ngừng phần đó rồi mới báo cáo. Điều này bảo vệ không bị thiếu thốn Bug và rất có thể tái hiện nay được.Viết nắm tắt lỗi rõ ràng: Đây là phần quan lại trọng chỉ sau phần tiêu đề. đề nghị mô tả lỗi ngắn gọn. Công việc nên tấn công thứ từ bỏ 1-2-3…, từng step chỉ biểu lộ một hành động, không viết dài quá. Mục tiêu là khi gửi Bug report cho một người lần chần gì thực hiện theo những mô tả hoàn toàn có thể tái hiện được Bug đó.Không sử dụng ngôn từ gây tổn thương fan đọc: nếu không phải là Bug thì nên gọi là sự việc của chức năng nào đó, không tiến công đồng call là Bug gây ảnh hưởng tới tâm lý người làm cho task.Bug nặng nề tái hiện: ngôi trường hợp quan trọng tái hiện tại lỗi tương đương nhau trên máy Dev cùng Tester thì nên cần dùng thứ thứ 3 nhằm tái hiện, vì vậy sẽ review được đúng mực lỗi hơn.

Xem thêm: Những Hoạt Động Nào Giúp Rèn Luyện Cơ Phụ Thuộc Vào Những Yếu Tố Nào? Những

Ví dụ: Báo cáo lỗi


*

Ví dụ về một bug report vừa đủ thông tin


6. Một số phần mềm hỗ trợ.

Phần mềm cung cấp kiểm tra và xác nhận lỗi

Phần mềm cung cấp chụp ảnh/ cù video:

Tóm lại, cầm cố nào là một trong bug report hiệu quả?

Dễ dàng tái hiện vày Dev hoặc tín đồ đọcReport ngắn gọn, rõ ràngĐầy đủ thông tin, hình ảnhDễ dàng theo dõi, tầm nã vấn bug lúc cầnKhả năng được fix cao

Trên đấy là những tay nghề của bạn dạng thân, rất ao ước nhận được sự chia sẻ hoặc bổ sung cập nhật ý loài kiến từ phía những bạn. Chúc các bạn viết Bug report hiệu quả!