테스트 케이스의 우선순위 결정 방법

TC를 작성하고 발생한 결함에 대해 처리 우선순위를 결정하는건 상당히 중요하다. 서비스의 가용성에 크리티컬한 결함일 수록 아닌 결함보다 빠르게 대처해야 비즈니스의 목적인 수익성에 타격이 없을 것이기 때문이다. 

고객들은 생각보다 까다롭다. 서비스를 이용하다 불편을 겪으면 '이거 왜이래?', '다른 서비스 쓸까?'라는 생각을 할 것이다. 나도 그렇기 때문에 ㅎㅎ..;;

 

그 중요한 우선순위를 결정하는 방법에는 2가지 기준이 있다고 한다.

위험도 기반

우선 위험도의 정의는 아래와 같다.

[risk = likelyhood(발생 가능성) * impact(발생 시 심각도)]

 

그리고 위험도의 구성인 발생 가능성과 발생 시 심각도의 정의는 아래와 같다.

발생 가능성 - 소스 코드의 복잡도, 구현 난이도, 테스트 대상 기능의 구현 크기(소스 코드 라인 수), 해당 모듈을 개발한 개발자의 수준 등의 기술적인 내용 발생 시 심각도 - 이 기능에 장애가 발생하였을 때, 비즈니스적으로 끼치는 타격

 

이놈들을 모두 고려해서 우선순위를 결정한다.

STA(Servere Teast Area) : 발생 가능성도 크고, 타격도 큰

SSTA(Strong Test Area) : 발생 가능성은 작지만 타격이 큰

ITA(Intensive Test Area) : 발생 가능성은 크지만 타격이 작은

FTA(Fundarmental Test Area) : 발생 가능성도 작고, 타격도 작은

 

발생 가능성이 큰 경우는 대부분 기술적인 요인에서 발생한다. 때문에 단위 테스트나 통합 테스트 같은 기술적인 레벨(로우) 테스트 단계에서 커버해야 한다.

기술 테스트, 통합 테스트 우선 순위 : STA → ITA → SSTA → FTA 

 

비즈니스에 영향이 큰 결함에 대해서는 하이 레벨 테스트 단계인 시스템 테스트와 인수 테스트 단계에서 진행하는게 좋다.

시스템 테스트, 인수 테스트 우선 순위 : STA → SSTA → ITA → FTA

 

복잡도 기반

코드의 복잡도가 높을수록 결함의 발생 가능성이 올라간다. 코드의 복잡도를 측정하는 방법 중 순환 복잡도 측정이라는 방법이 있는데, 이 수환 복잡도는 [분기 조건의 수 + 1]의 식으로 계산된다.

즉 if, while, switch, or 연산이나 분기문이 많으면 코드가 복잡하다고 생각하면 된다.