실용적인 심각도 선정 가이드

2010.03.11 13:51QA

 

최근 필자가 재직하고 있는 품질관리 팀 내에서 심각도(Severity)에 대한 기준을 다시 정리하는 작업을 진행했다. 국내에서 테스트 엔지니어들이 그들의 현업에서 바로 적용할 수 있을 정도의 심각도에 관한 기준이 세세하게 기록된 문서를 가지고 있는 회사가 과연 얼마나 많을지 의문이다. 아무리 테스트 업무를 오랫동안 진행한 부서라고 하더라도 결함의 심각도를 판단하는 유일한 기준이 오직 개별 테스트 엔지니어의 경험과 주관뿐인 경우가 허다한 것이 현실이다. 상황이 이러하다 보니 당연히 심각도 선정에 대한 객관성이 보장되지 않았고, 이로 인해 개발자와 테스트 엔지니어 사이에 결함의 심각도에 대한 의견 차이가 빈번하게 발생했을 뿐만 아니라, 테스트 팀 내에서도 동일한 결함에 대해 서로 다른 의견이 제시되고는 했다.

 

이런 문제들을 조금이라도 줄여보고자 심각도 선정에 대한 기준을 마련하는 작업을 진행하게 된 것인데, 생각보다 그 과정이 쉽지 않았다. 최근 이와 관련된 일들을 진행하면서 필자가 경험하고 느낀 심각도 설정에 팁이 될만한 몇 가지를 추려 공유하고자 한다. 일반적으로 흔히 통용되는 심각도의 기준은 다음과 같다.

1. 치명적 결함(Critical Defects): 하드웨어 또는 소프트웨어 장애, 시스템 중지, 시스템 잠김(접근 불가),
                                        
데이터 손실   또는 변조

2. 주요 결함(Major Defects): 기능 상실, 잘못된 기능, 주요 기능 오작동

3. 일반 결함(Average Defects): 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스

4. 사소한 결함(Minor Defects): 타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스

5. 개선 사항(Enhancement): 에러는 아니지만 개선이 필요한 사항

 

                                                                   <출처: 개발자도 알아야 할 소프트웨어 테스팅 실무 제2>


흔히 심각도의 수준을 위와 같은 3 ~ 5단계로 설정하는 것이 일반적이다. 상황에 따라 더욱 많은 단계를 설정할 수도 있겠지만, 개인적인 경험으로 볼 때 최소한 3단계의 수준이라면 충분히 통용될 수 있으리라 생각된다. 중요한 것은 심각도를 몇 단계로 설정하느냐가 아니라, 발견된 결함에 대해 얼마나 객관적인 심각도를 부여할 수 있느냐 하는 것이다. 위에서 제시된 것과 같은 범용적인 기준만 가지고는 명확하게 이 결함이 어느 정도의 심각도를 가지고 있는지 판단하기 모호한 경우가 무척 많다. 이런 경우, 아래의 사항들을 참조한다면 좀 더 객관적인 심각도 선정에 도움이 될 것이라 생각된다.

 

■ 테스트의 목적을 고려하라

동일한 텍스트 오류라고 하더라도 단순히 텍스트 오류를 검증하는 목적의 테스트 중에 발견되었느냐, 아니면 기능 테스트를 수행하다가 발견된 부수적인 결함이냐에 따라 그 심각도가 달라질 수 있다. 단순히 사용자에게 메시지 전달이 충실히 되느냐를 검증하는 목적의 테스트라면, 다른 테스트에서는 사소한 문제로 간주될 수 있는 텍스트 오류도 심각한 문제가 될 수 있다. 이처럼 동일한 증상의 결함이라고 하더라도 테스트의 목적과 얼마나 깊은 관계를 가지고 있느냐에 따라 상대적인 심각도가 달라질 수 있다. 

 

■ 노출 빈도를 고려하지 마라

