RBT - risk analysis

반응형

위험분석(Risk Analysis)

위험 요소 식별 (Identifying Risk Factors)

위험 분석 기반 테스트를 수행할 때, 첫 단계는 테스트가 필요한 피처들을 모두 나열하는 것이다. 이 과정은 테스트 범위를 설정하기 위한 출발점이 되며, 시스템의 기능적 및 비기능적 요소들이 모두 포함된다. 이렇게 식별된 피처들은 이후 위험 분석의 대상이 되며, 위험 분석 결과에 따라 테스트 계획이 수립된다.

피처들은 소프트웨어 요구사항 명세서를 바탕으로 식별할 수 있다. 요구사항 명세서는 시스템이 충족해야 할 기능적 요구사항뿐만 아니라 성능, 신뢰도, 가용성, 보안성과 같은 비기능적 요구사항도 포함하고 있다. 이 명세서는 테스트의 기준이 되는 중요한 문서이므로, 여기 나열된 요구사항들을 우선적으로 테스트할 피처로 삼는다.

그러나 요구사항 명세서가 완벽하지 않을 수 있으며, 사용자 입장에서 필요한 요구사항이 누락될 가능성도 존재한다. 이럴 경우, 테스터는 단순히 명세서만 참고하는 것에 그치지 않고, 품질 모델을 활용하여 추가적인 테스트 대상 피처들을 적극적으로 식별할 필요가 있다.

시스템의 유형에 따라 중요한 품질 요소는 달라질 수 있다. 예를 들어, 다수의 사용자 또는 클라이언트 시스템을 지원해야 하는 서버나 미들웨어 시스템에서는 확장성(scalability)이 중요한 품질 요소로 요구될 가능성이 크다. 많은 사용자나 클라이언트가 증가하더라도 성능이 유지되어야 하기 때문이다. 반면, 자원이 제한된 장치에서 작동하는 임베디드 소프트웨어의 경우, 성능(performance) 및 시스템 자원의 효율적 활용이 중요하다. 또한, 주변 장치의 오작동에도 불구하고 시스템이 안정적으로 동작해야 하므로 신뢰성 및 결함 허용성 역시 중요한 품질 요소가 될 수 있다.

이와 같이, 위험 요소를 식별하는 과정에서는 시스템의 기능적 요구사항뿐 아니라 비기능적 품질 요소를 함께 고려하여 테스트 범위를 명확히 설정하는 것이 중요하다.

위험도 산정(Risk assessment)

위험도 산정은 각 피처를 테스트 대상으로 포함할지 결정하고, 효과적인 테스트 전략을 수립하는 데 중요한 역할을 한다. 위험도는 발생 가능성(likelihood), 심각성(severity), 긴급성(urgency)을 기준으로 평가되며, 각 항목에 정량적 등급을 부여해 분석이 이루어진다. 이 등급은 3단계 또는 5단계로 세분화될 수 있으며, 이를 통해 각 피처의 위험도를 명확하게 평가할 수 있다.

 

발생 가능성 ---------------------

발생 가능성은 해당 피처가 장애를 일으킬 확률을 의미한다. 이를 평가할 때는 다음 세 가지 측면을 고려한다:

1. 기술적 복잡성
   구현이 복잡할수록 결함 발생 가능성이 증가한다. 복잡한 알고리즘이나 다수의 모듈 간 통합이 필요한 경우, 결함이 발생할 확률이 높다.
2. 결함 검출 가능성
   결함이 개발 초기 단계에서 검출될 가능성도 중요하다. 결함이 상세 설계 명세서나 코드 리뷰에서 발견될 수 있다면, 테스트 단계에서 해당 피처의 위험도는 낮아질 수 있다.
3. 사용 빈도
   사용자가 해당 피처를 얼마나 자주 사용하는가도 고려 대상이다. 사용 빈도가 높은 피처는 장애 발생 가능성이 증가한다.

(발생 가능성 등급 예시)

• 높음(High)
  기술적으로 매우 복잡하며, 통합된 모듈들이 많고, 사용자가 자주 사용하는 피처. 예: 온라인 결제 시스템의 결제 처리 모듈  
• 중간(Medium)
  기술적으로 어느 정도 복잡성이 있으나, 사용 빈도는 중간 정도인 피처. 예: 계정 설정 및 개인 정보 업데이트 기능  
• 낮음(Low)
  단순한 기능이며, 기술적 복잡성이 적고 사용 빈도도 낮은 피처. 예: 한 달에 한 번 사용되는 리포트 생성 기능

