Log Bug là công việc hàng ngày mà các QA, Tester đều phải thực hiện. Tuy nhiên không phải ai cũng có thể xử lý báo cáo một cách nhanh gọn và hiệu quả. Chính điều này đã tạo ra một số rào cản cho những bạn mới bước chân vào nghề kiểm thử, khiến họ gặp không ít khó khăn khi bắt đầu với một công việc mới, môi trường mới. Vậy, có cách nào để tối ưu việc log bug hàng ngày hay không? Câu trả lời là có và đã được trung tâm tester Hà Nội bật mí trong nội dung dưới đây.
Log bug là công việc gì?
Log bug có thể hiểu đơn giản việc báo cáo mô tả lỗi hay còn gọi là Bug report. Mục đích chính là để các bộ phận phát triển phần mềm có thể dễ dàng tìm kiếm nguyên nhân và sửa chữa kịp thời. Đây là công việc hàng ngày mà các Tester cần thực hiện. Họ có thể làm thủ công hoặc sử dụng các phần mềm hỗ trợ quản lý tasks như Jira, Redmine, Gitlab…
Các tester sẽ phải test phần mềm dựa trên các kịch bản thử nghiệm để chắc chắn rằng sản phẩm sẽ không bị lỗi trước khi đến tay khách hàng. Và khi phát hiện điểm chưa ổn, họ sẽ phải mô tả chi tiết rồi gửi cho Team lead để thẩm định, đánh giá trước khi bàn giao cho bộ phận phát triển sửa chữa. Công việc này đòi hỏi sự tỉ mỉ, chỉn chu để tránh các xung đột không cần thiết.
Cấu trúc một log bug cơ bản
Các log bug thường được triển khai thông qua các hệ thống quản lý thông dụng như Redmine hay Jira. Để giúp bạn hiểu rõ hơn, dưới đây là template lý tưởng khi tạo mới các bug ticket. Chúng tôi đã lấy một ví dụ điển hình trên Jira – Trình quản lý được sử dụng phổ biến nhất hiện nay.
- Summary (Tóm tắt vấn đề)
- Expected result (Kết quả mong đợi)
- Actual result (Kết quả thực tế)
- Environment (Môi trường test)
- Hardware: <content>
- Software: <content>
- Precondition (Tái tạo bug)
- Reproduction Steps (Tái hiện bug)
- Step 1: <content> => Result of Step 1 <OK/NG> <further note>
- Step 2: <content> => Result of Step 2 <OK/NG> <further note> …
- Step n: <content> => Result of Step n <OK/NG> <further note>
- Recover action (Khôi phục trạng thái)
- Remarks (Lỗi tương tự)
- Version (Phiên bản thử nghiệm)
Kinh nghiệm log bug của chuyên gia
Log bug là một công việc nhàm chán mà bạn sẽ phải làm hàng ngày. Vậy, viết như thế nào cho đúng và phải làm sao để mang lại hiệu quả cao nhất? Dưới đây là chia sẻ của thầy cô với nhiều năm kinh nghiệm thực chiến trong các dự án thực tế. Chắc chắn sẽ có ích cho những ai đang bắt đầu với sự nghiệp kiểm thử.
Kiểm tra kỹ lưỡng để chắc chắn ticket type phải là Bug hoặc Defect
Đây là một yêu cầu quan trọng cần thực hiện log bug. Cụ thể thì tester cần đảm bảo để khi cần thì có thể dễ dàng trích xuất mà không nhầm lẫn với các nhiệm vụ khác. Điều đó sẽ giúp tối ưu quy trình cũng như tiết kiệm được kha khá thời gian.
Viết log bug với Ticket Name dễ hiểu, dễ tìm kiếm
Để quá trình fix bug được diễn ra thuận lợi thì bạn cần phải chú trọng vào Ticket Name. Trong đó, Tester cần đảm bảo:
- Ticket Name là một câu hoàn chỉnh với đủ thành phần chủ vị. Giúp Dev dễ dàng đọc hiểu và xác định được vấn đề phát sinh.
- Nên sử dụng các từ khóa quan trọng, dễ nhớ để đặt ticket name. Điều đó sẽ giúp các lập trình việc dễ dàng tìm kiếm.
- Gắn thêm Tag để phân biệt bug. Đây cũng là một tuyệt chiêu giúp việc tìm kiếm và sửa lỗi được diễn ra nhanh chóng, dễ dàng hơn bao giờ hết. Đó có thể là bug [LOGIC], bug [GUI], bug [FRONTEND], [BACKEND], bug của [WEB] hay [ANDROID] hay [IOS] app.
Viết Summary ngắn gọn dễ hiểu
Hãy tóm gọn nội dung Log Bug trong khoảng 1-3 dòng để giúp bộ phận phát triển phần mềm có thể tìm hiểu nhanh về các lỗi sai và đưa ra phản ứng nhanh nhạy. Điều này sẽ có ích rất nhiều cho các giai đoạn quan trọng khi có nhiều dự án diễn ra cùng lúc. Hoặc trong dự án khi có sự tham gia của nhiều hơn 1 Tester/QA để kiểm thử phần mềm.
Viết Expected Result hợp lý
Phần kết quả mong đợi cần phải dựa vào yêu cầu sản phẩm để đưa ra định hướng cụ thể cho việc sửa lỗi. Tester hãy xem thật kỹ Requirement của khách hàng và viết thật rõ ràng, gãy gọn, dễ hiểu. Nếu phần yêu cầu không được cụ thể, vậy thì bạn có thể đánh giá dựa trên quan điểm người dùng. Sau đó đưa ra kết luận ở một mức mà cả khách hàng và dev đều cảm thấy đồng tình.
Mô tả chi tiết Actual Result
Viết Actual Result càng chi tiết thì càng hỗ trợ tốt cho đội thiết kế khi triển khai fix bug. Tester nên dựa vào Expected Result để viết mới nhằm tránh sự nhầm lẫn giữa 2 phần này. Bên cạnh đó, các Actual Result trên nhiều màn hình cũng cần được tách ra và ghi chú riêng lẻ. Điều này sẽ rất có ích cho quá trình sửa lỗi của các lập trình viên.
Liệt kê đầy đủ Environment
Việc test được thực hiện trên các môi trường nào cũng cần được viết đầy đủ, chi tiết trong log bug. Đặc biệt, tester cần mô tả rõ để việc kiểm tra, sửa lỗi diễn ra nhanh chóng nhất. Trong đó có 2 yếu tố cơ bản bạn cần lưu ý:
- Hardware (Phần cứng): Việc tái hiện bug được thực hiện trên máy nào, mobile hay laptop. Bug xảy ra khi chạy trên màn hình có kích cỡ ra sao, cấu hình máy như thế nào…
- Software (Phần mềm): Phần mềm được chạy thử và test trên hệ điều hành nào, có xảy ra trên các trình duyệt cụ thể hay không.
Precondition cũng cần được quan tâm
Phần này cũng phải được viết chi tiết để Dev dễ dàng hình dung được lỗi phần mềm. Trong đó, tester có thể trả lời một số câu hỏi cơ bản như:
- Trước khi test ra bug, bạn đã thực hiện trên môi trường nào?
- Bạn đăng nhập admin, member thì gặp bug hay các roll account khác?
- Khi phát hiện ra bug, bạn có sử dụng thêm chức năng nào hay không?
Tái hiện Bug chi tiết qua Reproduction Steps
Mô tả lại một cách chi tiết, chính xác trình tự các bước tìm ra bug. Đi kèm với đó là đầy đủ các thông tin cần thiết để dev dễ dàng xác định nguyên nhân xảy ra lỗi. Ở mỗi bước, tester sẽ cần confirm kết quả kèm theo những biểu hiện khác mà bạn cho là quan trọng (nếu có).
Điều tra Recover Actions
Trong nhiều trường hợp, việc tìm kiếm những hành động giúp khôi phục trạng thái bình thường hoặc làm bug biến mất tạm thời sẽ là chìa khóa để quá trình sửa lỗi được diễn ra nhanh chóng hơn. Đó là lý do tại sao các tester cũng nên giành kha khá thời gian để mày mò thêm ở bước này. Sau đó, ghi chi tiết, cụ thể trong log bug.
Chỉ ra các lỗi tương tự trong Remarks
Thực tế là một đoạn code lỗi có thể gây ra bug ở nhiều nơi khác nhau. Do đó việc ghi lại các biểu hiện tương tự ở những địa điểm khác cũng rất cần thiết. Tester cần ghi chú cụ thể ở phần Remarks khi thấy sự không đồng nhất giữa các môi trường. Để từ đó phát hiện tất cả lỗi sai, kịp thời sửa chữa trước khi bàn giao phần mềm.
Ghi chi tiết các Version sản phẩm phát hiện bug
Tester cần ghi cụ thể, chi tiết để người quản lý có thể xác định được quá trình tiến hóa của sản phẩm một cách dễ dàng. Ở phần này, bạn không cần viết quá nhiều, chỉ cần đúng, đủ là được. Trình bày gạch ý nếu thực hiện test trên nhiều version (Phiên bản).
Lưu ý quan trọng khi thực hiện log bug
Muốn log bug giỏi như một chuyên gia thì bạn cần lưu ý thêm vài điều cơ bản sau:
- Đối với team có ít thành viên thì có thể lược bớt hoặc thu gọn lại quy trình log bug bên trên cho phù hợp.
- Khi tìm ra bug, hãy chia sẻ và góp ý theo tinh thần đóng góp cho các dự án được hoàn thiện hơn. Điều đó sẽ giúp tránh xảy ra các xung đột với Dev và mang đến hiệu quả công việc cao hơn.
- Kiểm tra thật kỹ lưỡng để đảm bảo tránh trùng bug khi thực hiện viết log.
- Khi log bug, chỉ nên tập trung vào một vấn đề và chia nhỏ ra. Không nên gộp nhiều lỗi cùng một bug vì có thể khiến việc sửa chữa gặp nhiều khó khăn hơn.
- Khi log bug xong cần báo cáo và chuyển trạng thái cho phù hợp. Tạo sự đồng bộ trong quy trình làm việc và tránh xảy ra sai sót không đáng có.
- Nên có sự trao đổi giữa Tester/QA với Dev trước khi thực hiện log bug.
Với những chia sẻ trên đây, chắc chắn các tester của chúng ta đã bỏ túi được thêm nhiều kinh nghiệm log bug hiệu quả. Nếu muốn tìm hiểu các kiến thức khác bổ ích hơn, vui lòng truy cập vào website của chúng tôi.