결함이 얼마나 자주 재현되느냐, 즉 결함의 노출 빈도는 심각도와 동등한 위상을 가지는 결함의 또 다른 속성이라고 할 수 있다. 일반적으로 노출 빈도는 결함의 우선순위(Priority)와 더 깊은 관련을 가진다(절대적인 관계가 있는 것은 아니다). 심각도가 높으면서 사용자에게 적게 노출되는 문제도 있으며, 심각도가 낮지만 사용자가 쉽게 찾아낼 수 있는 결함도 존재한다. 또한 노출 빈도가 높다고 해서 그것이 바로 심각도가 높은 문제라고 판단할 수 있는 것은 아니며, 노출 빈도가 낮다고 해서 심각하지 않은 문제라고 규정하는 것은 섣부른 판단이다. 노출 빈도와 심각도의 정도가 정비례하는 절대적인 규칙은 존재하지 않는다. 이 두 개념은 서로 관련이 없는 별개의 속성으로 판단해야 한다.

객관적인 심각도 부여를 위해서는 결함의 재현과정 보다는 결함의 증상에 집중해야 한다. 재현이 잘 되지 않는다고 해서 결함의 심각도를 낮춰서는 안 된다. 수정하는 우선순위를 미루더라도 결함 자체의 심각도는 영향을 받아서는 안 된다.  

 

■ 사용자에 집중하라

심각도 판단의 기준을 제품을 사용할 사용자에 두느냐, 아니면 제품 자체(테스트의 대상)에 두느냐에 따라 동일한 증상이라도 심각도가 달라질 수 있다. 제품에서 나타나는 단순한 기능 상의 오류라고 하더라도 사용자에게는 심각한 영향을 끼칠 수 있는 것이다. 예를 들어, 아이템을 구매한 내용을 계산해 아라비아 숫자로 총액을 표시하는 기능을 테스트한다고 가정해 보자. 계산된 값이 출력되는 창에는 디폴트로 “0”이라는 값이 기록되어 있다고 가정하자. 구매 내역을 계산하는 기능은 정상적으로 동작하나 기본 출력값인 ‘0’이 사라지지 않아 계산된 금액에 ‘0’이 하나 더 붙는 오류가 발생했다고 할 경우, 이를 기능 자체의 관점에서 본다면 기능은 정상적으로 작동하고 출력값의 표시와 관련된 문제라 심각도가 낮아질 수 있는 문제다. 하지만 사용자의 관점에서 본다면 이는 정당하게 지불해야 할 금액의 10배를 지불해야 하는 문제가 되므로, 치명적인 문제로 간주되어야 한다.

 

■ 회피 수단이 존재하는지 살펴보라

사용자가 어떤 목적을 달성하려는 도중에 발생한 결함이라면 결함이 발생하는 시점에서 사용자의 목적을 달성시킬 수 있는 우회 경로나 결함을 회피할 수 있는 방법이 존재하는지 여부를 살펴보아야 한다. 해당 결함으로 인해 사용자가 자신의 목적을 정상적으로 달성할 수 있는 방법이 사라지게 된다면 이는 심각한 결함으로 간주되어야 한다. 반면에 해당 결함으로 인해 목적을 달성할 수 있는 방법이 비록 제한되기는 하지만 결함에 영향을 받지 않는 정상적인 다른 방법으로 달성할 수 있다면 이는 전자보다는 상대적으로 심각도가 가볍다고 할 수 있을 것이다.

애플리케이션을 종료하려는 사용자에게 메인 메뉴 상에서 등장하는 프로그램 종료 버튼이 작동하지 않는 결함이 발생했다고 가정해 보자. 이 경우 메인 메뉴를 제외한 기타 옵션에서 프로그램을 종료하는 옵션을 제공한다면, 프로그램을 종료하는 경우가 메인 메뉴 상의 종료 버튼을 통해서만 가능한 경우보다는 상대적으로 가벼운 심각도를 가진 결함으로 판단할 수 있을 것이다.

 

■ 얼마나 많은 사람이 당신의 심각도에 동의할 지 생각해보라

앞서 살펴본 바와 같이, 기준을 무엇으로 삼느냐에 따라 동일한 이슈에 대해서도 심각도는 여러 가지로 달라질 수 밖에 없다. 프로젝트의 모든 이해당사자들이 동의할 수 있는 심각도가 부여된다면 가장 이상적이겠지만, 현실적으로는 개발팀과 테스트 팀간의 합의 조차 힘든 경우도 부지기수다. 개발팀과 테스트 팀이 합의하더라도, 동일한 이슈에 대해 사업 혹은 영업 관련 부서가 판단한 심각도는 또 다를 수 있다.

