버그 심각도와 중요도의 개념과 일반적 조합

QA 부서와 그가 생산한 리포트를 받고 최종 결과 리포트의 의미를 전달 받는 사람들 간에 용어의 정의부터 달라 혼선을 겪는 경우가 많다. 따라서, 버그의 성질을 표시하는 중요 속성에 대해서 정의하고 판단 기준으로 삼는 것이 바람직하다.

버그(결점) 심각도는 버그의 심각성을 결정하는데 반해, 버그 중요도는 버그 긴급성 또는 수정의 촉박함을 결정한다. 영문으로는 Severity / Priority로 표기하며, 심각도는 단순히 심각한 정도(시스템이나 기능에 미치는 영향)만을 나타내며, 중요도는 심각도와 상관없이 단순히 수정의 시급성 및 그 버그의 최종적인 영향력 및 파괴력만을 의미하며 여기서 파생된 개념이 수정 작업의 실행 및 반영시기의 정도이다 . 이 두가지를 혼동하여 사용하고, 심한 경우 구별없이 버그를 취급한다면 재앙을 불러올 수 있다. (^^)

이러한 두 가지의 개념의 다양한 조합이 가능한데(단순한 분류를 위해서 두 개념의 가능한 레벨은 높음, 낮음의 단 두 개만 존재한다고 가정하면)

1. 높은 심각도와 낮은 중요도: 어떤 계산을 통해 주단위, 월단위, 분기별, 연도별로 은행 계좌 관련 리포트를 생성하는 어플리케이션이 있다고 가정할 때, 이 어플리케이션에서 연도별 리포트를 계산하는 기능에 버그가 있는 경우, 이 버그는 변경 요청에 의해 다음번 릴리즈에 수정될 수 있기 때문에, 높은 심각도를 가지지만 낮은 중요도를 가진다.
2. 낮은 심각도와 높은 중요도: BT.com 웹사이트에 철자 오류나 내용에 문제가 있는 경우를 가정하면, 이것은 지속적으로 노출되며, 빈도가 높을 수 있으므로, 이 버그는 웹사이트나 기능에 영향을 주는 것이 아니라 하더라도, 경쟁적인 시장 상황하에서는 웹사이트의 상태나 인기도를 고려해서 높은 중요도를 가진다.
3. 높은 심각도와 높은 중요도: 어떤 계산을 통해 주단위, 월단위, 분기별, 년도별로 은행 계좌 관련 리포트를 생성하는 어플리케이션이 있다고 가정하고,이 어플리케이션에서 주단위 리포트를 계산하는 기능에 문제가 있다면, 이 버그는 한 주 내에 어플리케이션의 기능에 장애를 유발하는 것이므로 높은 심각도와 높은 중요도를 가지며, 즉시적으로 수정되어야 한다.
4. 낮은 심각도와 낮은 중요도: 웹 페이지에 철자 오류가 있으며, 한달 간의 히트수가 아주 적은 경우라면, 이 버그는 낮은 심각도와 낮은 중요도를 가진다.

또한, 이러한 속성이외에 '재현 빈도'(reproduce)가 있을 수 있는데, 이것은 버그가 발견은 되었으나 다시 재현되는 정도가 어떠한지에 대한 분류이다. 위의 두 가지 (심각도와 중요도)와 이것이 결합되면 또 다른 조합을 만들어 낼 수 있는데 그것들은 다음과 같다. (낮은 심각도에 대한 얘기는 하지 않는다.)

1. 높은 심각도와 높은 재현 빈도의 결함: 일단, 중요도를 배제한 상태에서 이것은 긴급한 수정으로 간주되는 것이 바람직하며 따라서, 중요도 또한 높아질 수 있다. (초기에 할당된 중요도가 변경될 가능성 있음) 부연 설명을 하면, 이 상황이 유저에게 노출이 잘 되는 것이면 즉시 수정을 요하겠지만, 거의 생각할 수 없는 어려운 스텝으로 재현되거나 일반적인 사용에서 벗어난 경우에는 중요도는 또 낮아질 수 있다. 또한, 재현 빈도가 100%인 경우에는 수정의 용이함 때문에 수정을 결정하는 경우도 많다.
2. 높은 심각도와 낮은 재현 빈도의 결함: 이런 경우 뒤의 중요도에 따라 달라진다. 하지만, 재현 빈도가 낮은 경우 중요도가 높게 부여될 확률은 많지 않다. 대부분의 프로젝트의 경우 수정할 이슈가 차고 넘치기 때문이다.

중요한 것은 이러한 개념을 이해하고 적어도 QA팀 내에서는 동일 이슈를 가지고 다른 등급으로 판단하는 사례가 있어서는 안 되며, 나아가서 다른 협업 부서에서도 이러한 개념으로 해당 버그를 이해하는 것이 중요하다 하겠다.

이러한 분류는 획일적이지 않으며, 제품의 특성, 산업 분야 등에 따라서 중요시 하는 덕목(?)이 다르므로 산업별 표준 분류나 정의가 필요할 것도 같다.