Risk (Project Risks & Product Risks) và Testing

Trong phát triển phần mềm, khái niệm Risk (rủi ro) rất thường được sử dụng. Tuy nhiên, không phải ai cũng hiểu một cách rõ ràng về Risk. Chính vì vậy bài viết này sẽ cung cấp cho các bạn khái niệm về Risk, phân loại chúng và chỉ ra mối liên hệ giữa Risk và Testing.

1. Risk là gì?

Risk có thể được định nghĩa như là những vấn đề có thể gây nguy hiểm cho các sản phẩm của các bên liên quan trong dự án. Đó là khả năng xảy ra một kết quả tiêu cực hoặc không mong muốn. Risk là điều chưa từng xảy ra và nó có thể không bao giờ xảy ra, nó được coi như là một vấn đề tiềm ẩn. Xác suất của Risk nằm trong khoảng giữa 0% và 100% (cho thấy Risk chỉ là một khả năng, không phải là một sự chắc chắn).

Nguy cơ xảy ra Risk trong dự án phụ thuộc vào mức độ rủi ro liên quan đến các hậu quả tiêu cực có thể có của nó. Ví dụ: Nếu coi việc bị cảm cúm như là một rủi ro có thế/ không thể xảy ra, thì:

• Với một người trẻ tuổi, khỏe mạnh sẽ ít có nguy cơ bị cảm cúm hơn
• Với một người lớn tuổi, sức khỏe yếu sẽ có nhiều nguy cơ bị cảm cúm hơn

2. Các loại Risk:

2.1. Project Risks:

Project Risks (rủi ro dự án) là rủi ro có khả năng xảy ra xung quanh dự án trong quá trình phát triển để đạt được mục tiêu đã đề ra, như là:

Yếu tố tổ chức:

• Kỹ năng, đào tạo và thiếu nhân lực
• Vấn đề nhân sự
• Vấn đề trao đổi giữa các thành viên
• Thái độ không tích cực (ví dụ: không coi trọng sự cố được tìm thấy trong quá trình kiểm thử)

Vấn đề kỹ thuật:

• Vấn đề trong yêu cầu đặc tả
• Không đáp ứng được những ràng buộc trong yêu cầu
• Môi trường kiểm thử chưa sẵn sàng đúng thời gian
• Chuyển đổi dữ liệu chậm
• Chất lượng design, code, dữ liệu cấu hình, dữ liệu kiểm thử và kiểm thử thấp

Vấn đề về nhà cung cấp:

• Thất bại từ bên thứ ba
• Vấn đề hợp đồng

2.2. Product Risks:

Product Risks (rủi ro sản phẩm): phạm vi thất bại tiềm ẩn (bất lợi trong tương lai hoặc mối nguy hiểm) trong phần mềm hoặc hệ thống, bao gồm:

• Thất bại trong phần mềm đã bàn giao
• Tiềm năng mà phần mềm / phần cứng có thể gây hại cho cá nhân hoặc công ty
• Đặc tính nghèo nàn trong phần mềm (chức năng, tính khả dụng, hiệu năng, ...)
• Tính toàn vẹn dữ liệu kém (di chuyển dữ liệu, chuyển đổi dữ liệu, ...)
• Phần mềm không thực hiện được các chức năng đã dự định

3. Mối liên hệ giữa Risks (rủi ro) với Testing (kiểm thử):

• Risk được sử dụng để quyết định nơi bắt đầu kiểm thử và nơi nào sẽ thực hiện kiểm thử nhiều hơn.
• Kiểm thử được sử dụng để làm giảm bớt rủi ro có thể gây ra tác động bất lợi hoặc để giảm tác động của một ảnh hưởng phụ nào đó.
• Product risks là một dạng đặc biệt về rủi ro trong việc quyết định thành công của dự án. Kiểm thử như là một hoạt động kiểm soát rủi ro, cung cấp phản hồi về những rủi ro còn sót lại bằng cách đo lường hiệu quả việc loại bỏ khiếm khuyết nghiêm trọng và tạo ra các kế hoạch dự phòng.
• Phương pháp tiếp cận rủi ro dựa vào việc kiểm thử sẽ cung cấp các cơ hội chủ động để giảm mức độ rủi ro sản phẩm, bắt đầu từ giai đoạn đầu của dự án. Nó bao gồm việc xác định rủi ro sản phẩm và sử dụng chúng trong việc hướng dẫn lập kế hoạch kiểm thử và kiểm soát, đặc điểm kỹ thuật, chuẩn bị và thực hiện các kịch bản kiểm thử.

Cách tiếp cận rủi ro thông thường:

• Xác định kỹ thuật kiểm thử sẽ sử dụng
• Xác định mức độ kiểm thử sẽ thực hiện
• Ưu tiên kiểm thử trong một nỗ lực để tìm ra những khiếm khuyết quan trọng càng sớm càng tốt
• Xác định các hoạt động không phải kiểm thử nhưng có thể thực hiện để giảm thiểu rủi ro (Ví dụ: cung cấp các buổi đào tạo cho designer thiếu kinh nghiệm, ...)

Ngoài ra, kiểm thử có thể hỗ trợ việc xác định các rủi ro mới, có thể giúp xác định rủi ro nào cần được giảm và có thể làm giảm sự không chắc chắn về rủi ro.

Link tham khảo: http://istqbexamcertification.com/what-is-risk-in-software-testing/ http://www.softwaretestingmentor.com/what-is-product-risk-and-project-risk/ http://www.istqb.org/downloads/syllabi/foundation-level-syllabus.html