Quản lý rủi ro khi thực thi kiểm thử (Test Execution)

Ở phần trước, chúng ta đã nói về quản lý rủi ro ở giai đoạn lập kế hoạch kiểm thử. Ở phần này, chúng ta sẽ nói về việc làm thế nào để quản lý rủi ro ở giai đoạn thiết kế kiểm thử (test designing) hoặc giai đoạn thực thi kiểm thử (Test execution)

Chúng ta hãy cùng nhau xem ví dụ sau:

Nếu kiểm thử diễn ra vào ngày 1 tháng 1 và kéo dài cho đến ngày 14 tháng 1. Khi kiểm thử hoàn thành, ngày đưa sản phẩm ra thị trường sẽ được quyết định ngay lập tức. Ngày 15 tháng 1 là ngày hợp lý nhất. Trong điều kiện lí tưởng, mọi thứ sẽ diễn ra đúng theo kế hoạch. Nhưng tất cả chúng ta đều biết thực tế sẽ như thế nào.

Trong trường hợp như thế này, chúng ta hãy giả định một vài lý do. Kiểm thử không được bắt đầu cho đến ngày 7/1. Tức là đã mất 1 nửa thời gian kiểm thử. Cần 14 ngày để kiểm thử sản phẩm một cách triệt để và cần lùi ngày phát hành sản phẩm lại tới 7 ngày sau đó. Tuy nhiên, chúng ta không có quyền lựa chọn Bởi vì, sản phẩm đã được quyết định ngày phát hành và sự chậm trễ thì không tốt cho việc kinh doanh. Vì vậy, cần tìm ra phương pháp nào đó để với thời gian còn lại, vẫn có thể đưa ra một sản phẩm đã được kiểm thử với chất lượng tốt. Đây chắc hẳn là một công việc khó khăn.

Trong trường hợp này, chúng ta nên sử dụng phương pháp quản lý rủi ro.

• Nếu sự chậm trễ (delays) được dự đoán từ trước, trước khi bắt đầu kiểm thử, chúng ta sẽ quản lý rủi ro trong quá trình thiết kế kiểm thử (test designing)
• Nếu sự chậm trễn (delays) xảy ra trong suốt quá trình thực thi kiểm thử , chúng ta sẽ quản lý rủi ro trong quá trình thực thi kiểm thử đó.
• Các bước và phương pháp quản lý rủi ro là giống nhau dù nó xảy ra ở quá trình nào đi nữa.

Quản lý rủi ro diễn ra để xác định cần tập trung kiểm thử nhiều nhất vào vùng chức năng nào. Đây thường là các chức năng hoặc thành phần ảnh hưởng nhiều nhất đến sự thành công hay thất bại của sản phẩm.

Không chỉ QA là người thực hiện mà tất cả những người liên quan, có hiểu biết về sản phẩm như: Dev, BA, Khách hàng, quản lý dự án … Tuy nhiên, nhóm kiểm thử là những người điều khiển quá trình quản lý rủi ro này.

Step 1: Xác định rủi ro (Risk Identification)

Xác định tất cả các chức năng của hệ thống. Điều này chỉ đơn giản là tạo ra một danh sách các chức năng của hệ thống (function list)

Step 2: Đánh giá rủi ro ( Risk Asessment)

Tất cả các rủi ro được định lượng và xác định độ ưu tiên trong bước này. Định lượng chỉ đơn giản là chỉ định cho mỗi rủi ro trong danh sách một số (number) mà nó có thể xác định độ ưu tiên cần phải thực hiện.

Xác suất (cơ hội xảy ra) của rủi ro và ảnh hưởng (số tiền thiệt hại mà nó gây ra nếu rủi ro xảy ra) sẽ được quyết định

Phương pháp điển hình là chỉ định xếp hạng. Ví dụ, Xác suất có thể lấy giá trị từ 1 đến 5. 1 là xác suất xảy ra là thấp (không có khả năng xảy ra) và 5 là cao (chắc chắn sẽ xảy ra).

