Chi tiết bài viết
Tóm tắt nội dung
Trong thế giới kiểm thử phần mềm, việc ‘Log bug’ đóng vai trò quan trọng trong việc phát hiện và báo cáo lỗi. Nhưng Log bug là gì? Bài viết này sẽ giúp bạn hiểu rõ hơn về quá trình này, cũng như tại sao nó là bước quan trọng trong việc đảm bảo chất lượng sản phẩm
Công việc log bug là gì?
Log bug là quá trình ghi chép lại những lỗi được phát hiện và sự cố xảy ra trong quá trình sử dụng phần mềm. Công việc log bug thường được thực hiện bởi nhóm kiểm thử hoặc người dùng cuối để báo cáo vấn đề và cung cấp thông tin chi tiết để nhóm phát triển có thể sửa chữa.
Tại sao các tester phải viết Report cho mỗi quá trình log bug?
Việc viết báo cáo (report) cho mỗi quá trình log bug trong quá trình kiểm thử phần mềm là rất quan trọng và có nhiều lý do. Đơn giản như, quá trình báo cáo log bug là cách để chia sẻ thông tin chi tiết về lỗi với các thành viên khác trong nhóm phát triển, như lập trình viên, quản lý dự án, hay các chuyên gia khác. Quá trình viết report cũng giúp cho cả đội ngũ phát triển theo dõi tiến trình sửa lỗi. Các báo cáo thường có trạng thái, giúp theo dõi lỗi từ khi nó được phát hiện cho đến khi nó được sửa chữa và kiểm tra lại.
Bên cạnh đó, Báo cáo cung cấp thông tin để xác định mức độ nghiêm trọng của lỗi và ưu tiên công việc sửa chữa. Nhóm phát triển có thể quyết định xử lý các lỗi theo mức độ quan trọng và ảnh hưởng. Đồng thời giúp cho quá trình đánh giá về chất lượng phần mềm được hiệu quả. Các ý kiến, góp ý từ tester có thể cung cấp thông tin quý báu để cải thiện quy trình phát triển.
Lợi ích của các Developers khi nhận được report log bug là gì?
- Các Dev sẽ dễ dàng xác định được vị trí và nguyên nhân xảy ra lỗi.
- 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. Khi Tester viết Bug report “chất lượng” vô hình tạo cho Dev một ấn tượng, sự tin tưởng về kết quả test của Tester và những Bug mà Tester log lên. Khi đó, sẽ tránh được một vài xung đột không đáng có giữa Dev và Tester khi Tester trả về bug.
- Nâng cao kỹ năng code của Dev. Sau mỗi Bug bị trả về, Dev sẽ có thêm kinh nghiệm cover code của mình hơn.
- Giúp cho mối quan hệ giữa các Dev và Tester trở lên tốt hơn, làm việc hiệu quả hơn.
Cấu trúc của một bản Report log bug bao gồm những gì?
Đối với những tester lâu năm, để phát hiện và đánh giá được các log bug thì cần lưu ý tới những yếu tố sau để có thể dễ dàng mô tả chúng tới cho đội ngũ viết code:
- Các bug xảy ra là gì? Những bug đó đã gây ra hệ quả gì đến quá trình hoạt động của phần mềm?
- Lỗi này xảy ra ở đâu, trên môi trường nào (web thì browser nào,app thì trên hệ điều hành nào)
- Bug xảy ra khi nào (nghĩa là thực hiện những bước nào ở quá trình code thì xảy ra Bug)
- Nêu ra phương án sửa lỗi theo đề xuất của Tester
- Ai là người đã tạo ra những bug này và ai sẽ chịu trách nhiệm fix bug.
Cấu trúc viết báo cáo log bug là gì?
- Mô tả lỗi: Mô tả chi tiết về lỗi, bao gồm các bước để tái tạo lỗi nếu có thể.
- Ngày và thời gian xảy ra lỗi: Ghi lại thời điểm xảy ra lỗi để phục vụ việc theo dõi và xác định nguyên nhân.
- Loại lỗi: Phân loại lỗi theo mức độ nghiêm trọng, từ những lỗi nhỏ đến lỗi lớn có thể ảnh hưởng đến chức năng chính của phần mềm.
- Môi trường: Thông tin về môi trường nơi lỗi xảy ra, chẳng hạn như phiên bản phần mềm, hệ điều hành, trình duyệt, v.v.
- Dữ liệu liên quan: Nếu có thể, cung cấp dữ liệu mẫu hoặc đầu vào gây ra lỗi.
Quá trình log bug giúp tạo cơ sở dữ liệu vững chắc về các vấn đề trong phần mềm, giúp nhóm phát triển hiểu rõ hơn về thách thức và tối ưu hóa quá trình sửa lỗi.
Làm thế nào để viết một bản báo cáo log bug tốt
Một bản báo cáo log bug tốt là một bản report hiệu quả để Dev có thể tái hiện được, chấp nhận Bug và thực hiện fix. Thông thường bản report log bug hiệu quả sẽ chứa đầy đủ thông tin về vấn đề cần sửa, bản báo cáo này có thể dễ dàng được tái hiện lại và nhờ vào nó mà bug được sửa nhanh chóng…
Chính vì thế, thông thường một bản báo cáo hiệu quả sẽ được viết dựa trên những cấu trúc như sau:
- Bug title:ngắn gọn, xúc tích mà bao trọn được nội dung. Có thể bao gồm các thông tin sau: {ScreenID} – {Function Description} – {UTCaseID_Index}
- Hiện tượng:có cái nhìn tổng quan về hiện tượng xảy ra của Bug, có thể có ảnh chụp màn hình kèm theo để Dev có cái nhìn trực quan hơn
- Môi trường: Nên viết mô tả đầy đủ, chính xác hiện tượng xảy ra ở môi trường nào (như môi trường local, môi trường staging,…) để Dev hoặc người đọc xác nhận được Bug nhanh và chính xác hơn
- Kỳ vọng về kết quả sau khi fix của bug là gì? Để Dev và Tester có tiếng nói chung cũng như Dev hiểu được mong muốn về chất lượng phần mềm của Tester thì Tester nên ghi rõ phần này.
- Các bước tái hiện: ghi thành các bước rõ ràng, mỗi bước tương ứng với một thao tác cụ thể.
- Trạng thái của Bug: Khi Tester vừa tạo Bug report -> trạng thái của Bug là “New”. Sau đó sẽ có các trạng thái tương ứng như: Resolved – Bug đã được fix; Done – Bug đã được Tester test; Reopen – Sau khi Dev fix, Tester re-test vẫn còn lỗi;…
- Mức độ ưu tiên của Bug: 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. Trường hợp Bug chỉ gặp trên 1 số máy cụ thể, hoặc có độ ưu tiên thấp thì nên đánh độ ưu tiên của Bug thấp để xử lý sau.
- 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 fix
- Ngày hết hạn: Ngày kết thúc việc sửa thực tế
=> Đừng bỏ qua: Test report là gì? Phải làm sao để viết test report tốt?
Những thủ thuật để thực hiện hiệu quả log bug là gì?
Để thực hiện hiệu quả việc log bug (ghi chú lỗi) trong quá trình kiểm thử phần mềm, bạn có thể áp dụng những thủ thuật sau:
- Chụp ảnh lại ngay khi phát hiện lỗi để dễ dàng mô tả cho đội ngũ dev, để tránh trường hợp Bug khó tái hiện thì ta nên chụp ngay lại ảnh màn hình lưu lại để báo cáo sau khi xác nhận Bug.
- Thực hiện mô tả chi tiết lỗi và sự nghiêm trọng khi phát sinh lỗi: Mô tả chi tiết về môi trường kiểm thử và các bước đã thực hiện trước khi gặp lỗi.
- Xác định tầm quan trọng của lỗi này và xác định mức độ ưu tiên: Đánh giá nghiêm trọng của lỗi và ưu tiên sửa chữa dựa trên ảnh hưởng đến người dùng và mức độ cần thiết của sự sửa chữa.
- Xác nhận lại một lần nữa trước khi log bug: để không bị log Bug “nhầm” thì trước khi báo cáo nên kiểm tra xem đó có chính xác là Bug hay không 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 …và tự tái hiện Bug 3 lần trước khi báo cáo.
- Viết tóm tắt, báo cáo log bug một cách rõ ràng: Đây là phần quan trọng chỉ sau phần tiêu đề. Nên mô tả lỗi ngắn gọn. Các bước nên đánh thứ tự 1-2-3…, mỗi step chỉ mô tả một hành động, không viết dài quá. Mục tiêu là khi đưa Bug report cho một người không biết gì thực hiện theo các mô tả có thể tái hiện được Bug đó.
Trên đây, Daotaotester đã giúp cho bạn hiểu log bug là gì? Tầm quan trọng và cách viết report log bug hiệu quả? Mong rằng các tester sẽ cảm thấy hữu ích và áp dụng những kiến thức trên vào công việc của mình một cách tốt nhất?