Tìm bug và viết báo cáo về bug phát hiện là một trong những công việc quen thuộc của mọi kiểm thử viên. Một bug được báo cáo hiệu quả thì cơ hội được sửa chữa của nó sẽ cao hơn. Report bug là một kỹ năng, và để trở thành một kiểm thử viên chuyên nghiệp thì bạn cần nắm được kỹ năng này. Bài viết này mình sẽ giới thiệu về quy trình viết bug report cũng như các mẹo để có một report hiệu quả và chuyên nghiệp. Nhưng trước hết chúng ta hãy tìm hiểu để biết bug report là gì nhé.
Bug Report Là Gì?
Bug report là một tài liệu bao gồm các thông tin cụ thể về cái gì đang sai và cái gì cần được sửa trong phần mềm hoặc trên một trang web. Báo cáo này mô tả các yêu cầu hoặc đặc tả cho một sự cố phần mềm. Nó cho phép nhà phét triển hiểu được những gì sai và cách khắc phục.
Quy Trình Log Bug
Hoạt động kiểm thử nhằm góp phần cải thiện chất lượng của các ứng dụng và phần mềm. Trong trường hợp phát hiện bug trong phần mềm, nó cần được thông báo cho các nhà phát triển để sửa chữa, theo dõi trạng thái hiện tại của bug, tìm hiểu xem có bất kỳ lỗi tương tự nào được tìm thấy trong bước kiểm tra cuối không.
Một quy trình log bug hiệu quả cần bao gồm các bước sau đây:
- Chụp lại bằng chứng về bug Trong một bug report việc đính kèm ảnh, video bằng chứng về bug là cách trực quan nhất để giúp nhà phát triển sớm xác định được lỗi. Một số bug có tần số xuất hiện thấp nên khó tái hiện thì việc ghi lại bằng chứng còn giúp nhà phát triển suy đoán tốt hơn về cách mà lỗi ảnh hưởng và họ cần phải làm gì tiếp theo.
- Điền các thông tin liên quan tới bug Những thông tin cần thiết trong một report bug như Test Lead, Severity, Detected By, Project, Status, Bug ID và Assigned …. Bug ID thường được tạo tự động bởi công cụ quản lý bug, tuy nhiên nếu bạn quản lý bug bằng file lưu trữ như word, excel,… thì hãy đảm bảo giá trị này là duy nhất để tránh sự nhầm lẫn với những bug report đã tạo trước đó.
- Mô tả về bug
- Tiêu đề bug: Tiêu đề bug được đọc thường xuyên hơn bất kỳ phần nào khác trong báo cáo. Nó sẽ giải thích tất cả về những gì đi kèm với lỗi. Tiêu đề bug phải ngắn gọn nhưng cũng đủ gợi ý để người đọc có thể hiểu được.
- Môi trường: Cần thiết phải đề cập tới thông tin về môi trường gây ra bug như trình duyệt, phiên bản hệ điều hành, kích thước màn hình, tên thiết bị kiểm thử, v.v… Đó là cách tốt nhất để truyền đạt cách tái hiện bug. Nếu không tái hiện chính xác môi trường, phần mềm có thể hoạt động khác đi và lỗi ở phía người kiểm thử có thể không lặp lại ở phía nhà phát triển. Vì vậy, tốt nhất là đề cập rõ ràng về môi trường mà lỗi được phát hiện.
- Các bước tái hiện bug Đề cập rõ ràng các bước để tái hiện bug. Các bước này cần phải bao gồm các hành động có thể gây ra bug. Không đưa ra những tuyên bố chung chung. Hãy cụ thể các bước để làm theo.
- Example:
- Go to the homepage https://testviewpoint.com/
- Click on CONTACT tab
- Input a valid data as below: YOUR NAME = Tester1, YOUR EMAIL = test123@gmail.com, SUBJECT = Valid case
- Click on Submit button
- Example:
- Kết quả kỳ vọng và thực tế: Đây là chỗ mô tả những gì bạn mong đợi sẽ xuất hiện trên màn hình và những gì đã xuất hiện với nhà phát triển của bạn. Điều này sẽ giúp bất kỳ nhà phát triển nào cũng có được bức tranh rõ ràng về những gì được mong đợi và những gì không.
- Example:
- Expected result: An message of successful submission should be displayed. At the same time, the system should be successfully send mail to the specifed email address.
- Actual result: An error message displayed and there’s not any mail sent to the specified email address.
- Example:
- Tần suất tái hiện bug: Một số bug có thể không xuất hiện thường xuyên, nên thông tin về tần suất xuất tái hiện bug là một thông tin bổ sung hữu ích để nhà phát triển phán đoán được tình hình bug.
- Đính kèm bằng chứng về bug: Chụp ảnh màn hình về trường hợp lỗi với chú thích phù hợp để làm nổi bật lỗi. Đánh dấu các thông báo lỗi không mong muốn bằng màu đỏ nhạt. Điều này thu hút sự chú ý đến khu vực cần thiết. Một bức tranh đáng giá ngàn lời nói. Vậy nên đừng quên đính kèm bằng chứng về bug vào báo cáo của bạn nhé.
Những Mẹo Để Viết Một Report Hiệu Quả
- Ghi lại bằng chứng ngay Trong quá trình kiểm tra sản phẩm, khi phát hiện bất cứ nghi ngờ gì cần ghi lại bằng chứng ngay bằng cách chụp màn hình, record các bước … Bởi một số bug rất khó tái hiện, hoặc bug chỉ xuất hiện khi bạn thực hiện một số thao tác cụ thể nào đó.
- Tái hiện bug trước khi viết bug report Đảm bảo chắc chắn nghi ngờ của bạn là bug chứ không phải là lỗi do một thao tác sai nào đó trong quá trình kiểm thử, nghi ngờ của bạn cần được tái hiện lại một cách rõ ràng. Đây là cũng một cách quan trọng để bạn có thể mô tả chính xác và rõ ràng các bước tái hiện trong report của mình.
- Xác nhận bug đã được phát hiện trước đó hay chưa Một dự án lớn, quá trình kiểm thử có thể được thực hiện bởi nhiều tester, do đó trong một số trường hợp bug đã được phát hiện, report từ trước đó. Hãy xác minh với những người liên quan, hoặc kiểm tra trong kho bug chung để đảm bảo bug của bạn chưa tồn tại trước đó.
- Viết tiêu đề bug rõ ràng Viết thật ngắn gọn, rõ ràng, đủ ý. Điều quan trọng là phải nắm bắt được bản chất của lỗi khi đọc tiêu đề. Một tiêu đề rõ ràng cũng giúp người quản lý giao phó đến đúng nhà phát triển.
- Mỗi lỗi một report Mỗi lỗi một report có thể giúp tránh trùng lặp, nhầm lẫn và cũng dễ dàng hơn cho nhà kiểm thử xác minh sau khi bug được sửa chữa. Nếu mô tả quá nhiều lỗi trong một report, một số có thể bị bỏ qua, hoặc bị trùng lặp ở những report khác.
- Kiểm tra lỗi đó trên một vài module tương tự Hầu hết các nhà phát triển sử dụng cùng một đoạn code cho các module khác nhau. Do đó nhiều khả năng lỗi trong một module sẽ xảy ra ở một module tương tự khác. Đảm bảo bạn đã bao phủ được hết các chỗ nghi ngờ sẽ xảy ra bug tương tự.
- Xem lại bug report cẩn thận Đọc kỹ lại bug report trước khi ấn vào nút “Submit”. Đảm bảo các thông tin quan trọng đã được ghi lại đầy đủ, kiểm tra lại tất cả các cụm từ, đảm bảo chúng được viết là rõ ràng, không mơ hồ để tránh hiểu sai.
- Sử dụng văn phong lịch sự Sử dụng từ ngữ lịch sự trong báo cáo của bạn. Bạn đã làm rất tốt – đã tìm được bug, nhưng đừng chỉ trích nhà phát triển theo cách này.
Kết Luận
Hầu hết người kiểm thử không thích viết báo cáo vì nghĩ chúng làm mất thời gian của họ. Nhưng bug report là tài liệu rất quan trọng và phải được viết đúng cách. Nó kết nối nhà kiểm thử, nhà phát triển và người quản lý, là tài liệu quan trọng để theo dõi quá trình sửa bug, đánh giá chất lượng sản phẩm, cũng như là tài liệu tham khảo sau này. Viết bug report tốt giúp công ty bạn tiết kiệm tài nguyên cũng như tạo mối quan hệ tốt giữa kiểm thử viên và nhà phát triển phần mềm.