- Nhận biết nội dung của báo cáo sự cố [IEEE 829]. (K1)
- Viết một báo cáo sự cố bao gồm các quan sát của một sự cố trong quá trình kiểm thử. (K3)
Chúng ta kết thúc chương quản lý kiểm thử với một chủ đề quan trọng: cách chúng ta có thể lập tài liệu và quản lý các sự cố xảy ra trong quá trình thực hiện kiểm thử. Chúng ta sẽ xem xét những chủ đề nào nên đề cập khi báo cáo sự cố và lỗi. Ở cuối phần này, bạn sẽ sẵn sàng viết một báo cáo sự cố kỹ lưỡng.
Thuật ngữ duy nhất trong phần này: ghi nhật ký sự cố (incident logging).
5.6.1 Báo cáo sự cố là gì và làm cách nào để viết báo cáo tốt?
Khi chạy kiểm thử, bạn có thể quan sát kết quả thực tế khác với kết quả mong đợi. Đây không phải là điều xấu (một trong những mục tiêu chính của kiểm thử là tìm ra vấn đề). Các tổ chức khác nhau có tên khác nhau để mô tả các tình huống như vậy.
Thông thường, chúng được gọi là sự cố (incidents), lỗi (bugs), khiếm khuyết (), vấn đề (problems )hoặc vấn đề (issues).
Nói một cách chính xác, đôi khi chúng ta phân biệt giữa một bên là sự cố và bên kia là khiếm khuyết hoặc lỗi. Sự cố là bất kỳ tình huống nào mà hệ thống thể hiện hành vi đáng ngờ, nhưng chúng ta thường coi sự cố là lỗi chỉ khi nguyên nhân gốc rễ (root cause) là sự cố nào đó trong mục mà chúng ta đang kiểm thử.
Các nguyên nhân khác của sự cố bao gồm cấu hình sai hoặc lỗi của môi trường kiểm thử, dữ liệu kiểm thử bị hỏng, kiểm thử kém, kết quả dự kiến không hợp lệ và lỗi của người kiểm thử. (Tuy nhiên, trong một số trường hợp, chính sách phân loại bất kỳ sự cố nào phát sinh từ thiết kế kiểm thử, môi trường kiểm thử hoặc bất kỳ thứ gì khác dưới sự quản lý cấu hình chính thức đều là một lỗi.) Chúng ta nói về các sự cố để chỉ ra khả năng một hành vi đáng ngờ không nhất thiết là một lỗi thực sự. Chúng ta ghi lại những sự cố này để có hồ sơ về những gì đã quan sát được và có thể theo dõi sự cố cũng như theo dõi những gì đã được thực hiện để khắc phục sự cố.
Mặc dù việc ghi nhật ký sự cố (incident logging) hoặc báo cáo lỗi (defect reporting) là các quy trình và công cụ phổ biến nhất được sử dụng trong các giai đoạn kiểm thử chính thức, độc lập, bạn cũng có thể ghi nhật ký, báo cáo, theo dõi và quản lý các sự cố được tìm thấy trong quá trình phát triển và đánh giá. Trên thực tế, đây là một ý tưởng hay vì nó cung cấp thông tin hữu ích về mức độ các hoạt động phát hiện và loại bỏ lỗi sớm (và rẻ hơn) đang diễn ra.
Tất nhiên, cũng cần một số cách báo cáo, theo dõi và quản lý các sự cố xảy ra tại hiện trường hoặc sau khi triển khai hệ thống. Mặc dù nhiều sự cố trong số này là do lỗi của người dùng hoặc một số hành vi khác không liên quan đến lỗi, nhưng một số phần trăm lỗi thoát khỏi các hoạt động kiểm thử và đảm bảo chất lượng. Phần trăm phát hiện lỗi (so sánh các lỗi hiện trường với kiểm thử lỗi) là một thước đo quan trọng về hiệu quả của quá trình kiểm thử.
Dưới đây là một ví dụ về công thức DDP sẽ áp dụng để tính DDP cho cấp độ kiểm thử cuối cùng trước khi đưa ra thực địa:
Thông thường nhất là tìm thấy các lỗi được báo cáo đối với mã hoặc chính hệ thống. Tuy nhiên, chúng ta cũng đã thấy các trường hợp lỗi được báo cáo dựa trên yêu cầu và thông số kỹ thuật thiết kế, hướng dẫn và kiểm thử của người dùng và người vận hành.
Thông thường, nó hỗ trợ tính hiệu lực và hiệu quả của việc báo cáo, theo dõi và quản lý lỗi khi công cụ theo dõi lỗi cung cấp khả năng thay đổi một số thông tin được thu thập tùy thuộc vào lỗi được báo cáo dựa trên điều gì.
Trong một số dự án, một số lượng rất lớn các lỗi được tìm thấy. Ngay cả trên các dự án nhỏ hơn khi tìm thấy 100 lỗi hoặc ít hơn, bạn có thể dễ dàng mất dấu vết của chúng trừ khi bạn có quy trình báo cáo, phân loại, chỉ định và quản lý lỗi từ khi phát hiện đến giải pháp cuối cùng.
Một báo cáo sự cố chứa một mô tả về hành vi sai trái đã được quan sát và phân loại hành vi sai trái đó. Như với bất kỳ giao tiếp bằng văn bản nào, sẽ giúp bạn có mục tiêu rõ ràng khi viết. Một mục tiêu chung cho các báo cáo như vậy là cung cấp cho lập trình viên, người quản lý và những người khác thông tin chi tiết về hành vi được quan sát và lỗi. Một cách khác là hỗ trợ phân tích các xu hướng trong dữ liệu lỗi tổng hợp, để hiểu thêm về một nhóm vấn đề hoặc kiểm thử cụ thể hoặc để hiểu và báo cáo mức chất lượng chung của hệ thống. Cuối cùng, các báo cáo lỗi, khi được phân tích trong một dự án và thậm chí giữa các dự án, cung cấp thông tin có thể dẫn đến các cải tiến quy trình phát triển và kiểm thử.
Khi viết một sự việc, bạn cũng nên nghĩ đến người đọc. Các lập trình viên cần thông tin trong báo cáo để tìm và sửa lỗi. Tuy nhiên, trước khi điều đó xảy ra, người quản lý nên xem xét và ưu tiên các lỗi để các nguồn lực dành cho nhà phát triển và kiểm thử được sử dụng để khắc phục, kiểm thử xác nhận các lỗi quan trọng nhất. Vì một số lỗi có thể bị trì hoãn (có thể sẽ được khắc phục sau hoặc cuối cùng sẽ không được khắc phục), nên bao gồm các cách giải quyết và thông tin hữu ích khác cho bộ phận trợ giúp hoặc nhóm hỗ trợ kỹ thuật. Cuối cùng, người kiểm thử thường cần biết những gì đồng nghiệp của họ đang tìm kiếm để có thể theo dõi hành vi tương tự ở nơi khác và tránh cố gắng chạy kiểm thử mà sẽ bị chặn.
Một báo cáo sự cố tốt là một tài liệu kỹ thuật. Ngoài mục tiêu và đối tượng rõ ràng, bất kỳ báo cáo tốt nào cũng phát triển từ cách tiếp cận cẩn thận để nghiên cứu và viết báo cáo. Có một số quy tắc chung có thể giúp bạn viết báo cáo sự cố tốt hơn.
Trước tiên, hãy sử dụng cách tiếp cận cẩn thận, chu đáo để chạy bài kiểm thử. Không bao giờ bạn biết khi nào sẽ tìm thấy một vấn đề. Nếu bạn đang gõ bàn phím trong khi tán gẫu với bạn cùng văn phòng hoặc mơ mộng về một bộ phim bạn vừa xem, bạn có thể không nhận thấy những hành vi kỳ lạ. Ngay cả khi bạn nhìn thấy sự việc, bạn thực sự biết được bao nhiêu về nó? Bạn có thể viết gì trong báo cáo sự cố?
Các triệu chứng không liên tục hoặc lẻ tẻ là một thực tế của cuộc sống đối với một số lỗi và việc báo cáo sự cố bị trả lại là “không thể sửa chữa” luôn khiến bạn nản lòng. Vì vậy, bạn nên cố gắng tái tạo các dấu hiệu khi bạn nhìn thấy chúng và ba lần là một quy tắc tốt. Nếu một lỗi có các triệu chứng không liên tục, chúng ta vẫn sẽ báo cáo lỗi đó, nhưng chúng ta chắc chắn sẽ cần càng nhiều thông tin càng tốt, đặc biệt là số lần cố gắng tái tạo lỗi đó và số lần lỗi đó đã xảy ra trên thực tế.
Bạn cũng nên cố gắng cô lập lỗi bằng cách thực hiện các thay đổi được lựa chọn cẩn thận đối với các bước được sử dụng để tái tạo nó. Khi cô lập lỗi, bạn giúp hướng dẫn lập trình viên đến phần có vấn đề của hệ thống. Bạn cũng nâng cao kiến thức của mình về cách thức hoạt động của hệ thống (và cách thức hoạt động của nó).
Một số trường hợp kiểm thử tập trung vào các điều kiện biên, điều này có thể khiến cho một lỗi không có khả năng xảy ra thường xuyên trong thực tế. Chúng ta nhận thấy rằng nên tìm kiếm các điều kiện tổng quát hơn gây ra lỗi, thay vì chỉ dựa vào trường hợp kiểm thử. Điều này giúp ngăn chặn lời đáp lại báo cáo sự cố nổi tiếng rằng “Không người dùng thực nào sẽ làm điều đó”. Nó cũng cắt giảm số lượng báo cáo trùng lặp được nộp.
Vì thường có rất nhiều kiểm thử diễn ra với hệ thống trong thời gian kiểm thử, nên có rất nhiều kết quả kiểm thử khác có sẵn. So sánh một vấn đề được quan sát với các kết quả kiểm thử khác và các lỗi đã biết được tìm thấy là một cách tốt để tìm và ghi lại thông tin bổ sung mà lập trình viên có thể thấy rất hữu ích. Ví dụ: bạn có thể kiểm thử các dấu hiệu tương tự được quan sát thấy với các lỗi khác, dấu hiệu tương tự được quan sát thấy với các lỗi đã được khắc phục trong các phiên bản trước hoặc các kết quả tương tự (hoặc khác) được thấy trong các kiểm thử bao gồm các phần tương tự của hệ thống.
Nhiều người đọc các báo cáo sự cố(đặc biệt là các nhà quản lý) sẽ cần phải hiểu mức độ ưu tiên và mức độ nghiêm trọng của lỗi. Vì vậy, tác động của vấn đề đối với người dùng, khách hàng và các bên liên quan khác là rất quan trọng. Hầu hết các hệ thống theo dõi lỗi đều có trường tiêu đề hoặc tóm tắt và trường đó cũng phải đề cập đến tác động.
Lựa chọn từ ngữ chắc chắn quan trọng trong các báo cáo sự cố. Nên rõ ràng và không mơ hồ. Bạn cũng nên trung lập, tập trung vào thực tế và vô tư, ghi nhớ các vấn đề liên quan đến kiểm thử giữa các cá nhân được thảo luận trong Chương 1 và trước đó trong chương này. Cuối cùng, giữ cho báo cáo ngắn gọn giúp thu hút sự chú ý của mọi người và tránh vấn đề đánh mất họ trong các chi tiết.
Theo nguyên tắc cuối cùng đối với các báo cáo sự cố, bạn nên sử dụng quy trình xem xét cho tất cả các báo cáo được gửi. Nó hoạt động nếu bạn có báo cáo đánh giá của người kiểm thử chính và cho phép người kiểm thử (ít nhất là những người có kinh nghiệm) xem xét báo cáo của những người kiểm thử khác. Đánh giá là kỹ thuật đảm bảo chất lượng đã được chứng minh và báo cáo sự cố là sản phẩm bàn giao quan trọng của dự án
