Tóm tắt nội dung
Trong quá trình kiểm thử phần mềm, Log bug là một công việc cơ bản, thường xuyên nhưng đóng vai trò vô cùng quan trọng đối với một Tester/QA. Tuy nhiên với nhiều người mới thì có lẽ đây vẫn là một khái niệm mơ hồ, bài viết này sẽ giúp bạn hiểu rõ hơn về log bug, cách log bug hiệu quả cũng như những lưu ý trong quá trình phát triển phần mềm.
Log bug là gì?
Log bug còn được gọi là ghi nhật ký lỗi, là quá trình ghi lại và giám sát các lỗi hoặc sự cố trong quá trình phát triển, thử nghiệm phần mềm. Nó bao gồm việc mô tả chi tiết về lỗi hoặc sự cố, cách tái hiện lại vấn đề và các thông tin liên quan, như thời gian xảy ra, môi trường, phiên bản phần mềm và người báo cáo. Các phần mềm phức tạp được xây dựng bằng nhiều dòng mã thường có xu hướng có hàng trăm, thậm chí hàng ngàn lỗi.
Việc log bug giúp cho các lỗi và sự cố được giải quyết kịp thời và chính xác, đồng thời cũng cung cấp thông tin quan trọng giúp cải thiện chất lượng sản phẩm, quy trình phát triển và định hướng phát triển sản phẩm trong tương lai.
Khi log một bug, người kiểm thử cần phải đảm bảo giúp cho người đọc có thể hiểu được các vấn đề xảy ra, sau đó nhanh chóng xử lý bug tránh lãng phí thời gian, cuối cùng là xác nhận lại với kiểm thử viên.
Tại sao Log bug lại quan trọng?
Việc log bug là một phần không thể thiếu trong quá trình phát triển phần mềm, nó có vai trò quan trọng như sau:
- Nâng cao chất lượng sản phẩm: Log bug giúp phát hiện và sửa lỗi sớm, đảm bảo rằng phần mềm đáp ứng đầy đủ các yêu cầu và tiêu chuẩn chất lượng.
- Tiết kiệm thời gian và chi phí: Nếu phát hiện lỗi ở giai đoạn đầu, sẽ tiết kiệm được nhiều thời gian và chi phí trong quá trình phát triển và kiểm thử phần mềm sau này.
- Tăng sự hài lòng của khách hàng: Khách hàng sẽ không muốn sử dụng phần mềm không ổn định hoặc có quá nhiều lỗi. Khi các lỗi được giải quyết kịp thời, khách hàng sẽ có sự hài lòng và tin tưởng hơn vào sản phẩm.
- Cải thiện quy trình phát triển phần mềm: Log bug cung cấp thông tin về các lỗi phát hiện được trong quá trình phát triển phần mềm. Dựa trên thông tin đó, nhóm phát triển có thể cải thiện quy trình phát triển và kiểm thử để giảm thiểu các lỗi trong tương lai.
- Định hướng phát triển sản phẩm: Các lỗi và sự cố log bug cũng cung cấp thông tin về các tính năng phần mềm cần cải tiến hoặc thêm mới để đáp ứng được nhu cầu của người dùng.
Cách Log bug hiệu quả qua các thành phần của Bug
Để có thể log bug hiệu quả thì bạn cần phải nắm được và vận dụng các thành phần sau của một bug:
Tracker
Việc đầu tiên khi log bug là bạn cần chọn lựa tracker là Bug để có thể dễ dàng quản lý, theo dõi, trích xuất ra danh sách các bug hiện có và không bị lẫn với các loại task khác.
Subject
Là tiêu đề của vấn đề, nó nên ngắn gọn nhưng mô tả chính xác vấn đề mà người dùng đang gặp phải. Đây cũng là một yếu tố cần được chú trọng, thường sẽ có nhiều bug trong một dự án được triển khai trong thời gian dài. Việc có một Subject tốt sẽ giúp cho các thành viên trong dự án có thể tìm kiếm bug một cách dễ dàng, tranh bị trùng lặp bug.
Một vài lưu ý đối với Subject:
- Subject phải dễ hiểu, ngắn gọn và bao gồm các từ khóa quan trọng và dễ nhớ.
- Để dễ dàng phân biệt bug ở các màn hình khác nhau thì Subject nên đính kèm thêm tag. Khi log bug cần chú ý xem bug đó là bug về giao diện hay bug ở web, validate data, android hay iOS, bên cạnh đó cũng cần chú ý bug đó ở màn hình nào. Việc thêm các tag này sẽ giúp việc tìm kiếm và phân chia công việc trở nên dễ dàng hơn.
Description
Đây là phần mô tả chi tiết về vấn đề, bao gồm các bước để tái hiện lại vấn đề và các thông tin liên quan như ngày xảy ra, môi trường và phiên bản phần mềm. Description là phần vô cũng quan trọng khi log bug, nó giúp cho các nhà phát triển tái hiện bug dễ dàng và chính xác
- Summary: Đây là phần mô tả chi tiết của bug chỉ ra Bug xảy ra ở đâu? Nguyên nhân gì dẫn đến bug? Hậu quả của bug như thế nào?
- Pre-condition: Đây là phần tiền điều kiện để có thể tái hiện được bug
Ví dụ: Khi test trường hợp đăng nhập thành công vào hệ thống thì tiền điều kiện của case này sẽ là: người dùng đã có account được đăng ký thành công trước đó. - Step to re-produce: Các bước chi tiết để tái hiện bug.
- Actual result: Kết quả trả về thực tế sau khi thực hiện các bước ở phần Step to re-produce
- Expected result: Kết quả mong muốn trả về sau khi thực hiện các bước ở phần Step to re-produce.
- Content: Bug xảy ra trên môi trường nào, version bao nhiêu.
- Attachment: Đính kèm link hoặc tên files như hình ảnh, mp3, gif,… tái hiện bug để nếu đọc xong phần Step to re-produce dev vẫn không hiểu thì có thể xem thêm phần tài liệu đính kèm để hiểu về bug.
Status
Đây là trạng thái của bug, ví dụ như mới, đang chờ xử lý, đang được xử lý hoặc đã được giải quyết. Khi log bug mới, trạng thái mặc định của bug sẽ là New.
Priority
Đây là mức độ ưu tiên của bug, xác định mức độ nghiêm trọng của bug và độ ưu tiên của việc giải quyết nó. Khi bug xảy ra, bạn có thể đánh giá độ ưu tiên xử lý của lỗi để có thể gán cho nó trạng thái tương ứng phù hợp. Với hệ thống quản lý Redmine thì có 5 mức độ ưu tiên xử lý là: Low, Normal, High, Urgent, Immediate.
Assignee
Đây là người được giao nhiệm vụ giải quyết vấn đề. Khi biết chắc lỗi này do ai xử lý bạn có thể trực tiếp giao phó cho nhà phát triển đó để họ nhận bug và xử lý nhanh chóng hoặc bạn có thể giao cho leader, sau đó leader sẽ giao lại cho nhà phát triển, ngoài ra bạn cũng có thể để trắng phần này, sau khi bạn log bug lên hệ thống, nhà phát triển sẽ vào xem task nào mình phụ trách và tự giao cho mình.
Target version
Đây là phiên bản phần mềm mà bug sẽ được giải quyết trong đó.
Bug Severity
Đây là mức độ nghiêm trọng của bug, xác định mức độ ảnh hưởng của vấn đề đến tính năng của phần mềm và mức độ ưu tiên của việc giải quyết vấn đề. Đối với hệ thống quản lý Redmine thì có 5 mức độ ưu tiên là: Blocker, Critical, High, Medium, Low.
Những vấn đề thường gặp khi log bug
Ngoài những vấn đề về thành phần cần thiết của một phần mềm Log Bug như đã trình bày ở trên, còn có những vấn đề khác có thể gặp phải khi log bug trong phát triển phần mềm, bao gồm:
Không có sự thống nhất về tiêu chuẩn log bug
Điều này có thể xảy ra khi mỗi thành viên trong đội phát triển có thể log bug theo cách riêng của họ. Điều này dẫn đến khó khăn trong việc đánh giá và phân loại các vấn đề, cũng như khó khăn trong việc quản lý và giải quyết các vấn đề.
Không đủ kiến thức và kỹ năng để log bug
Việc log bug không chỉ đơn giản là ghi lại các thông tin liên quan đến vấn đề mà còn yêu cầu kiến thức và kỹ năng phân tích, đánh giá, và phân loại các vấn đề. Nếu thành viên trong đội phát triển thiếu kinh nghiệm và kiến thức cần thiết, họ có thể ghi thiếu hoặc không ghi đầy đủ thông tin, làm cho việc giải quyết vấn đề trở nên khó khăn.
Chậm trễ trong việc log bug
Việc ghi lại và báo cáo các vấn đề liên quan đến phát triển phần mềm là một công việc quan trọng. Nếu việc log bug không được thực hiện kịp thời, các vấn đề có thể trở nên nghiêm trọng hơn và gây ra các vấn đề khác. Việc chậm trễ trong log bug cũng có thể ảnh hưởng đến quy trình phát triển phần mềm và làm chậm tiến độ dự án.
Cách đánh giá mức độ nghiêm trọng của bug
Mức độ nghiêm trọng của bug thường được đánh giá dựa trên các yếu tố sau:
- Ảnh hưởng đến tính năng: Bug ảnh hưởng đến tính năng quan trọng của phần mềm sẽ được đánh giá là nghiêm trọng hơn so với bug ảnh hưởng đến các tính năng không quan trọng.
- Tần suất xảy ra: Bug xảy ra thường xuyên và ảnh hưởng nhiều người dùng sẽ được đánh giá là nghiêm trọng hơn so với bug xảy ra ít và ảnh hưởng một số người dùng nhỏ.
- Độ ưu tiên: Bug được đánh giá là nghiêm trọng hơn nếu nó ảnh hưởng đến tính năng quan trọng hoặc nếu có ảnh hưởng đến người dùng quan trọng hoặc số lượng người dùng lớn.
- Khả năng phục hồi: Bug không thể phục hồi được hoặc rất khó để phục hồi sẽ được đánh giá là nghiêm trọng hơn so với bug có thể phục hồi dễ dàng.
- Độ ảnh hưởng: Bug ảnh hưởng đến nhiều tính năng của phần mềm hoặc gây ra sự cố lớn sẽ được đánh giá là nghiêm trọng hơn so với bug ảnh hưởng đến một tính năng cụ thể.
Xem thêm: Bug là gì? Nguyên nhân gây ra bug
Những lưu ý khi log bug
Về yếu tố tâm lý
Có thể nói tìm ra bug là niềm vui của Tester nhưng là nỗi buồn đối với developer, do đó khi tìm ra bug không nên ra lệnh cho các developer phải thừa nhận và fix bug. Hãy đóng góp với tinh thần giúp cho dự án ngày càng hoàn thiện và có chất lượng tốt nhất khi đến tay người dùng.
Cần tránh log trùng bug
Có rất nhiều Tester cho một dự án do đó đối với mỗi bộ testcase có những lỗi trước đó đã log và đã được fix tuy nhiên đến giai đoạn này bug lại xảy ra hoặc bug đã được log nhưng tester quên note lại vào file testcase. Do đó cần đảm bảo bug của bạn không trùng với một bug bất kỳ nào trước đó.
Ngoài ra ta có thể lên tool quản lý lỗi (Redmine) để search các key liên quan đến bug cần log xem bug đã đc log hay chưa. Nếu phát hiện bug bị log trùng thì comment vào bug là bug bị duplicate, duplicate vs bug nào thì sẽ gắn kèm theo link của bug đó sau đó sẽ chuyển bug về trạng thái close.
Nên tập trung vào một vấn đề
Đối với mỗi một bug được log lên hệ thống quản lý lỗi thì khi test hệ thống bạn cần phải cố gắng chỉ tập chung vào một vấn đề cụ thể gặp phải. Không nên gộp chung nhiều vấn đề vào một bug, điều này sẽ khiến vấn đề trở nên rắc rối và khó khăn trong việc xử đối với developer.
Quản lý bug
Trước và sau khi log bug lên hệ thống thì bạn cần phải trao đổi với developer để đảm bảo nắm được bug đó, tránh bị sót khi xử lý.Log bug xong bạn cũng nên note lại ID bug và file test checklist/ test case để có thể kiểm soát bug một cách dễ dàng nhé!
Đảm bảo tính chính xác và đồng bộ của thông tin
Hãy đảm bảo rằng các thông tin liên quan đến bug đều được ghi lại chính xác và đồng bộ để tránh nhầm lẫn và tránh làm mất thời gian khi giải quyết bug.
Như vậy, việc log bug là một công việc quan trọng trong quá trình phát triển phần mềm, đóng vai trò quan trọng trong việc cải thiện chất lượng phần mềm và đảm bảo sự hài lòng của khách hàng. Trên đây là những thông tin chi tiết cho bạn về Log bug cũng như cách thực hiện hiệu quả. Mong rằng những thông tin trên hữu ích và nếu bạn đang muốn bắt đầu với công việc Tester thì có thể tham khảo Khóa học Tester cho người mới bắt đầu nhé!
