Để ngăn ngừa các mối nguy hiểm đã nhận dạng được không trở thành hiện thực thì cần phải chú ý đặc biệt đến chúng. Gerrard [4] cho rằng ngăn chặn các lỗi không cho chúng xảy ra cũng rất quan trọng đối với người kiểm thử. Người kiểm thử chịu trách nhiệm ngăn chặn cũng như phát hiện ra các lỗi. Họ buộc phải tác động để người phát triển cùng hành động nhằm giảm thiểu nguy cơ.
IEC [9] đã định nghĩa một vài thuật ngữ liên quan đến giảm thiểu lỗi. Nó chỉ ra rằng việc giảm thiểu rủi ro khi thực hiện các hệ thống có liên quan đến an toàn là rất quan trọng. Giảm bớt rủi ro để đáp ứng được mức rủi ro chấp nhận được cho một tình huống cụ thể được gọi là giảm thiểu rủi ro cần thiết. Rủi ro chấp nhận được phụ thuộc vào xác suất và hậu quả của một sự kiện nguy hiểm cụ thể. Một hệ thống liên quan đến cần phải thỏa mãn tiêu chuẩn giảm thiểu rủi ro cần thiết. Phương pháp để đạt được mức rủi ro chấp nhận được thường được gọi là "thấp đến mức được thực tế chấp nhận" (ALARP – as low as reasonable practicable). Mức rủi ro được chia ra thành các vùng. Vùng nằm giữa rủi ro không thể chấp nhận được và rủi ro có thể chấp nhận được thì được gọi là vùng ALARP. Vùng này được xác định là một vùng vẫn còn nhiều rủi ro, nhưng nó có thể được chấp nhận nếu một lợi ích nào đó đã đạt được. Những tốn kém cho việc giảm bớt rủi ro sẽ phụ thuộc vào độ lớn của rủi ro đó. Điều này được minh họa trong Hình 1.7, trong đó vùng ALARP được đặt ở giữa.
Hình 1.1 Vùng ALAPR Rủi ro không thể chấp nhận được trừ những trường hợp thật đặc biệt Vùng không thể chấp nhận được Vùng ALARP Chấp nhận được (rủi ro được chấp nhận nếu một lợi ích nào đó
đã đạt được )
Vùng được chấp nhận rộng rãi
Chỉ chấp nhận nếu việc giảm rủi ro thêm nữa là không thực tế hoặc nếu chi phí quá vô lý so với những gì thu được
Rủi ro không đáng kể
Khi rủi ro được giảm bớt thì cần thiét phaỉ giảm tiếp để thỏa mãn ALARP. Khái niệm giảm thiểu tỷ lệ được thể hiện bằng hình tam giác
Để giảm thiểu rủi ro, gần như mọi rủi ro nghiêm trọng đều phải được chú ý đặc biệt. Tập trung vào kiểm thử và phân tích mã chương trình có thể cũng là một giải pháp. Một cơ hội khác là phân tích cấu trúc của chương trình và tối thiểu hóa rủi ro. Có một cách để thực hiện việc này là sử dụng phương pháp phân tích cây sai sót (FTA). Việc phân tích này có thể hữu ích trong nhiều lĩnh vực nhưng không phải là phương pháp hiệu quả nhất trong lĩnh vực phần mềm. Điều này đặc biệt đúng trong các hệ thống yêu cầu độ an toàn cao, những hệ thống mà nên được đảm bảo an toàn bằng cách sử dụng các hệ thống cho phép dư thừa (tài nguyên) và cho phép tiếp tục hoạt động mặc dù vẫn mắc lỗi. Chấp nhận điều đó sẽ có lợi hơn là phải mở rộng năng lực của thiết kế. Trong những phần mềm phức tạp, rất khó để đảm bảo rằng mọi việc đều đúng đắn và không lãng phí thời gian. Do đó chúng ta cần phải tránh những giải pháp quá phức tạp.
Một kỹ thuật dễ dàng và hiệu quả hơn đó là ngăn cản không cho sự kiện gây ra lỗi xảy ra, hoặc ngăn cản hoặc giảm thiểu ảnh hưởng của sự kiện này. Cái đó được gọi là một thanh chắn hoặc rào cản. Smith [8] đã định nghĩa “thanh chắn là một chướng ngại có thể (i) ngăn cản, không cho một hành động được thực hiện hoặc một sự kiện nào đó được xảy ra, hoặc (ii) ngăn cản hoặc giảm thiểu tác hại của hậu quả, hạn chế tầm ảnh hưởng của hậu quả hoặc làm yếu chúng đi theo một cách nào đó". Đây có thể là một giải pháp kết hợp xã hội - kỹ thuật giống như dấu hiệu không hút thuốc hoặc các cảnh báo.
Tóm tắt Chương 1
Tóm lại, trong chương này chúng ta đã tìm hiểu được rủi ro là gì và cách phòng ngừa, xử lý các rủi ro. Đồng thời, chúng ta cũng đã hiểu rõ hơn kiểm thử phần mềm là gì và có các loại hình kiểm thử nào. Đặc biệt là nghiên
cứu tìm hiểu một số phương pháp kiểm thử dựa trên các rủi ro đã phát hiện được khi phân tích.
Chương sau sẽ trình bày về cách thức sắp xếp thứ tự ưu tiên cho các kiểm thử theo mức độ nguy hiểm của các rủi ro.
Chương 2 Phân loại ưu tiên các kiểm thử
Trong chương trước, tiêu điểm là tìm hiểu xem phần mềm bị sai hỏng như thế nào và quyết định nên kiểm thử cái gì. Trong chương này này, mục tiêu là phát hiện ra những bộ phận nào của phần mềm gây rủi ro nhiều hơn so với các bộ phận khác. Sau đó sẽ sắp xếp ưu tiên kiểm thử cho những bộ phận có nguy cơ xảy ra sai sót cao hơn trước.
Để làm được điều đó, trước tiên phải tìm xem những nhân tố nào sẽ tác động lớn đến các thiệt hại do rủi ro gây ra. Những bộ phận quan trọng của hệ thống nếu bị hư hại có thể sẽ gây ra thiệt hại lớn hơn. Những nhân tố làm tăng xác suất xuất hiện rủi ro liên quan đến quá trình phát triển và lập trình sẽ được trình bày trong các mục 2.1 và 2.2. Những nhân tố này được gọi là những tác nhân gây lỗi vì chúng được sử dụng để xác định các bộ phận hệ thống có nhiều lỗi. Hai ví dụ về việc sử dụng các nhân tố này sẽ được trình bày trong các mục còn lại.