Tại sao cần một Báo cáo lỗi tốt?
Nếu báo cáo lỗi của Tester chính xác, thì khả năng các lỗi đó được sửa sẽ cao hơn và sẽ không mất nhiều thời gian giải thích bug cho developer. Nếu Tester không báo cáo lỗi chính xác, thì developer rất có thể sẽ không sửa được lỗi do không thể tái hiện được.
Vì vậy, việc sửa lỗi phụ thuộc vào mức độ hiệu quả của báo cáo lỗi. Báo cáo lỗi không có gì khác, đơn giản nó là một kỹ năng, bài biết sẽ hướng dẫn và giải thích cách để đạt được kỹ năng này.
Chất lượng của một báo cáo lỗi tốt
Bất kỳ ai cũng có thể viết báo cáo lỗi. Nhưng không phải ai cũng có thể viết một báo cáo lỗi hiệu quả. Làm cách nào để phân biệt được Báo cáo lỗi tốt hay không tốt? Rất đơn giản, hãy áp dụng các đặc điểm và kỹ thuật sau để báo cáo lỗi.
Đặc điểm và Kỹ thuật
1) Số/id Lỗi được chỉ định rõ ràng: Luôn chỉ định một “số/id lỗi” duy nhất cho mỗi báo cáo lỗi. Điều này sẽ giúp bạn xác định bản báo cáo lỗi. Nếu bạn đang sử dụng bất kỳ công cụ báo cáo lỗi tự động nào thì “số/id lỗi” duy nhất này sẽ được tạo tự động mỗi khi bạn thực hiện báo cáo lỗi.
2) Có thể tái hiện: Nếu lỗi của bạn không thể tái hiện, thì nó sẽ không bao giờ được sửa.
Bạn nên đề cập rõ ràng các bước để tái hiện lỗi. Đừng giả định hoặc bỏ qua bất kỳ bước tái hiện nào. Lỗi được mô tả từng bước sẽ rất dễ tái hiện và dĩ nhiên nó cũng dễ dàng được sửa hơn.
3) Hãy cụ thể: Đừng viết lan man, dài dòng. Hãy cụ thể và đi thẳng vào vấn đề. Cố gắng tóm tắt vấn đề bằng các từ tối giản nhưng theo cách hiệu quả. Không kết hợp nhiều vấn đề ngay cả khi chúng có vẻ giống nhau. Vấn đề khác nhau thì chúng ta sẽ viết riêng thành các báo cáo lỗi khác nhau.
4) Báo lỗi hiệu quả
Báo cáo lỗi là một khía cạnh quan trọng trong Kiểm thử phần mềm. Báo cáo lỗi hiệu quả giúp giao tiếp tốt với nhóm phát triển phần mềm để tránh nhầm lẫn hoặc thông tin bị sai lệch.
Một báo cáo Lỗi tốt phải rõ ràng và ngắn gọn mà không bỏ sót bất kỳ điểm chính nào. Bất kỳ sự thiếu rõ ràng nào cũng dẫn đến sự hiểu lầm và làm chậm quá trình phát triển. Viết và báo cáo lỗi là một trong những lĩnh vực quan trọng nhất nhưng thường bị bỏ qua trong vòng đời kiểm thử (testing life cycle).
Kỹ năng viết báo cáo lỗi tốt là việc rất quan trọng trong việc tìm ra lỗi. Điểm quan trọng nhất mà tester nên ghi nhớ là không sử dụng ngôn từ mang tính chất ra lệnh trong báo cáo. Điều này phá vỡ tinh thần và tạo ra một mối quan hệ công việc không lành mạnh. Chúng ta nên sử dụng ngôn từ mang tính gợi ý.
Đừng cho rằng developer đã phạm sai lầm và do đó bạn có thể sử dụng những từ ngữ khó nghe. Trước khi báo cáo, điều quan trọng không kém là kiểm tra xem lỗi tương tự đã được báo cáo hay chưa.
5) Một lỗi bị lặp lại (Duplicated bug) là một điểm quan trọng trong vòng đời kiểm thử. Hãy kiểm tra toàn bộ danh sách các lỗi đã biết. Đôi khi, các developer có thể không nhận thức được vấn đề và bỏ qua nó cho các bản phát hành trong tương lai. Bạn cũng có thể sử dụng các công cụ như Bugzilla, nó giúp chúng ta tự động tìm kiếm các lỗi trùng lặp. Tuy nhiên, tốt nhất là tìm kiếm thủ công bất kỳ lỗi trùng lặp nào.
Thông tin quan trọng mà báo cáo lỗi phải truyền đạt là “Làm thế nào?” và ở đâu?” Báo cáo phải trả lời rõ ràng chính xác cách thức kiểm thử được thực hiện và lỗi xảy ra ở đâu. Người đọc sẽ dễ dàng tái hiện lỗi và tìm ra lỗi ở đâu.
Hãy nhớ rằng mục tiêu của việc viết báo cáo Lỗi là để cho phép developer hình dung vấn đề. Họ nên hiểu rõ lỗi từ báo cáo Lỗi. Hãy nhớ cung cấp tất cả các thông tin liên quan mà developer cần có.
Ngoài ra, hãy nhớ rằng báo cáo lỗi sẽ được lưu giữ để sử dụng trong tương lai và phải được viết rõ ràng với các thông tin bắt buộc. Sử dụng các câu có ý nghĩa và các từ đơn giản để mô tả lỗi. Đừng dùng những câu khó hiểu làm mất thời gian của người khác.
Báo cáo từng lỗi như một vấn đề riêng biệt. Trong trường hợp có nhiều vấn đề trong một Báo cáo lỗi, bạn không thể “Closed” báo cáo đó trừ khi tất cả các vấn đề được giải quyết.
Do đó, tốt nhất là chia các vấn đề thành các lỗi riêng biệt . Điều này đảm bảo rằng mỗi lỗi có thể được xử lý riêng biệt. Một báo cáo lỗi được viết tốt sẽ giúp developer tái hiện lại lỗi tại thiết bị đầu cuối của họ. Điều này cũng sẽ giúp họ chẩn đoán được vấn đề.
Làm thế nào để báo cáo một lỗi?
Sử dụng mẫu báo cáo Lỗi đơn giản sau:
Đây là một định dạng báo cáo lỗi đơn giản. Nó có thể khác nhau tùy thuộc vào công cụ báo cáo Lỗi mà bạn đang sử dụng. Nếu bạn đang viết báo cáo lỗi theo cách thủ công thì một số trường cần được đề cập cụ thể như số Lỗi – sẽ được chỉ định theo cách thủ công.
- Người báo cáo (Reporter): Tên và địa chỉ email của bạn.
- Sản phẩm(Product): Bạn tìm thấy lỗi này ở sản phẩm nào?
- Phiên bản (Version): Phiên bản sản phẩm, nếu có.
- Thành phần (Component): Đây là các mô-đun phụ của sản phẩm.
- Nền tảng(Platform): Đề cập đến nền tảng phần cứng nơi bạn tìm thấy lỗi này. Các nền tảng khác nhau như ‘PC’, ‘MAC’, …
- Hệ điều hành(Operating system): Đề cập đến tất cả các hệ điều hành mà bạn đã tìm thấy lỗi. Các hệ điều hành như Windows, Linux, Unix, SunOS và Mac OS. Ngoài ra, hãy đề cập đến các phiên bản của hệ điều hành khác nhau như Windows 7, Windows 10,… nếu có.
- Mức độ ưu tiên(Priority): Khi nào một lỗi nên được sửa? Ưu tiên thường được đặt từ P1 đến P5. P1(Immediate) là “sửa lỗi với mức độ ưu tiên cao nhất” và P5 (Low) là “Sửa lỗi khi thời gian cho phép”.
- Mức độ nghiêm trọng (Severity): Điều này mô tả mức độ ảnh hưởng của lỗi đối với một phần hay toàn bộ sản phẩm.
Các loại mức độ nghiêm trọng:
- Blocker: Không thể thực hiện thêm công việc kiểm thử nào.
- Critical: Sự cố ứng dụng, Mất dữ liệu.
- Major: Mất chức năng chính.
- Minor: Mất chức năng phụ.
- Trivial: Một số cải tiến giao diện người dùng.
- Enhancement: Yêu cầu một tính năng mới hoặc một số cải tiến trong tính năng hiện có.
- Trạng thái: Khi bạn log lỗi vào bất kỳ hệ thống theo dõi lỗi nào thì theo mặc định, trạng thái lỗi sẽ là ‘Mới’.
Sau đó, lỗi trải qua các giai đoạn khác nhau như Đã sửa, Đã xác minh, Đã mở lại, Không sửa, ….
- Chỉ định cho ai: Nếu bạn biết developer nào chịu trách nhiệm cho mô-đun cụ thể đã xảy ra lỗi, thì bạn có thể chỉ định developer đó. Nếu không, hãy để trống và Người quản lý sẽ chỉ định lỗi cho developer. Có thể thêm người quản lý vào danh sách CC.
- URL: URL của trang đã xảy ra lỗi.
- Tóm tắt: Một bản tóm tắt ngắn gọn về lỗi, hầu hết trong khoảng 60 từ trở xuống. Đảm bảo rằng bản tóm tắt của bạn phản ánh vấn đề là gì và nó ở đâu.
- Mô tả: Mô tả chi tiết về lỗi.
Sử dụng các trường sau cho mô tả:
- Các bước tái hiện: Rõ ràng, đề cập đến các bước để tái hiện lỗi.
- Kết quả mong muốn: Ứng dụng sẽ hoạt động như thế nào theo các bước nêu trên.
- Kết quả thực tế: Kết quả thực tế của việc chạy các bước trên, tức là hành vi lỗi là gì?
Đây là những bước quan trọng trong báo cáo lỗi. Bạn cũng có thể thêm “Loại báo cáo” làm một trường nữa sẽ mô tả loại lỗi.
- Các loại báo cáo bao gồm:
- Coding error
- Design error
- New Suggestion
- Documentation issue
- Hardware problem
Các thông tin quan trọng trong báo cáo lỗi
1) Số lỗi/id
Số Lỗi hoặc số nhận dạng (chẳng hạn như bug001) giúp báo cáo lỗi và quá trình đề cập đến lỗi dễ dàng hơn nhiều. Developer có thể dễ dàng kiểm tra xem một lỗi cụ thể đã được sửa hay chưa. Nó làm cho toàn bộ quá trình kiểm thử và kiểm thử lại dễ dàng hơn.
2) Tiêu đề lỗi
Tiêu đề lỗi được đọc thường xuyên hơn bất kỳ phần nào khác của báo cáo lỗi. Điều này sẽ giải thích tất cả về những gì đi kèm với lỗi. Tiêu đề Lỗi phải đủ gợi ý để người đọc có thể hiểu được. Tiêu đề lỗi rõ ràng giúp dễ hiểu và người đọc có thể biết lỗi đã được báo cáo trước đó hay đã được sửa.
3) Mức độ Ưu tiên
Dựa trên mức độ nghiêm trọng của lỗi, có thể đặt mức độ ưu tiên cho nó. Một lỗi có thể là một Blocker, Critical, Major, Minor, Trivial, hoặc một gợi ý. Mức độ ưu tiên lỗi có thể được đưa ra từ P1 đến P5 để những lỗi quan trọng được xem trước.
4) Nền tảng/Môi trường
Cấu hình hệ điều hành và trình duyệt là những thông tin cần thiết để báo cáo lỗi được rõ ràng. Đó là cách tốt nhất để truyền đạt cách tái hiện lỗi.
Nếu không có nền tảng hoặc môi trường chính xác, ứng dụng có thể hoạt động khác đi và lỗi ở phía tester có thể không lặp lại ở phía developer. 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.
5) Mô tả
Mô tả lỗi giúp developer hiểu lỗi. Nó mô tả vấn đề gặp phải. Một mô tả kém sẽ tạo ra sự nhầm lẫn và lãng phí thời gian của các developer cũng như tester.
Cần truyền đạt, mô tả rõ. Việc sử dụng các câu hoàn chỉnh luôn hữu ích. Không sử dụng các từ ngữ như “Tôi nghĩ” hoặc “Tôi tin”.
6) Các bước để tái hiện
Một báo cáo lỗi tốt nên đề cập rõ ràng các bước để tái hiện. Các bước này phải bao gồm các hành động có thể gây ra lỗi. Đừng đưa ra những câu từ chung chung. Hãy viết cụ thể các bước để làm theo.
Dưới đây là một ví dụ:
Các bước:
- Chọn sản phẩm Abc01.
- Bấm vào “Thêm vào giỏ hàng”.
- Nhấn “Remove” để xóa sản phẩm khỏi giỏ hàng.
7) Kết quả mong đợi và thực tế
Mô tả Lỗi sẽ không đầy đủ nếu không có kết quả Mong muốn và Thực tế. Cần viết rõ kết quả của việc kiểm thử là gì và người dùng mong muốn điều gì. Người đọc nên biết kết quả chính xác của việc kiểm thử là gì. Cần rõ ràng, đề cập đến những gì đã xảy ra trong quá trình kiểm thử và kết quả là gì.
8) Evidence (Ảnh chụp màn hình/Video)
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 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 số mẹo bổ sung để viết báo cáo lỗi tốt
1) Báo cáo sự cố ngay lập tức
Nếu bạn tìm thấy bất kỳ lỗi nào trong khi kiểm thử, thì bạn không nên đợi để viết báo cáo lỗi chi tiết sau. Thay vào đó, hãy viết báo cáo lỗi ngay lập tức. Điều này sẽ đảm bảo một báo cáo Lỗi tốt và có thể tái hiện. Nếu bạn viết báo cáo Lỗi sau thì sẽ có nhiều khả năng thiếu hoặc quên các bước quan trọng trong báo cáo lỗi.
2) Tái hiện lỗi ba lần trước khi viết báo cáo Lỗi
Lỗi của bạn tìm thấy nên dễ tái hiện. Đảm bảo rằng các bước của bạn đủ để tái hiện lỗi dễ dàng mà không có bất kỳ sự mơ hồ nào.
3) Kiểm tra sự xuất hiện lỗi tương tự trên các mô-đun tương tự khác
Đôi khi developer sử dụng cùng một đoạn mã lệnh cho các mô-đun tương tự khác nhau. Vì vậy, có nhiều khả năng lỗi trong một mô-đun cũng xảy ra trong các mô-đun tương tự khác.
4) Viết một bản tóm tắt lỗi tốt
Tóm tắt lỗi sẽ giúp các developer nhanh chóng phân tích bản chất của lỗi. Một báo cáo chất lượng kém sẽ làm tăng thời gian phát triển và kiểm thử một cách không cần thiết. Hãy nhớ rằng bản tóm tắt lỗi có thể được sử dụng làm tài liệu tham khảo.
5) Đọc lại báo cáo Lỗi trước khi Gửi
Đọc tất cả các câu, từ ngữ và các bước được sử dụng trong báo cáo lỗi. Xem liệu có câu nào tạo ra sự mơ hồ có thể dẫn đến hiểu sai không. Cần tránh những từ hoặc câu gây hiểu lầm để có một báo cáo lỗi rõ ràng.
6) Không sử dụng ngôn ngữ xúc phạm.
Bạn tìm ra lỗi tức là bạn đã làm việc tốt nhưng không sử dụng việc này để chỉ trích developer hoặc bất kỳ cá nhân nào.
Kết luận
Hay tập trung vào viết báo cáo lỗi tốt và dành thời gian cho nhiệm vụ này vì đây là điểm giao tiếp chính giữa tester, developer và người quản lý. Người quản lý nên tạo nhận thức trong nhóm của họ rằng viết một báo cáo Lỗi tốt là trách nhiệm chính của bất kỳ tester nào.
Nỗ lực để viết một báo cáo Lỗi tốt sẽ không chỉ tiết kiệm tài nguyên của công ty mà còn tạo ra mối quan hệ tốt đẹp giữa tester và developer.
Để có năng suất tốt hơn, hãy viết một báo cáo Lỗi tốt hơn.
