Cách phân tích rủi ro để có chất lượng phần mềm tốt hơn và làm khách hàng hài lòng!
Bài đăng này đã không được cập nhật trong 3 năm
Phân tích lỗi và ảnh hưởng của lỗi (FMEA) là 1 kỹ thuật Quản lý rủi ro. Nếu được triển khai đúng cách, đây có thể là một đóng góp tuyệt vời cho các quy trình Đảm bảo chất lượng. Trong bài viết này, mục tiêu là giới thiệu cho bạn kỹ thuật Phân tích rủi ro này để đạt đến mục đích cuối cùng là cải thiện chất lượng phần mềm.
Phân tích lỗi và ảnh hưởng của lỗi (FMEA)
FMEA chủ yếu được sử dụng bởi quản lý cấp trên hoặc các bên liên quan. Trên thực tế, những kiểm thử viên hiểu rất ít về kỹ thuật này. Nhưng hiện tại xu hướng đang thay đổi, nếu những người kiểm tra hiểu đúng khái niệm này, họ có thể thúc đẩy tư duy của họ lên một cấp khi viết các trường hợp kiểm thử, bằng cách sử dụng kỹ thuật này để:
Hiểu mục đích thử nghiệm ứng dụng của các bên liên quan.
Hiểu doanh nghiệp.
Tìm ra các kịch bản thử nghiệm nâng cao dựa trên mối quan tâm của doanh nghiệp và cấp quản lý.
Tìm ra các trường hợp thử nghiệm hiệu quả để cung cấp phạm vi bao phủ tốt hơn cho các chức năng dễ xảy ra rủi ro.
Ưu tiên các trường hợp thử nghiệm . Quyết định những gì cần kiểm tra và những gì nên trì hoãn ở bất kỳ giai đoạn nào
Cơ sở của phương pháp phân tích rủi ro (phân tích lỗi và ảnh hưởng của lỗi) FMEA
Phân tích rủi ro là một khía cạnh quan trọng của Quản lý Kiểm thử. Câu hỏi đặt ra sau đó - Phân tích Rủi ro là gì? Và tại sao nó lại quan trọng? Để hiểu được điều này, điều quan trọng là phải hiểu Rủi ro là gì ?
Rủi ro theo nghĩa đen của nó là khả năng xảy ra một kết quả hoặc sự kiện tiêu cực không như mong muốn. Rủi ro nếu không được xử lý hoặc quản lý đúng cách có thể dẫn đến chất lượng kém, khách hàng không hài lòng và đôi khi thua lỗ trong kinh doanh.
Rủi ro có 2 thuộc tính:
-
Xác suất
-
Tác động
Xác suất có nghĩa là khả năng xảy ra rủi ro cụ thể, và tác động có nghĩa là mức độ ảnh hưởng của rủi ro.
Phân tích rủi ro là gì?
Phân tích rủi ro là một cơ chế mà theo đó các rủi ro tiềm ẩn đã được xác định, phân tích và nghiên cứu kỹ lưỡng để tìm ra xác suất và tác động của nó. Nên đo lường hai thuộc tính và dựa trên kết quả có thể xác định được như sau :
Cái gì kiểm tra đầu tiên?
Cái gì để kiểm tra tiếp theo ?
Cái gì không cần thử nghiệm (Trong lần này)?
Có nhiều phương pháp thực hiện Phân tích rủi ro và chúng được phân loại rộng rãi thành hai loại
Informal Techniques : Đây là những kỹ thuật dựa trên kinh nghiệm, khả năng phán đoán và trực giác.
Formal Techniques: Xác định và cân nhắc các thuộc tính rủi ro.
Phân tích lỗi và ảnh hưởng của lỗi (FMEA)
Đây là một phương pháp phổ biến khi thực hiện Phân tích Rủi ro. FMEA là một Formal Techniques để thực hiện Phân tích rủi ro. Đây là một công cụ có hệ thống và được định lượng dưới dạng Bảng tính, hỗ trợ các thành viên dự án trong việc phân tích những gì có thể dẫn đến lỗi. Để thực hiện FMEA, cần yêu cầu những người phù hợp. một đại diện từ mọi bên liên quan, bao gồm cả khách hàng.
Miêu tả
Quy trình phân tích lỗi và ảnh hưởng bắt đầu và tiếp tục với các hoạt động tìm hiểu, phân tích. Người tham gia cần xác định tất cả các thành phần, mô-đun, mối tương quan, hạn định những gì có thể bị lỗi trong môi trường Production dẫn đến chất lượng kém, độ tin cậy thấp và có thể dẫn đến thua lỗ trong kinh doanh.
Trong quá trình phân tích lỗi và ảnh hưởng, chúng ta không chỉ xác định mức độ tổn thất mà còn cố gắng xác định nguyên nhân của những lỗi này. Để đo đạc phân tích lỗi và ảnh hưởng, chúng ta cần yêu cầu 3 thuộc tính:
Mức độ nghiêm trọng của lỗi (S)
Mức độ ưu tiên của lỗi (P)
Khả năng xảy ra lỗi (L)
Mỗi thuộc tính này được đặt trong một thang điểm bên dưới
Mức độ nghiêm trọng
Mô tả | Độ nghiêm trọng | Thang điểm |
---|---|---|
Mất dữ liệu,phần cứng hoặc các vấn đề về bảo mật | Urgent | 1 |
Mất chức năng mà không có giải pháp thay thế | High | 2 |
Mất chức năng và có giải pháp thay thế | Medium | 3 |
Mất 1 phần chức năng | Low | 4 |
Lỗi nhỏ về giao diện | No | 5 |
Thang đo độ ưu tiên
Mô tả | Độ ưu tiên | Thang điểm |
---|---|---|
Mất hoàn toàn giá trị của hệ thống | Urgent | 1 |
Mất giá trị không thể chấp nhận được của hệ thống | High | 2 |
Có thể giảm giá trị của hệ thống | Medium | 3 |
Giảm giá trị hệ thống trong tầm có thể chấp nhận được | Low | 4 |
Giá trị hệ thống giảm không đáng kể | No | 5 |
Thang đo khả năng có thể xảy ra
Mô tả | Khả năng | Thang điểm |
---|---|---|
Chắc chắn sẽ ảnh hưởng tới toàn bộ người dùng | Urgent | 1 |
Chắc chắn sẽ ảnh hưởng tới nhiều người dùng | High | 2 |
Có thể ảnh hưởng tới nhiều người dùng | Medium | 3 |
Có thể ảnh hưởng tới 1 vài người dùng | Low | 4 |
Không định mức được số lượng người dùng có thể bị ảnh hưởng | No | 5 |
Tất cả ba thuộc tính này (Mức độ nghiêm trọng, Mức độ ưu tiên và Khả năng xảy ra) được đo lường riêng lẻ trong quy mô và sau đó nhân lên để có được Số mức độ ưu tiên rủi ro (RPN).
Tức là Số ưu tiên rủi ro (RPN) = S * P * L
Dựa trên giá trị RPN này, chúng tôi xác định mức độ thử nghiệm. Thấp hơn là RPN, cao hơn là Rủi ro.
Hãy thử hiểu khái niệm này bằng một ví dụ:
Ví dụ về phân tích độ ảnh hưởng của lỗi (Đây là một ví dụ giả định chỉ nhằm mục đích hiểu biết. Việc triển khai thực tế và các tính năng có thể khác nhau)
Hãy xem xét một ví dụ đơn giản về một ứng dụng ngân hàng có 4 tính năng.
Tính năng 1: Rút tiền
Tính năng 2: Đặt cọc
Đặc điểm 3: Cho vay mua nhà
Tính năng 4: Tiền gửi cố định.
Một nhóm Phân tích rủi ro được thành lập bao gồm người quản lý ngân hàng, người quản lý kiểm tra UAT (đại diện cho người dùng cuối), chuyên gia kỹ thuật, chuyên gia kiểm thử, Quản trị viên mạng, DBA và Người quản lý dự án.
Sau một loạt các phiên thảo luận, nhóm đã đưa ra các Rủi ro sau:
Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất vay mua nhà.
Hệ thống bị lỗi cùng lúc ở 200 người dùng .
Hệ thống không xử lý được các tài liệu có dung lượng lớn hơn 6 MB.
Bây giờ chúng ta hãy thử tính mức độ nghiêm trọng, mức độ ưu tiên và khả năng xảy ra của những rủi ro đã xác định này.
Mức độ nghiêm trọng
Chức năng | Độ nghiêm trọng | Thang điểm |
---|---|---|
Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất vay mua nhà | Verify High | 2 |
Hệ thống bị lỗi cùng lúc ở 200 người dùng | High | 3 |
Hệ thống không xử lý được các tài liệu có dung lượng lớn hơn 6 MB | Veriy High | 2 |
Độ ưu tiên
Chức năng | Độ ưu tiên | Thang điểm |
---|---|---|
Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất vay mua nhà | Verify High | 2 |
Hệ thống bị lỗi cùng lúc ở 200 người dùng | High | 3 |
Hệ thống không xử lý được các tài liệu có dung lượng lớn hơn 6 MB | High | 3 |
Khả năng xảy ra
Chức năng | Khả năng | Thang điểm |
---|---|---|
Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất vay mua nhà | High | 3 |
Hệ thống bị lỗi cùng lúc ở 200 người dùng | High | 3 |
Hệ thống không xử lý được các tài liệu có dung lượng lớn hơn 6 MB | Low | 4 |
Bây giờ chúng ta hãy đặt tất cả các thuộc tính này lại với nhau:
Chức năng | Độ nghiêm trọng | Độ ưu tiên | Khả năng xảy ra |
---|---|---|---|
Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất vay mua nhà | 2 | 2 | 3 |
Hệ thống bị lỗi cùng lúc ở 200 người dùng | 3 | 3 | 3 |
Hệ thống không xử lý được các tài liệu có dung lượng lớn hơn 6 MB | 2 | 3 | 4 |
Bây giờ hãy tính Số ưu tiên rủi ro (RPN = Mức độ nghiêm trọng * Mức độ ưu tiên * Khả năng xảy ra)
Chức năng | Độ nghiêm trọng | Độ ưu tiên | Khả năng xảy ra | RPN |
---|---|---|---|---|
Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất vay mua nhà | 2 | 2 | 3 | 12 |
Hệ thống bị lỗi cùng lúc ở 200 người dùng | 3 | 3 | 3 | 27 |
Hệ thống không xử lý được các tài liệu có dung lượng lớn hơn 6 MB | 2 | 3 | 4 | 24 |
Bám theo logic : thấp hơn là RPN - cao hơn là rủi ro.
Cho ví dụ cụ thể này, tính năng 1 (Logic nghiệp vụ phức tạp trong trường hợp tính lãi suất của khoản vay mua nhà) có rủi ro cao nhất và Tính năng 2 (Hệ thống không thành công với 200 người dùng đồng thời) có rủi ro thấp nhất.
Làm thế nào để sử dụng điều này để lấy các trường hợp thử nghiệm?
Vì Tính năng 1 là tính năng rủi ro nhất, các trường hợp thử nghiệm phải nghiêm ngặt và chuyên sâu hơn. Viết các trường hợp thử nghiệm để bao phủ toàn bộ chức năng và các chức năng bị ảnh hưởng khác . Sử dụng tất cả các loại kỹ thuật viết trường hợp thử nghiệm (Phân vùng tương đương, giá trị biên, sơ đồ chuyển trạng thái, bảng quyết định ) để suy ra các trường hợp thử nghiệm.
Các trường hợp thử nghiệm không chỉ có chức năng mà còn phi chức năng (Load test, Stress Test, v.v.). Về cơ bản, chúng ta cần thực hiện kiểm tra toàn diện tính năng cụ thể này, vì vậy hãy căn cứ vào các trường hợp thử nghiệm bạn đã thiết kế. Ngoài ra, hãy xem xét tất cả các mô-đun phụ thuộc vào tính năng quan trọng này.
Tính năng 2 là tính năng rủi ro ít nhất, vì vậy hãy căn cứ vào các trường hợp thử nghiệm của bạn dựa trên chức năng chính. Chỉ cần các trường hợp thử nghiệm chính để xác nhận rằng tính năng hoạt động như mong đợi là đủ.
Tính năng 3 là một tính năng rủi ro trung bình, vì vậy hãy căn cứ vào các trường hợp thử nghiệm của bạn để bao phủ chức năng chính và các chức năng phụ thuộc. Viết một số trường hợp thử nghiệm BVA để xác thực một số trường hợp tiêu cực. Mức độ của các trường hợp thử nghiệm phải nằm giữa Rủi ro cao và Rủi ro thấp. Nếu được yêu cầu, hãy làm thêm một số trường hợp thử nghiệm phi chức năng.
Phân tích lỗi và ảnh hưởng (FMEA) và các mức độ kiểm tra Dựa trên giá trị RPN, có thể xác định được phạm vi hoặc mức độ thử nghiệm cần thực hiện.
Thông thường nếu:
RPN nằm trong khoảng từ 1-10, nên thực hiện Kiểm tra mở rộng (Bao gồm toàn bộ tính cả trong và ngoài, cùng các tính năng phụ thuộc.
RPN trong khoảng từ 11 đến 30, thực hiện Kiểm tra cân bằng (Bao gồm tất cả các chức năng chính của tính năng / mô-đun)
RPN trong khoảng 31-70, chúng tôi thực hiện Kiểm tra cơ hội (Bao gồm các chức năng cơ bản của tính năng / mô-đun)
RPN hơn 70 - Không thử nghiệm hoặc chỉ thử nghiệm khi thời gian cho phép, chỉ báo cáo vấn đề bất thường.
Những phạm vi hoặc con số này có thể thay đổi tùy theo bản chất của dự án.
Kết luận
Phân tích rủi ro bằng FMEA đòi hỏi thời gian và kinh nghiệm. Chỉ có thể đạt được kết quả mong muốn khi có sự tham gia bình đẳng của tất cả các thành viên trong dự án. Mặc dù kỹ thuật này là khá phổ biến, nó vẫn đòi hỏi một loạt các phiên phân tích, điều tra và điều quan trọng không kém là phải ghi lại tất cả các rủi ro đã xác định.
Vì hầu hết các ứng dụng là độc quyền, nên thang đo để đo các thông số của FMEA (tức là Mức độ ưu tiên, Mức độ nghiêm trọng và Khả năng xảy ra) cũng phụ thuộc vào ứng dụng. Nếu được thực hiện một cách thích hợp, kỹ thuật FMEA có nhiều lợi thế. Nó có thể được sử dụng để xác định rủi ro tiềm ẩn và dựa trên cơ sở này, dự án có thể hoạch định một chiến lược giảm thiểu rủi ro hiệu quả. Nguồn : https://www.softwaretestinghelp.com/failure-mode-and-effects-analysis-fmea/#more-3199
All rights reserved