ISTQB – Chương 5 – Mục 5.6- Quản lý sự cố – Phần 2/2

Điều gì xảy ra trong báo cáo sự cố?

Báo cáo sự cố mô tả một số tình huống, hành vi hoặc sự kiện xảy ra trong quá trình kiểm thử cần nghiên cứu thêm. Trong nhiều trường hợp, báo cáo sự cố bao gồm một hoặc hai màn hình (chứa đầy thông tin được thu thập bởi công cụ theo dõi lỗi và được lưu trữ trong cơ sở dữ liệu).

Như đã đề cập ở trên, bạn thường ghi lại thông tin tường thuật như tóm tắt, các bước tái diễn, các bước cô lập đã thử và tác động của vấn đề. Các trường này phải đề cập đến đầu vào đã cho và đầu ra được quan sát, sự khác biệt hoặc khác biệt so với kỳ vọng, các cách khác nhau mà bạn có thể (và không thể) khiến vấn đề tái diễn và tác động.

Thông tin phân loại mà người kiểm thử sẽ cung cấp bao gồm ngày và thời gian xảy ra lỗi, lỗi được tìm thấy ở giai đoạn nào của dự án, trường hợp kiểm thử nào tạo ra lỗi, sự cố, tham chiếu đến thông số kỹ thuật hoặc các tài liệu khác cung cấp thông tin về hành vi đúng, tên của người kiểm thử (và có thể là người đánh giá), môi trường kiểm thử và bất kỳ thông tin bổ sung nào về cấu hình của phần mềm, hệ thống hoặc môi trường. Đôi khi người kiểm thử phân loại phạm vi, mức độ nghiêm trọng và mức độ ưu tiên của lỗi, mặc dù đôi khi người quản lý xử lý vai trò đó.

Khi sự cố được quản lý để giải quyết, người quản lý có thể chỉ định mức độ ưu tiên cho báo cáo. Ban kiểm soát thay đổi hoặc ủy ban xử lý lỗi có thể ghi lại các rủi ro, chi phí, cơ hội và lợi ích liên quan đến việc sửa hoặc không sửa lỗi. Lập trình viên khi sửa lỗi có thể nắm bắt được nguyên nhân cốt lõi, giai đoạn đưa vào và giai đoạn loại bỏ.

Sau khi lỗi đã được giải quyết, người quản lý, lập trình viên hoặc những người khác có thể muốn nắm bắt các kết luận và khuyến nghị. Trong suốt vòng đời của báo cáo sự cố(từ khi phát hiện đến giải quyết), hệ thống theo dõi lỗi sẽ cho phép người làm báo cáo sự cố nhập thông tin về trạng thái và lịch sử.

Điều gì xảy ra với các báo cáo sự cố sau khi tài liệu chúng?

Như đã đề cập trước đó, các báo cáo sự cố được quản lý thông qua vòng đời từ khi phát hiện đến khi giải quyết. Vòng đời báo cáo sự cố thường được thể hiện dưới dạng sơ đồ chuyển đổi trạng thái (xem Hình 5.3). Mặc dù hệ thống theo dõi lỗi có thể sử dụng một vòng đời khác, nhưng hãy lấy ví dụ này làm ví dụ để minh họa cách thức hoạt động của vòng đời báo cáo sự cố.

Trong vòng đời báo cáo sự cố được minh họa trong Hình 5.3, tất cả các báo cáo sự cố di chuyển qua một loạt các trạng thái được xác định rõ ràng sau khi được báo cáo. Một số chuyển đổi trạng thái này xảy ra khi một thành viên của nhóm dự án hoàn thành một số nhiệm vụ được giao liên quan đến việc đóng báo cáo sự cố. Một số trạng thái chuyển đổi lại xảy ra khi nhóm dự án quyết định không sửa lỗi trong dự án này, dẫn đến việc báo cáo sự cố bị hoãn lại. Một số chuyển đổi trạng thái xảy ra khi báo cáo sự cố được viết kém hoặc mô tả hành vi thực sự chính xác, dẫn đến việc báo cáo đó bị từ chối.

Hãy tập trung vào con đường được thực hiện bởi các báo cáo sự cố mà cuối cùng đã được khắc phục. Sau khi một sự cố được báo cáo, một người kiểm thử ngang hàng hoặc người quản lý kiểm thử  sẽ xem xét báo cáo. Nếu thành công trong việc xem xét, báo cáo sự cố sẽ được mở, vì vậy nhóm dự án phải quyết định có sửa chữa lỗi hay không. Nếu lỗi cần được sửa chữa, một lập trình viên sẽ được chỉ định sửa chữa nó.

Sau khi lập trình viên tin rằng việc sửa chữa đã hoàn tất, báo cáo sự cố sẽ gửi lại cho người kiểm thử để kiểm thử xác nhận. Nếu kiểm thử xác nhận không thành công, báo cáo sự cố sẽ được mở lại và sau đó được chỉ định lại. Sau khi người kiểm thử xác nhận sửa chữa tốt, báo cáo sự cố sẽ được đóng lại. Không còn công việc nào phải làm nữa.

Ở bất kỳ trạng thái nào khác với trạng thái bị từ chối, hoãn lại hoặc đóng, cần phải tiếp tục xử lý sự cố trước khi kết thúc dự án này. Trong tình trạng như vậy, báo cáo sự cố có một chủ sở hữu được xác định rõ ràng. Chủ sở hữu chịu trách nhiệm chuyển sự cố sang trạng thái được phép tiếp theo. Các mũi tên trong sơ đồ hiển thị các chuyển đổi được phép này.

Ở trạng thái bị từ chối, hoãn lại hoặc đóng, báo cáo sự cố sẽ không được chỉ định cho chủ sở hữu. Tuy nhiên, một số sự kiện trong thế giới thực có thể khiến báo cáo sự cố thay đổi trạng thái ngay cả khi không có hoạt động nào đang diễn ra trên báo cáo sự cố.

Các ví dụ bao gồm sự tái diễn của lỗi liên quan đến báo cáo sự cố đã đóng và việc phát hiện ra lỗi nghiêm trọng hơn liên quan đến báo cáo sự cố bị trì hoãn.

Lý tưởng nhất là chỉ chủ sở hữu mới có thể chuyển báo cáo sự cố từ trạng thái hiện tại sang trạng thái tiếp theo và lý tưởng nhất là chủ sở hữu chỉ có thể chuyển báo cáo sự cố sang trạng thái tiếp theo được phép. Hầu hết các hệ thống theo dõi lỗi đều hỗ trợ và thực thi các quy tắc về vòng đời và vòng đời. Các hệ thống theo dõi lỗi tốt cho phép bạn tùy chỉnh tập hợp các trạng thái, chủ sở hữu và quá trình chuyển đổi được phép để phù hợp với quy trình công việc thực tế của bạn. Và, trong khi một hệ thống theo dõi lỗi tốt là
hữu ích, quy trình xử lý lỗi thực tế nên được giám sát và hỗ trợ bởi quản lý dự án và công ty.

Ezami

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *