Rủi ro trong phát triển phần mềm

Trong bất kỳ một lĩnh vực nào cũng đều có tồn tại yếu tố rủi ro. Bạn cũng đã từng gặp phải rủi ro trong phát triển phần mềm dù không nhiều thì ít? Và với đặc thù riêng của mình, nhận diện và phân tích xử lý rủi ro trong phát triển phần mềm là một điều không hề đơn giản. Đã không ít sản phẩm thất bại khi mà đội ngũ phát triển bỏ qua hoặc kiểm soát rủi ro một cách sơ sài, dẫn đến việc sản phẩm đưa đến tay khách hàng và nhận lại nhiều phàn nàn hoặc chi phí tăng cao.

I. Rủi ro trong kiểm thử phần mềm là gì?

• Trong kiểm thử phần mềm, các rủi ro là những vấn đề có thể gây nguy hiểm cho những mục tiêu của các bên liên quan đến dự án. Nó là một kết quả tiêu cực hoặc không mong muốn. Một rủi ro là điều gì đó mà chưa từng xảy ra và nó có thể không bao giờ xảy ra; Đó là một vấn đề tiềm ẩn.

• Trong tương lai, rủi ro xảy ra với xác suất từ 0% đến 100%; Đó chỉ là khả năng, không phải là sự chắc chắn.

• Cơ hội rủi ro trở thành một kết quả 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ụ, hầu hết mọi người sẽ bị cảm lạnh trong suốt cuộc đời của họ, thường là nhiều lần. Nhưng cá nhân khỏe mạnh sẽ không bị hậu quả nghiêm trọng. Vì vậy, mức độ rủi ro tổng thể liên quan đến chứng cảm lạnh là thấp đối với người này. Mặt khác, nguy cơ bị cảm lạnh đối với người cao tuổi bị khó thở sẽ cao hơn. Vì vậy, trong trường hợp này mức độ rủi ro tổng thể liên quan đến cảm lạnh là cao.

• Chúng ta có thể phân loại rủi ro thành hai loại sau:

  • Rủi ro sản phẩm (các yếu tố liên quan đến sản phẩm do công việc sản xuất, ví dụ những điều chúng ta đang thử nghiệm).

  • Rủi ro của dự án (các yếu tố liên quan đến cách công việc được thực hiện, ví dụ dự án thử nghiệm).

II. Thử nghiệm dựa trên rủi ro

• Thử nghiệm dựa trên rủi ro về cơ bản là một thử nghiệm được thực hiện cho dự án dựa trên rủi ro. Thử nghiệm dựa trên rủi ro sử dụng rủi ro để ưu tiên và nhấn mạnh các bài kiểm tra thích hợp trong quá trình thực hiện kiểm tra. Nói một cách đơn giản - Rủi ro là xác suất xảy ra một kết quả không mong muốn.

• Kết quả này cũng liên quan đến tác động. Vì có thể không có đủ thời gian để kiểm tra tất cả các chức năng, thử nghiệm dựa trên rủi ro liên quan đến việc kiểm tra các chức năng có tác động cao nhất và xác suất thất bại.

• Thử nghiệm dựa trên rủi ro là ý tưởng chúng ta có thể tổ chức các nỗ lực thử nghiệm của mình theo cách làm giảm mức tồn tại của rủi ro sản phẩm khi triển khai hệ thống.

  • Các thử nghiệm dựa trên rủi ro bắt đầu từ đầu dự án, xác định rủi ro đối với chất lượng hệ thống và sử dụng kiến ​​thức về rủi ro để hướng dẫn lập kế hoạch kiểm tra, quy định, chuẩn bị và thực hiện thử nghiệm.

  • Thử nghiệm dựa trên rủi ro liên quan đến cả việc giảm thiểu - kiểm tra để cung cấp cơ hội để giảm khả năng xảy ra khiếm khuyết, đặc biệt là các khiếm khuyết có ảnh hưởng lớn - và kiểm tra ngẫu nhiên để xác định các hoạt động đã tạo ra các khiếm khuyết trong quá khứ gây phiền nhiễu cho chúng ta.

  • Thử nghiệm dựa trên rủi ro cũng bao gồm đo mức độ chúng ta đang làm bằng việc tìm kiếm và loại bỏ các khiếm khuyết trong các vùng quan trọng.

  • Thử nghiệm dựa trên rủi ro cũng có thể bao gồm việc sử dụng phân tích rủi ro để xác định các cơ hội chủ động để loại bỏ hoặc ngăn ngừa khiếm khuyết thông qua các hoạt động không thử nghiệm và để giúp chúng ta lựa chọn hoạt động thử nghiệm nào để thực hiện.

• Mục đích của thử nghiệm dựa trên rủi ro không thể thực tế - một dự án không có rủi ro. Những gì chúng ta có thể nhận được từ thử nghiệm dựa trên rủi ro là thực hiện kiểm tra với các phương pháp hay nhất trong quản lý rủi ro để đạt được kết quả dự án cân bằng rủi ro với chất lượng, tính năng, ngân sách và tiến độ.

Làm sao để thực hiện thử nghiệm dựa trên rủi ro:

• Lập một danh sách các rủi ro được ưu tiên.

• Thực hiện kiểm tra khám phá mỗi rủi ro.

• Khi những rủi ro được giải quyết và những cái mới xuất hiện, điều chỉnh nỗ lực thử nghiệm của bạn để tập trung vào phân đoạn hiện tại.

III. Rủi ro sản phẩm trong kiểm thử phần mềm

• Rủi ro sản phẩm là khả năng hệ thống hoặc phần mềm có thể không đáp ứng hoặc chỉ đáp ứng được một số kỳ vọng mong muốn của khách hàng, người sử dụng hoặc các bên liên quan. (Một số người còn gọi “Rủi ro về sản phẩm” là “Rủi ro về chất lượng” vì chúng là những rủi ro đối với chất lượng của sản phẩm.)

• Các rủi ro về sản phẩm mà có thể khiến sản phẩm hoặc phần mềm gặp nguy hiểm là:

  • Nếu phần mềm bỏ qua một số chức năng quan trọng mà khách hàng chỉ định, người sử dụng yêu cầu hoặc các bên liên quan đã thống nhất.

  • Nếu phần mềm không đáng tin cậy và thường xuyên hoạt động bị lỗi.

  • Nếu phần mềm hỏng theo những cách gây ra thiệt hại về tài chính hoặc thiệt hại khác cho người sử dụng hoặc công ty mà người sử dụng đang làm việc.

  • Nếu phần mềm có vấn đề liên quan đến một đặc tính chất lượng cụ thể, có thể không phải là tính năng, mà là an ninh, độ tin cậy, khả năng sử dụng, tính bảo trì hoặc hiệu suất.

• Hai lời khuyên nhanh chóng về phân tích rủi ro sản phẩm:

  • Thứ nhất, bạn nên nhớ cân nhắc cả khả năng xảy ra rủi ro và tác động của rủi ro. Trong khi bạn có thể cảm thấy tự hào bằng cách tìm kiếm được nhiều khuyết điểm nhưng thử nghiệm cũng là về xây dựng sự tự tin trong các chức năng chính. Chúng ta cần phải kiểm tra cả những điều có thể sẽ không phá vỡ nhưng sẽ rất xấu nếu chúng đã thực hiện.

  • Thứ hai, phân tích rủi ro sớm, thường là các cuộc phỏng đoán đã được huấn luyện. Tại các mốc quan trọng của dự án, điều quan trọng là phải đảm bảo rằng bạn xem lại và theo dõi phân tích rủi ro.

IV. Rủi ro dự án trong kiểm thử phần mềm

• Thử nghiệm là một hoạt động giống như phần còn lại của dự án và do đó nó tiềm ẩn rủi ro gây nguy hiểm cho dự án.

