Quản lý lỗi (Defect management) là một quy trình có hệ thống để xác định và sửa lỗi. Một chu trình quản lý lỗi bao gồm các giai đoạn sau:
1) Phát hiện lỗi (Discovery of defect)
2) Phân loại lỗi (Defect categorization)
3) Sửa lỗi bởi nhà phát triển (Fixing of defect)
4) Xác minh bởi người kiểm tra (Verification)
5) Đóng lỗi (Defect closure)
6) Báo cáo lỗi ở cuối dự án (Defect report)
Chủ đề này sẽ hướng dẫn bạn cách áp dụng quy trình quản lý lỗi cho dự án trang web của một Ngân hàng. Bạn có thể làm theo các bước dưới đây để quản lý lỗi.
Trong giai đoạn khám phá, các nhóm dự án phải phát hiện ra càng nhiều lỗi càng tốt trước khi khách hàng cuối có thể phát hiện ra nó. Một lỗi được cho là được phát hiện và chuyển sang trạng thái chấp nhận khi nó được các nhà phát triển thừa nhận và chấp nhận.
Trong kịch bản trên, người kiểm tra đã phát hiện ra 84 lỗi trên trang web Ngân hàng.
Chúng ta hãy xem kịch bản sau đây; nhóm kiểm thử của bạn đã phát hiện ra một số vấn đề trên trang web của Ngân hàng. Họ coi chúng là lỗi và báo cáo với nhóm phát triển, nhưng xảy ra xung đột: Nhóm kiểm thử cho rằng những vẫn đề này là lỗi, nhưng nhóm phát triển cho rằng không phải.
Với tư cách là Người quản lý kiểm tra, bạn sẽ làm gì?
A) Đồng ý với nhóm kiểm thử rằng đó là một lỗi
B) Người quản lý kiểm tra đóng vai trò là người phán xét để quyết định xem vấn đề có bị lỗi hay không
C) Đồng ý với nhóm phát triển rằng đó không phải là lỗi
Trong trường hợp đó, cần áp dụng quy trình giải quyết để giải quyết xung đột, bạn đóng vai trò là thẩm phán để quyết định xem vấn đề của trang web có phải là lỗi hay không.
Việc phân loại lỗi giúp các nhà phát triển phần mềm ưu tiên các task của họ. Điều đó có nghĩa là loại ưu tiên này giúp các nhà phát triển sửa những lỗi quan trọng trước tiên.
Các lỗi thường được phân loại bởi Test manager –
Hãy làm một bài tập nhỏ như sau: Kéo và thả mức độ ưu tiên của lỗi bên dưới
| 1) Hiệu suất trang web quá chậm | |
| 2) Chức năng đăng nhập của website không hoạt động bình thường | |
| 3) GUI của website không hiển thị chính xác trên Thiết bị di động | |
| 4) Trang web không thể nhớ phiên đăng nhập của người dùng | |
| 5) Một số liên kết không hoạt động |
Dưới đây là những câu trả lời được đề xuất:
| STT | Mô tả | Độ ưu tiên | Giải thích |
|---|---|---|---|
| 1 | Hiệu suất trang web quá chậm | High | Lỗi hiệu suất có thể gây ra sự bất tiện lớn cho người dùng. |
| 2 | Chức năng đăng nhập của trang web không hoạt động bình thường | Critical | Đăng nhập là một trong những chức năng chính của website ngân hàng, nếu tính năng này không hoạt động sẽ là lỗi nghiêm trọng |
| 3 | GUI của website không hiển thị chính xác trên thiết bị di động | Medium | Lỗi này ảnh hưởng đến người dùng sử dụng Điện thoại thông minh để xem trang web. |
| 4 | Trang web không thể nhớ phiên đăng nhập của người dùng | High | Đây là một vấn đề nghiêm trọng vì người dùng sẽ có thể đăng nhập nhưng không thể thực hiện bất kỳ giao dịch nào nữa |
| 5 | Một số liên kết không hoạt động | Low | Đây là một bản sửa lỗi dễ dàng dành cho những người phát triển và người dùng vẫn có thể truy cập trang web mà không cần các liên kết này |
Giải quyết lỗi trong kiểm thử phần mềm là quá trình từng bước sửa lỗi. Quá trình giải quyết lỗi bắt đầu bằng việc gán lỗi cho nhà phát triển, sau đó nhà phát triển lên lịch sửa lỗi theo mức độ ưu tiên, sau đó lỗi được sửa và cuối cùng nhà phát triển gửi báo cáo giải pháp cho người quản lý kiểm thử. Quá trình này giúp sửa chữa và theo dõi lỗi một cách dễ dàng.
Bạn có thể làm theo các bước sau để sửa lỗi.
Sau khi nhóm phát triển đã sửa và báo cáo lỗi, nhóm kiểm thử sẽ xác minh rằng các lỗi đó đã thực sự được giải quyết.
Ví dụ, trong kịch bản trên, khi nhóm phát triển báo cáo rằng họ đã sửa được 61 lỗi, nhóm của bạn sẽ kiểm tra lại để xác minh những lỗi này đã thực sự được sửa hay chưa.
Khi lỗi đã được sửa và xác minh, lỗi sẽ thay đổi trạng thái là đã đóng . Nếu không, bạn cần gửi thông báo cho bộ phận phát triển để kiểm tra lại lỗi đó.
Báo cáo lỗi trong kiểm thử phần mềm là một quá trình trong đó người quản lý kiểm thử chuẩn bị và gửi báo cáo lỗi cho nhóm quản lý để lấy phản hồi về quy trình quản lý lỗi và trạng thái lỗi. Sau đó, nhóm quản lý kiểm tra báo cáo lỗi và gửi phản hồi hoặc cung cấp hỗ trợ thêm nếu cần. Báo cáo lỗi giúp giao tiếp, theo dõi và giải thích lỗi một cách chi tiết hơn.
Ban quản lý có quyền biết tình trạng lỗi. Họ phải hiểu quy trình quản lý lỗi để hỗ trợ bạn trong dự án này. Vì vậy, bạn phải báo cáo cho họ tình trạng lỗi hiện tại để nhận được phản hồi từ họ.
Nhóm của bạn đã tìm thấy lỗi khi thử nghiệm dự án Ngân hàng.
Sau một tuần, nhà phát triển trả lời –
Trong tuần tới người thử nghiệm sẽ phản hồi
Như trong trường hợp trên, nếu việc giao tiếp khiếm khuyết được thực hiện bằng lời nói thì mọi việc sẽ sớm trở nên rất phức tạp. Để kiểm soát và quản lý lỗi một cách hiệu quả, bạn cần có vòng đời của lỗi.
Quay lại tình huống trên. Nhóm phát triển và nhóm thử nghiệm đã xem xét các lỗi được báo cáo. Đây là kết quả của cuộc thảo luận đó.
Làm thế nào để đo lường và đánh giá chất lượng thực hiện kiểm thử?
Đây là câu hỏi mà mọi Test Manager đều muốn biết. Có 2 thông số bạn có thể xem xét như sau:
Trong kịch bản trên, bạn có thể tính Tỷ lệ từ chối lỗi – Defect Rejection Ratio (DRR) là 20/84 = 0,238 (23,8%).
Một ví dụ khác, giả sử trang web Ngân hàng có tổng cộng 64 lỗi, nhưng nhóm thử nghiệm của bạn chỉ phát hiện 44 lỗi, tức là họ đã bỏ sót 20 lỗi. Do đó, bạn có thể tính Tỷ lệ rò rỉ lỗi – Defect Leakage Ratio (DLR) là 20/64 = 0,312 (31,2%).
Kết luận, chất lượng thực hiện kiểm thử được đánh giá thông qua hai thông số sau:
Giá trị DRR và DLR càng nhỏ thì chất lượng thực hiện kiểm thử càng tốt. Phạm vi tỷ lệ có thể chấp nhận được là gì ? Phạm vi này có thể được xác định và chấp nhận dựa trên mục tiêu của dự án hoặc bạn có thể tham khảo số liệu của các dự án tương tự.
Trong dự án này, giá trị khuyến nghị của tỷ lệ chấp nhận được là 5 ~ 10%. Nó có nghĩa là chất lượng thực hiện kiểm thử thấp. Bạn nên tìm biện pháp để giảm các tỷ lệ này như:
Bài viết được dịch từ: https://www.guru99.com/defect-management-process.html
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