Tương tự như vậy, tác động và ảnh hướng (impact) cũng có thể được chỉ định 1-5 đánh giá. 1 là tác động thấp (ngay cả khi rủi ro này xảy ra, tổn thất là tối thiểu) và 5 tác động lớn (tổn thất rất lớn khi xảy ra). Step 3

Lập bảng như bên dưới và chuyển tới tất cả các thành viên của dự án: Dev, BA, Khách hàng, PM, QA.. hoặc bất cứ ai có liên quan

Step 4 Hướng dẫn mỗi thành viên điền giá trị dựa trên đánh giá của họ về xác suất và ảnh hưởng của mỗi chức năng.

Sau khi có các giá trị xác suất và ảnh hưởng, chúng ta sẽ tiến hành tính toán hệ số rủi ro

Hệ số rủi ro (Risk factor)= Xác suất (Probability) X Ảnh hưởng (Impact)

=> hệ số rủi ro càng cao thì vấn đề càng nguy hiểm và càng cần tìm phương pháp giải quyết.

Ví dụ:

Xin lưu ý rằng vào thời điểm này, đây chỉ đơn giản là kết quả đánh giá của một nhóm. Đối với một dự án có 5 nhóm khác nhau sẽ có 5 bảng khác nhau.

Step 5:

Tính toán trung bình của hệ số rủi ro. Ví dụ, nếu có 5 nhóm, với mỗi module, cộng tất cả các hệ số rủi ro và chia cho 5. Kết quả cuối cùng là kết quả cần tìm.

Hệ số rủi ro càng lớn thì càng nhiều module phải được kiểm thử.

Vì thế, module 5 và 2 cần được quan tâm nhất và ảnh hưởng tới sự thành công của dự án.

Chia sẻ kết quả này với tất cả các nhóm

Step6: Kế hoạc làm giảm thiểu rủihro ( Risk Mitigation Plan)

Chúng ta đã xác định được module 5 và 2 là những module cần tập trung nhiều nhất

Ví dụ về kế hoạch giảm thiểu rủi ro cho trường hợp trên

• Module 5 vfa 2 sẽ được kiểm thử một cách tỉ mỉ, kỹ càng bằng cách chắc chắn rằng tất cả các trường hợp kiểm thử (test cases ) liên quan sẽ được kiểm thử. Các modules khác sẽ được kiểm thử dựa trên phương pháp kiểm thử thăm dò (exploratory testing)
• Module 5 và 2 sẽ được kiểm thử đầu tiên và sau đó phụ thuộc vào khoảng thời gian còn lại sẽ quyết định các trường hợp tiếp theo.

• Đây là hoạt động tập hợp ý kiến của tất cả mọi người trong nhóm, độ chính xác và hiệu quả của nó cao hơn khi sử dụng ý kiến của 1 người.
• Đây không phải là một phương pháp chính thống và nó không phải là một phần của tất cả các dự án phầm mềm
• Đôi khi không cần vẽ bảng và chỉ định các giá trị, chỉ cần một phiên họp đơn giản với tất cả ọi người cũng có thể đưa cho nhóm kiểm thử hướng đi tốt và cách làm thế nào để tiến hành quản lý rủi ro
• Đầu vào của nhóm phát triển là vô cùng quan trọng bởi họ là một trong những người tạo nên sản phẩm, họ sẽ biết cái gì đang diễn ra và cần phải kiểm tra những gì. Hãy chắc chắn là bạn sẽ không bỏ qua điều đó
• Mặc dù có vô bàn bước trong quá trình quản lý rủi ro, nhưng không nhất thiết phải mất quá nhiều thời gian để thực hiện chúng. Đặc biết là nếu tất cả nhóm có thể ngồi cùng nhau và làm việc một cách đồng thời
• Hãy nhớ rằng quá trình này và kết quả của nó chỉ là một phương pháp thay thế. Nếu chúng ta nhận được nhiều thời gian kiểm thử như dự kiến thì cách tốt nhất là nên thực hiện theo kế hoạch ban đầu đã đề ra.

Bài viết được dịch lại từ nguồn: http://www.softwaretestinghelp.com/risk-management-at-test-execution-phase/