리스크 기반 테스팅

소프트웨어 테스팅 7가지 기본 원칙에서도 나오듯 완벽한 테스팅은 불가능하다. 그렇다면 어떻게 해야 좀 더 효율적으로 결함을 발견할 수 있을까? 🤔 여러 가지 방법이 있겠지만 기본적으로 리스크기반 테스트를 주로 사용한다. 

---

🤷‍♂️ 리스크 기반 테스트?

• 테스트 대상에 비해서 테스트 자원이 부족한 경우, 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위한 테스트 전략이다.
• 비즈니스, 기술 상의 위험을 정량적으로 측정하여 우선 순위가 높은 부분에 주어진 테스팅 자원을 집중하여 전체적인 영향을 줄이기 위한 테스트 전략이다.
• 리스크란 “장애 발생 가능성” X “장애로 인한 영향” 으로 정의된다.
• 장애 발생 가능성이란, 복잡성, 새로운 개발의 정도, 상호관계, 소스 코드의 크기, 사용 기술의 난이도/최신성, 개발팀의 수준 등이 해당된다.

✔️ 리스크 기반 테스팅의 목적?

• 테스트 대상에 비해서 테스트 자원이 부족한 경우, 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위해

✔️리스크 기반 테스트 4단계

출처 : https://velog.io/@soyean

1. 리스크 식별 

• 발생 가능 위험의 카테고리화, 테스트 대상이 될 항목을 식별한다.
• 하나의 리스크 단위에는 되도록이면 35개 미만까지 선정하는게 좋다.

2. 리스크 분석

• 식별 위험의 우선순위 결정
• 리스크 요소를 결정한 후 이에 대한 타당성을 결정한다.
• 리스크 요소에 대한 타당성은 이해관계자와 함께 진행하게 되는데 개발자, 마케팅, 사용자 등이 포함된다.

 

 

3. 리스크 계획

• 리스크 매트릭스(Risk Matrix) 를 작성하여 리스크 아이템 별 요소를 표시합니다. 
• 리스크 정보를 근거로 대처방안을 수립하는, 즉 리스크를 줄이는 '테스트'를 생성
• 리스크 매트릭스의 STA에 해당하는 부분은 우선적으로 주어진 시간과 자원을 고려하여 공식적인 기법을 적용한 강력한 테스팅을 진행
• FTA에 해당하는 부분의 경우 자유롭게 시간이 허용하는 범위에서 테스팅을 진행

http://jidum.com/jidums/view.do?jidumId=579

4. 리스크 추적

• 테스트 계획 단계에서 계획한 테스트를 프로젝트 동안 준수하고 리스크가 최소화되고 있는지 이슈가 없는지에 대해 모니터링하고 제어하는 단계이다.
• 하위레벨 테스트 : 프로젝트 단위 테스트 또는 통합 테스트 레벨과 같이 기술적 측면을 중점으로 테스트하며, 강도를 조정하며 테스팅을 진행함
• 상위레벨 테스트 : 주로 제 3자 테스팅 또는 비즈니스 흐름을 검증하는 시스템 레벨 또는 인수 레벨 중점으로 테스트하며, 강도를 조정하며 테스팅을 진행함

---

❗️용어 정리

STA (Severe Test Area)	장애 발생 가능성과 장애로 인한 영향이 모두 높은 부분 자원이 허용되는 한 "반드시 강도 높게 테스트해야 하는" 영역
ITA(Biz) (Intensive Test Area(Biz))	장애 발생 가능성은 낮으나 장애로 인한 영향은 높은 부분 "출시가 가까워질수록 강력하게 테스트해야 할" 영역 장애 영향도 즉 사업적인 관점(Biz)에서 테스트해야 할 영역
ITA(Tech) (Intensive Test Area(Tech))	장애 발생 가능성은 높으나 장애로 인한 영향은 낮은 부분 "코딩 시기에 가까워질수록 강력하게 테스트해야 하는" 영역 장애 발생 가능성 즉 기술적인 관점(Tech)에서 테스트해야 할 영역
FTA (Fundamental Test Area)	두 가지 리스크 요소가 모두 낮은 부분 "상대적으로 강도를 낮춰 또는 간접적으로 테스트할 수 있는" 영역

 

 

📝Ref.Site

http://jidum.com/jidums/view.do?jidumId=579
https://tech.kakaoenterprise.com/104
https://velog.io/@soyean/%EB%A6%AC%EC%8A%A4%ED%81%AC-%EA%B8%B0%EB%B0%98-%ED%85%8C%EC%8A%A4%ED%8A%B8