• Rủi ro của dự án có thể gây nguy hiểm cho dự án là:

  • Rủi ro như truyền tải các đề mục thử nghiệm muộn cho nhóm thử nghiệm hoặc các vấn đề có sẵn với môi trường thử nghiệm.

  • Cũng có những rủi ro gián tiếp như sự chậm trễ quá mức trong việc sửa chữa các khiếm khuyết được tìm thấy trong quá trình kiểm thử hoặc các vấn đề với việc hỗ trợ quản lý hệ thống chuyên nghiệp cho môi trường thử nghiệm.

• Đối với bất kỳ rủi ro nào, rủi ro dự án hoặc rủi ro sản phẩm nào, chúng ta có 4 hành động tiêu biểu mà có thể thực hiện được là:

  • Giảm thiểu: Thực hiện các bước nâng cao để giảm khả năng và tác động của rủi ro.

  • Dự phòng: Có kế hoạch để giảm thiểu khả năng rủi ro trở thành kết quả.

  • Chuyển tiếp: thuyết phục một số thành viên khác của nhóm hoặc các bên liên quan dự án để giảm xác suất hoặc chấp nhận tác động của rủi ro.

  • Bỏ qua: Bỏ qua rủi ro, thường là lựa chọn tốt chỉ khi có rất ít phương pháp mà có thể được thực hiện hoặc khi khả năng và tác động của rủi ro đó là thấp trong dự án.

V. Phân tích rủi ro là gì

• Có rất nhiều kỹ thuật để phân tích rủi ro, đó là:

  • Một kỹ thuật để phân tích rủi ro là đọc kỹ các yêu cầu kỹ thuật, thiết kế chi tiết kỹ thuật, tài liệu hướng dẫn sử dụng và các hạng mục khác.

  • Một kỹ thuật khác là động não với nhiều bên liên quan đến dự án.

  • Một ví dụ khác là hình thành một chuỗi các cuộc họp riêng lẻ hoặc nhóm nhỏ với các chuyên gia kinh doanh và công nghệ trong công ty.

  • Một số người sử dụng tất cả các kỹ thuật này khi họ có thể. Còn đối với chúng ta, cách tiếp cận dựa trên các bên liên quan và chuyên gia then chốt thích hợp hơn với cách tiếp cận dựa trên tài liệu thuần túy, vì cách tiếp cận nhóm sử dụng kiến thức, sự khôn ngoan và cái nhìn sâu sắc của toàn bộ nhóm để xác định thử nghiệm và mức độ.

• Các thước đo được sử dụng để đánh giá khả năng và tác động thay đổi. Một số người đánh giá chúng cao, trung bình và thấp. Một số sử dụng thang điểm từ 1-10. Vấn đề với đối thang điểm 1-10 là rất khó để đánh giá các giá trị 2 từ 3 hoặc 7 từ 8, trừ khi sự khác biệt giữa mỗi đánh giá được xác định rõ ràng. Một thang năm điểm (rất cao, cao, trung bình, thấp và rất thấp) có xu hướng hoạt động tốt hơn cả.

• Chúng ta hãy thảo luận về một số rủi ro xảy ra cùng với một số lựa chọn để quản lý chúng:

  • Tính pháp lý hoặc vấn đề chất lượng sản phẩm mà nó có thể ngăn chặn các thử nghiệm: Có thể được thực hiện vừa phải bởi việc lên kế hoạch cẩn thận, phân loại lỗi và quản lý tốt, và thiết kế thử nghiệm mạnh mẽ.

  • Các bài thử nghiệm sẽ không cài đặt trong môi trường thử nghiệm: Có thể được giảm thiểu thông qua kiểm thử sơ lược (hoặc chấp nhận) trước khi bắt đầu giai đoạn thử nghiệm hoặc là một phần của một phiên bản hoặc tích hợp liên tục. Một quá trình gỡ bỏ sẽ được xác định là một kế hoạch dự phòng tốt.

  • Thay đổi quá mức đối với sản phẩm làm mất hiệu lực kết quả thử nghiệm hoặc yêu cầu cập nhật các trường hợp thử nghiệm, kết quả mong muốn và môi trường: Chúng có thể được giảm thiểu tốt các quy trình kiểm soát thay đổi, thiết kế thử nghiệm mạnh mẽ và tài liệu kiểm thử không đáng kể. Khi có sự cố nghiêm trọng xảy ra, sự chuyển đổi rủi ro bằng cách leo thang sang quản lý thường là theo thứ tự sắp xếp.

  • Các môi trường thử nghiệm không đầy đủ hoặc không thực tế sẽ mang lại kết quả sai lệch: Một lựa chọn là chuyển đổi các rủi ro sang quản lý bằng cách giải thích các giới hạn về kết quả kiểm thử thu được trong một số môi trường hạn chế. Giảm thiểu - đôi khi hoàn thành sự giảm nhẹ - có thể đạt được bằng cách thuê các thử nghiệm như các thử nghiệm hiệu năng đặc biệt nhạy cảm với môi trường kiểm tra thích hợp.