심각성  ---------------------

심각성은 장애 발생 시 시스템에 미치는 영향을 평가하는 요소이다. 장애가 발생했을 때 사용자 경험, 시스템의 안정성 및 가용성에 미치는 영향을 고려하여 심각성을 산정한다.

(심각성 등급 예시)   

• 높음(High)
  장애 발생 시 시스템 전체가 중단되거나 중요한 기능이 멈춰 사용자에게 심각한 문제를 일으키는 경우. 예: 은행 시스템의 입출금 기능 장애  
• 중간(Medium)
  장애가 일부 기능에만 영향을 미치며, 사용자는 약간의 불편을 겪지만 치명적이지 않은 경우. 예: 이메일 알림 기능이 일시적으로 작동하지 않는 경우  
• 낮음(Low)
  장애가 발생해도 사용자가 거의 영향을 받지 않거나, 시스템의 주요 기능에는 영향이 없는 경우. 예: 색상 테마 변경 기능이 작동하지 않는 경우

긴급성 ---------------------

긴급성은 장애가 발생했을 때 얼마나 빨리 수정해야 하는지를 평가하는 항목이다. 피처의 사용 빈도와 중요도, 법적 또는 계약상의 요구사항에 따라 긴급성이 평가된다.

1. 사용 빈도
   많은 사용자가 빈번하게 이용하는 기능일수록 긴급성이 높다.
2. 법적/계약적 요구사항
   장애 발생 시 법적 책임이나 계약 상의 의무로 인해 신속한 수정이 필요할 수 있다.

(긴급성 등급 예시)

• 높음(High)
  사용자들이 빈번히 사용하는 기능이며, 장애가 발생했을 때 즉각적인 대응이 필요한 경우. 예: 실시간 거래 시스템에서의 데이터 동기화 문제  
• 중간(Medium)
  사용자가 가끔 사용하는 기능으로, 장애가 발생했지만 즉각적인 수정이 필요하지 않은 경우. 예: 비밀번호 변경 기능이 작동하지 않는 경우  
• 낮음(Low)
  사용자에게 거의 영향을 미치지 않으며, 수정의 시급성이 낮은 경우. 예: 단순한 UI 요소가 비정상적으로 표시되는 경우

위험 분석 예시  ---------------------

[피처 1] 온라인 결제 시스템의 결제 처리 모듈

• 발생 가능성 : 높음
  기술적으로 복잡하며, 여러 모듈과의 통합이 필요하고 사용 빈도가 매우 높다.  
• 심각성 : 높음
  결제 시스템의 장애는 사용자에게 심각한 불편을 주고, 수익 손실로 이어질 수 있다.
• 긴급성 : 높음
  결제 처리가 중단되면 즉각적으로 대응해야 하며, 특히 계약 및 법적 책임이 따를 수 있다.

종합 위험도 : 매우 높음(High Risk)

이 피처는 발생 가능성, 심각성, 긴급성이 모두 높아 즉각적인 테스트가 필요하며, 가장 높은 우선순위로 관리해야 한다.

[피처 2] 계정 설정 및 개인 정보 업데이트 기능

• 발생 가능성 : 중간
  기술적으로 중간 정도의 복잡성이 있으며, 사용 빈도도 중간 정도이다.
• 심각성 : 중간
  장애가 발생해도 시스템 전체에는 큰 영향을 미치지 않지만, 사용자에게 불편함을 줄 수 있다.  
• 긴급성 : 중간
  중요한 기능이지만, 장애 발생 시 즉각적인 대응이 요구되지는 않는다.

종합 위험도 : 중간(Medium Risk)

이 피처는 중간 수준의 위험도로, 테스트 우선순위가 높지만 결제 모듈보다는 낮다.

[피처 3] 색상 테마 변경 기능

• 발생 가능성 :  낮음
  단순한 UI 기능으로, 기술적 복잡성도 낮고 사용 빈도가 낮다.
• 심각성 : 낮음
  장애가 발생해도 사용자에게 미치는 영향이 거의 없다.  
• 긴급성 : 낮음
  장애 발생 시 수정이 필요하지만, 즉각적인 대응은 필요하지 않다.

종합 위험도 : 낮음(Low Risk)

이 피처는 위험도가 낮아 테스트 우선순위가 가장 낮다. 다른 중요 피처의 테스트가 완료된 후 처리해도 무방하다.

위와 같은 위험도 산정을 통해, 각 피처의 우선순위를 명확히 하여 효과적인 테스트 계획을 수립할 수 있다.