테스트 팀/인력에 대한 정량적 평가에 대한 개인 생각

테스트 팀 혹은 개별 인력에 대한 정량적 평가를 위해선 일단 기본 척도가 될 수 있는 품질에 대해 어떻게 측정할 수 있을지를 먼저 정의하는 것이 맞을 것 같다.

품질 그리고 결함

제조업의 경우, 개별 제품 혹은 전체 제품 대비 테스트 대상이 되는 제품 중, 결함 제품의 비율등을 통해 결함율을 측정할 수 있을 것이다. 이와 유사하게 소프트웨어의 경우에는 전체 기능에 대비 결함율을 측정해볼 수 있을 것이다. 다만 단순히 개수만을 측정하는 것이 아닌 결함의 심각도에 따라 결함을 분류하고 각 심각도에 가중치를 주어서 전체 점수 혹은 측정 값을 산출 할 수 있을 것으로 보인다.

위의 방법은 정말 간단하고 단순한 방법이다. 단순히 결함으로만 품질을 측정한다는 것은 부족할 수 있기 때문이다. 그럼 다른 요소들은 무엇이 있을까? 결함이외에 단일 혹은 전체 테스트 케이스의 기능 커버리지, 자동화로 절약한 비용, 사용자 만족도, 특정 릴리스 후의 사용자 유입(트래픽) 증감 혹은 이용자의 증가 및 주문 및 결제와 같은 의미 있는 트랜잭션의 증가등등이 있을 수 있겠으나, 이는 서비스의 도메인에 따라 차이가 존재할 수 있고, 따라서 각 서비스에 맞게 결함외의 어떤 것을 품질 측정에 사용을 할 것인지에 대해 논의 및 협의가 필요할 것으로 보인다.

그렇지만 결함으로 인해 발생할 수 있는 부정적 영향이 다양할 수 있고, 만약 릴리즈 이후에 심각한 결함이 발생한다면 이는 비용으로 산정하는 것이 매우 어려울 수 있다. 그 이유는 몇명의 사용자게에 부정적 사용 경험을 주었는지, 각 사용자마다 체감하는 서비스에 대한 신뢰도 하락등은 정확한 측정 자체가 어려울 것으로 보이기 때문이다. 다만 알 수 있는 점은 릴리즈 전과 후에 발생하는 결함의 비용은 아주 큰 차이가 있다는 것이다. 따라서 결함의 심각도에 따른 분류와 함께 릴리즈 전 혹은 후에 발견되었는지 여부까지 고려하여 결함들을 분류하는 것이 필요해 보인다.

정량적 가능 후보들

위에서 살펴본 것과 같이 심각도와 릴리즈 전/후에 따른 결함 내역, 테스트 케이스의 커버리지 그리고 테스트 자동화로 절약한 비용(반복적인 테스트 작업에 대한 리소스 비용)등이 있을 것으로 보이는데, 사용자 만족도등과 같은 항목은 정성적인 측면이 지배적이라 제외하는 것이 나을 것으로 보인다.

정량적 후보 지표로 평가의 가능 여부

그럼 위와 같은 정량적 후부 지표들로 팀 혹은 개개인에 대한 평가가 가능할 것인가?를 살펴봐야하겠으나, 먼저 이런 정량적 지표들로 살펴보고 개선의 항목들을 도출하는 것이 개개인의 평가를 위한 것인지 아니면 서비스의 품질을 측정하기 위한 것인지 살펴봐야할 것으로 보인다. 테스트 팀 혹은 개개인의 평가 수단에 정량적 방법 혹은 지표가 필요하다라는 의견이 종종 보이는 것에 대한 나의 생각은 인사 평가와 깊은 상관성이 있고, 인사 평가를 위해 활용이 가능해보이기 때문이라고 생각한다. 다만 중요한 점은 서비스의 품질에 대한 측정이 우선이고 이를 위해 이런 정량적 지표의 측정 및 산출이 먼저 되어야 한다는 것이다. 인사 평가의 수단으로 사용을 할 것인지 아닌지 여부는 개개인의 판단에 따라야 하지 않을까?

또한 정략적 지표 혹은 후보들의 측정 및 산출을 위해선 시스템적인 접근 및 자동화가 필수라고 보여진다. 시스템의 구축 및 자동화 구성을 위해선 생각보다 많은 비용이 필요할 수 있다. 만약 인사 평가를 위해 이런 비용을 감수한다? 그 보다는 서비스의 품질 측정을 그리고 개선을 위해 투자를 하는 것이 나을 것으로 보인다. :)

즉, 정량적 지표의 정의 및 산출 그리고 측정을 위한 시스템의 구성은 개개인의 인사평가를 위해서가 아닌 서비스의 품질 및 개선을 위해 필요한 것이고, 인사 평가에 활용을 할 것인지는 개개인의 선택 혹은 부차적인 문제이지않을까 하는 생각이다.

그럼 어떻게 평가할 것인가?

먼저 테스트 팀 혹은 개인을 구분하는 이유가 무엇인지 알고 싶다. 물론 개개인의 인사 평가를 위해 이런 구분이 필요하겠으나, 어차피 인사 평가라는 것인 개개인에 대한 평가가 아닌가?

차라리 서비스 혹은 프로젝트 단위로 전체 팀 구성 단위로 평가를 하는 것이 낫지 않을까 하는 생각이며, 서비스의 개발 비용, 납기 준수 및 결함율(¹.) 전체적으로 측정 및 평가하여 서비스 혹은 프로젝트 단위로 점수(?)를 부여하는 것이 나은 방법이지 않을까 한다.

참고 사항

결함율

참고로 결함율이 높아진다고 해서 테스트 팀 혹은 개인의 문제는 아니라고 생각한다. 결함은 앞에서 말한 것과 같이 릴리즈 전, 즉 구상 및 기획, 디자인, 구현 및 테스트의 각 단계에서 발견 및 제거할 수 있고, 앞선 단계에서 발견 및 제거 될 수록 결함의 비용은 급격하게 감소하기 때문이다.