Rủi ro đơn giản là một vấn đề có khả năng xảy ra và khi nó xảy ra, nó sẽ gây ra thiệt hại. Thiệt hại có thể là bất cứ thứ gì: tiền bạc, thời gian, công sức hoặc một sự thỏa hiệp về chất lượng. Thiệt hại thì không bao giờ là điều tốt cả. Cho dù chúng ta có cố gắng và thử đi thử lại bao nhiêu thì rủi ro cũng không phải là việc tích cực và sẽ không bao giờ tích cực . Do đó, quản lý rủi ro là một phần không thể thiếu trong dự án phần mềm, để chắc chắn rằng chúng ta có thể xử lý những rủi ro, giảm thiểu, ngăn ngừa những tổn thất, thiệt hại.
Quy trình quản lý rủi ro xảy ra trong suốt 2 phần (phases) trong vòng đời phát triển phần mềm
1.Lập kế hoạch kiểm thử (test planning) 2.Thiết kế test cases ( test case design) hoặc thỉnh thoảng là trong khi thực thi kiểm thử ( test execution phases)
Quy trình quản lý rủi ro
Quy trình chung cho quản lý rủi ro bao gồm 3 bước quan trọng :
1.Xác định rủi ro ( Risk identification) 2.Phân tích ảnh hưởng rủi ro ( risk impact analysis) 3.Giảm thiểu rủi ro (risk mitigation)
Xác định rủi ro ( Risk identification)
Bước đầu tiên để giải quyết 1 vấn đề đó là xác định đó là vấn đề gì. Ở giai đoạn này, tạo ra danh sách tất cả những thứ tiềm tàng có thể xảy ra làm phá vỡ luồng hoạt động thông thường.
**Đầu ra chính của bước này đó là: danh sách các rủi ro. ** Bước kiểm thử dựa trên rủi ro này thường được hướng dẫn bởi QA lead/manager…Tuy nhiên, trưởng nhóm không thể một mình tạo ra toàn bộ danh sách các rủi ro được, cả nhóm phải cùng nhau tạo nên một danh sách đầy đủ hơn và có ảnh hưởng lớn hơn.
Ngoài ra, rủi ro được xác định trong suốt quá trình lập kế hoạch kiểm thử sẽ có ý nghĩa trong việc định hướng, quản lý hơn. Chúng ta có thể nhìn vào bất cứ thứ gì gây ra ảnh hưởng: kế hoạch của dự án, nỗ lực, ngân sách, sự thay đổi hạ tầng…
Những rủi ro trong suốt quá trình lập kế hoạch kiểm thử – Ví dụ kiểm thử dựa trên rủi ro.
Những điều dưới đây là một danh sách mẫu của các rủi ro trong suốt quá trình lập kế hoạch kiểm thử. Hãy chú ý rằng, AUT và chức năng không được chú trọng ở đây.
#1. Thời gian, lịch trình (schedule) kiểm thử chặt chẽ. Nếu thời gian bắt đầu kiểm thử bị trì hoãn, việc kiểm thử sẽ không thể được mở rộng trước khi kế hoạch UAT bắt đầu.
#2. Không đủ nhân lực, nhân lực có thể bắt đầu công việc quá muộn
#3. Lỗi được tìm ra ở các giai đoạn sau của vòng đời phát triển phần mềm. Lỗi được tìm ra muộn có khả năng phụ thuộc vào đặc tả yêu cầu không rõ ràng và mất nhiều thời gian để giải quyết nó.
#4. Phạm vi kiểm thử không được định nghĩa một cách đầy đủ
#5. Thảm họa thiên nhiên
#6. Môi trường test độc lập không sẵn sàng
#7. Kiểm thử bị trì hoãn phụ thuộc vào những vấn đề mới phát sinh.
Một khi tất cả các rủi ro được liệt kê ra, chúng ta sẽ tiến hành đánh giá rủi ro, phân tích ảnh hưởng của rủi ro đó.
Đánh giá rủi ro/ Phân tích ảnh hưởng rủi ro ( Risk assessment/ Risk impact analysis)
Phân tích rủi ro trong kiểm thử phần mềm: Tất cả những rủi ro được định lượng và đánh thứ tự ưu tiên trong bước này. Mỗi khả năng xảy ra của rủi ro và ảnh hưởng ( số lượng tổn thất mà nó có thể gây ra ) được xác định một cách có hệ thống.
Các giá trị: cao – trung bình – thấp được phân chia dựa trên cả khả năng xảy ra và ảnh hưởng của mỗi rủi ro. Rủi ro với khả năng xảy ra cao và khả năng ảnh hưởng lớn sẽ được quan tâm đầu tiên sau đó tới các rủi ro tiếp theo.
Bảng phân tích ảnh hưởng rủi ro:
Theo dõi các bước dưới đây, bảng phân tích ảnh hưởng rủi ro cho các rủi ro liệt kê ở bên trên:
| Rủi ro (Risk) | Khả năng có thể xảy ra (Probability) | Ảnh hưởng (impact) |
|---|---|---|
| #1. Thời gian, lịch trình (schedule) kiểm thử chặt chẽ. Nếu thời gian bắt đầu kiểm thử bị trì hoãn, việc kiểm thử sẽ không thể được mở rộng trước khi kế hoạch UAT bắt đầu. | Cao | Cao |
| #2 Không đủ nhân lực, nhân lực có thể bắt đầu công việc quá muộn | Trung bình | Cao |
| #3. Lỗi được tìm ra ở các giai đoạn sau của vòng đời phát triển phần mềm. Lỗi được tìm ra muộn có khả năng phụ thuộc vào đặc tả yêu cầu không rõ ràng và mất nhiều thời gian để giải quyết nó | Trung bình | Cao |
| #4. Phạm vi kiểm thử không được định nghĩa một cách đầy đủ | Trung bình | Trung bình |
| #5. Thảm họa thiên nhiên | Thấp | Trung bình |
| #6. Môi trường test độc lập không sẵn sàng | Trung bình | Cao |
| #7. Kiểm thử bị trì hoãn phụ thuộc vào những vấn đề mới phát sinh. | Trung bình | Cao |
Giảm thiểu rủi ro
Bước cuối cùng trong quá trình kiểm thử dựa trên rủi ro là tìm giải pháp để lên kế hoạch làm thế nào xử lý các rủi ro đã liệt kê. Kế hoạch này có thể khác nhau giữa các công ty, các dự án và kể cả là giữa con người với con người.
Các kỹ thuật giảm thiểu rủi ro
Đây là một ví dụ về bảng rủi ro sau khi quá trình được hoàn thành.
| Rủi ro (Risk) | Khả năng có thể xảy ra (Probability) | Ảnh hưởng (impact) | Kế hoạch giảm thiểu rủi ro ( Mitigation Risk) |
|---|---|---|---|
| #1. Thời gian, lịch trình (schedule) kiểm thử chặt chẽ. Nếu thời gian bắt đầu kiểm thử bị trì hoãn, việc kiểm thử sẽ không thể được mở rộng trước khi kế hoạch UAT bắt đầu. | Cao | Cao | Nhóm kiểm thử có thể chuẩn bị cho công việc (tasks) trước đó và giao tiếp sớm với các bên liên quan. Thêm thời gian dự phòng |
| #2 Không đủ nhân lực, nhân lực có thể bắt đầu công việc quá muộn | Trung bình | Cao | – Ngày nghỉ và kỳ nghỉ được dự đoán và đưa vào lịch trình (schedule), sự sai lệch so với dự đoán có thể gây ra sự trì hoãn trong kiểm thử. |
| #3. Lỗi được tìm ra ở các giai đoạn sau của vòng đời phát triển phần mềm. Lỗi được tìm ra muộn có khả năng phụ thuộc vào đặc tả yêu cầu không rõ ràng và mất nhiều thời gian để giải quyết nó | Trung bình | Cao | Có kế hoạch quản lý lỗi để xác định và sửa lỗi kịp thời. |
| #4. Phạm vi kiểm thử không được định nghĩa một cách đầy đủ | Trung bình | Trung bình | Xác định phạm vi kiểm thử một cách đầy đủ. |
| #5. Thảm họa thiên nhiên | Thấp | Trung bình | Các dự án và những người có trách nhiệm được chia ra hai khu vực địa lý khác nhau. Trong trường hợp có sự kiện không mong muốn ở một trong 2 khu vực thì vẫn còn nguồn lực ở khu vực còn lại có thể tiếp tục công việc. |
| #6. Môi trường test độc lập không sẵn sàng | Trung bình | Cao | Lịch trình kiểm thử sẽ bị ảnh hưởng và sẽ dẫn đến ngày bắt đầu kiểm thử bị trì hoãn. |
| #7. Kiểm thử bị trì hoãn phụ thuộc vào những vấn đề mới phát sinh. | Trung bình | Cao | Trong suốt quá trình kiểm thử, những lỗi mới sẽ được phát hiện và có thể gây ra những vấn đề mất nhiều thời gian để giải quyết. Có những lỗi được đưa ra trong suốt quá trình kiểm thử vì đặc tả yêu cầu không rõ ràng. Có những vấn đề gây ảnh hưởng đến toàn bộ lịch trình của dự án. Nếu những lỗi mới được phát hiện, việc quản lý lỗi và các thủ tục quản lý phát hành được đưa ra để ngay lập tức cung cấp giải pháp giải quyết vấn đề |
Một vài điểm cần lưu ý:
- Càng quản lý rủi ro sớm trong quá trình lập kế hoạch kiểm thử thì càng tốt 2.Trong 3 bước quản lý rủi ro, xác định rủi ro là quan trọng nhất. Nếu bất cứ rủi ro nào không được liệt kê và xem xét thì rủi ro đó càng có nguy cơ không xử lý được.
- Hãy thử tìm một khung thời gian lý tưởng cho hoạt động này. Hãy nhớ rằng quá nhiều kế hoạch để lại quá ít thời gian để làm.
- Ngoài ra, sau quá trình quản lý rủi ro, nếu có một tình huống mới xuất hiện, kế hoạch quản lý rủi ro có thể được thay đổi hoặc cập nhật để phản ánh tình trạng hiện tại.
- Dữ liệu lịch sử có thể rất hữu ích cho sự thành công của quá trình này.