사용자의 입장을 대변하는 테스트 엔지니어가 제안하는 심각도가 가장 객관적인 심각도로 판명되어야만 한다. 프로젝트와 관련된 이해당사자들이 가장 존중해야 할 기준은 제품을 구매하고 직접 사용할 사용자가 될 수 밖에 없다. 테스트 엔지니어 역시 개인의 감성적인 판단이나 경험에 의존하는 것이 아니라, 해당 결함이 실제 사용자에게 어떤 영향을 끼칠 수 있을지를 객관적으로 판단하고 적합한 심각도를 부여해야만 많은 사람들이 당신이 부여한 심각도에 동의할 것이다.  

 

원주율 값은 소수점 이하 무한대로 확장될 수 있지만 일반적으로 소수점 2자리 이하의 값들을 버린 3.14 라는 값이 널리 통용된다. 이와 같이 심각도를 선정하는 작업에서도 고려해야 할 수많은 사항들을 얼마나 깊이 고려할 것인가라는 문제도 무척 중요하다. 이를테면, 엔드 유저 대상의 소프트웨어에서 발생한 결함이 사용자에게 어떤 영향을 끼칠 것인가를 고려할 때, 가상의 사용자를 연령별 혹은 직업별로 분류해 각각의 사용자에게 끼칠 영향을 별도로 설정한다던가 하는 것은 경우에 따라 투자한 노력 대비 얻을 수 있는 효과가 미미할 수도 있다. , 배보다 배꼽이 더 큰 작업이 될 수 있는 것이다. 의료나 군사 분야와 같이 안전(Safety)이 가장 우선시 되는 분야가 아닌 이상, 가장 일반적인 사용자를 가정하되, 일반적인사용자가 어떤 사람인가를 분석하는 것도 어느 정도의 리소스를 어떻게 투입해서 진행할지를 고민해 보아야 한다.

 

심각도를 선정하는 기준은 앞서 제시된 기준들 뿐만 아니라 훨씬 더 다양한 기준이 제시될 수 있다. 우선순위나 결함의 원인, 그리고 해당 결함을 개선하는 데 필요한 시간 및 인력 등을 파악하고 이 요소들을 심각도와 함께 관리한다면 결함을 통한 품질평가라는 측면에서 좀 더 의미있는 지표가 될 수 있을 것이다. 

 

심각도를 판단하는 절대적인 기준은 있을 수 없다. 때에 따라서는 앞서 제시한 기준들이 서로 모순되게 나타날 수도 있고, 제시되지 않은 기준이 더 중요하게 작용할 수도 있다. 결함의 심각도를 판단하는 데 있어 무엇보다 중요한 것은 발견된 결함을 객관적으로 판단하되 사용자의 입장을 충분히 반영할 수 있어야 한다는 것이다. 결함의 심각도를 판단할 때 사용자의 편을 들어줄 수 있는 사람은 오직 테스트 엔지니어 뿐이라는 사실을 잊지 말아야 한다.

'QA' 카테고리의 다른 글

생활 속의 QA - Early Testing  (4) 2010.04.20
Cloud QA  (0) 2010.03.22
실용적인 심각도 선정 가이드  (2) 2010.03.11
게임 QA를 꿈꾸는 분들에게  (81) 2010.02.19
소프트웨어 테스팅의 종류  (0) 2010.02.08
QA, QC 그리고 테스트 엔지니어링의 차이  (9) 2010.02.05
  • 프로필사진
    BlogIcon 크로노72011.01.05 21:33 신고

    요즘 신규 제품 개발에 따라 테스트를 진행해야 하는데 심각도(중요도), 우선순위를 정의하고 있는데 위 내용들이 도움이 될것 같습니다. '사용자 입장에서 객관적으로 판단하기' 노력해 봐야겠네요.^^

    • 프로필사진
      BlogIcon 검은왕자2011.01.06 12:47 신고

      도움이 되어야 할텐데요... ^^
      사용자 입장에서 판단한다는 것이 참 말은 쉬운데, QA나 개발자 모두에게 어려운 일인것 같아요.
      감사합니다. ^^