• Chúng ta cùng đi qua một số rủi ro bổ sung và đưa ra cách để quản lý chúng:

  • Các vấn đề về tổ chức như thiếu nhân sự, kỹ năng hay đào tạo, vấn đề giao tiếp và đáp ứng các kết quả kiểm thử, các mong đợi không cần thiết về việc thử nghiệm có thể đạt được và sự phức tạp của nhóm hoặc của tổ chức dự án.

  • Các vấn đề của nhà cung cấp như các vấn đề với nền tảng hoặc phần cứng cơ bản, có lỗi trong việc xem xét các vấn đề thử nghiệm trong hợp đồng hoặc không đáp ứng đúng các vấn đề khi chúng phát sinh.

  • Các vấn đề kỹ thuật liên quan đến các yêu cầu mơ hồ, mâu thuẫn hoặc không được ưu tiên, một số lượng lớn yêu cầu đối với các ràng buộc khác của dự án, sự phức tạp của hệ thống cao và các vấn đề về chất lượng với thiết kế, mã hoặc các thử nghiệm.

• Cần lưu ý rằng không phải tất cả các dự án đều phải chịu những rủi ro tương tự nhau.

• Và cuối cùng, chúng ta không nên quên rằng ngay cả thực hiện kiểm thử cũng có thể có những rủi ro ảnh hưởng đến dự án.

• Ví dụ: có một rủi ro là kế hoạch kiểm thử bỏ qua các thử nghiệm cho một vùng chức năng nào đó hoặc các trường hợp thử nghiệm không được thực hiện tại các vùng quan trọng của hệ thống.

• Quản lý rủi ro trong giai đoạn lập kế hoạch cần phải lặp lại ở giai đoạn đầu của dự án vì những rủi ro tại thời điểm này là những phỏng đoán được đào tạo. Một trong những phỏng đoán có thể là sai. Đảm bảo rằng bạn có kế hoạch đánh giá lại và điều chỉnh rủi ro của mình một cách thường xuyên trong dự án và thực hiện sửa đổi phương hướng thích hợp cho việc thử nghiệm.

• Bạn nên quản lý rủi ro phù hợp, dựa trên khả năng và tác động của chúng. Tách các rủi ro bằng cách hiểu được làm thế nào mà nỗ lực của bạn có thể bỏ ra để giải quyết chúng.

Kết luận:

• Những rủi ro đã được phân tích hoặc đang trong quá trình kiểm soát cần được đề ra trong các cuộc họp tiến độ dự án định kỳ. Trong cuộc họp cần chỉ rõ tường tận các rủi ro, đặc biệt là các rủi ro có tính chất nghiêm trọng. Việc hiểu rõ ràng và tường tận rủi ro giúp tránh gặp phải những rủi ro na ná trong tương lai (bao gồm cả trong và ngoài dự án hiện tại).

Nguồn: http://istqbexamcertification.com/what-is-risk-in-software-testing/ http://istqbexamcertification.com/what-is-risk-based-testing/ http://istqbexamcertification.com/what-is-product-risk-in-software-testing/ http://istqbexamcertification.com/what-is-project-risk-in-software-testing/ http://istqbexamcertification.com/what-is-risk-analysis/