간단한QC(Quality Control)지표...

지금 내가 있는 조직에서 테스터를 할당하는 방식은... 감(感)과 경험이라고 하는데, 결국은 이해관계자의 목소리가 큰 서비스의 경우에는 많이 투입하고 그렇지 못한 부분은 적게 투입하고 있는 현실이다.

이런 주먹구구식의 투입을 개선하려고 생각하던 찰나,  다음과 같은 지표가 떠 올라 적어보았다.

지표의 이름 : 1개월동안 개발자1명이 개발한 것을 동일 기간 테스터 1명이 테스트시 발견되는 버그 수...  

먼저 투입된 개발비용 대비 발생한 버그를 보면 

버그는 각 조직에서 사용하는 레벨이 있다면 레벨별로 가중치를 두도록 한다. 우리 조직의 버그는 Critical, Major, Minor로 분류 되고 있으며 각각의 가중치는 다음과 같다.

NumOfBug = Critical×1.4 + Major×1.2 + Minor×1.0

해당 프로젝트에 투입된 테스터의 공수 단위로 이를 계산하면 위에서 언급한 지표가 나온다. 

여기에서 Testing Cost는 투입된 테스터를 MM으로 계산한 것이며 투입된 테스터별로 레벨이 있다면 가중치를 둘 수도 있다. (여기에서는 두지 않았다.)

이 지표의 결과는 결코 개발조직의 우열을 가리는 지표가 아니다. 이 지표는 개발자의 레벨, 개발환경의 복잡성등 여러가지 변수들의 영향을 받기 때문이다.

하지만 QC의 입장에서 관찰해야 할 것은 이 지표의 변화이다.

동일한 개발팀에서 지속적으로 개발 프로젝트를 진행한다고 할 때, 매 테스팅시 마다 이 지표를 관찰해 보자.

1. 완만하게 하강하는 모습 : 정상적으로 개선이 되는 것으로 판단
2. 급격한 하강 : 개선이 아닌, 개발 환경의 단순화나 개발인력의 레벨 업, 또는 투입 Tester리소스의 과다로 볼 수 있음. 이런 경우 과거의 경우를 고려하면서 Testing리소스를 줄여 남은 리소스를 다른 곳으로 전용 가능.
3. 상승하는 모습 : 점점 악화되는 모습이다. 이의 경우는 개발환경의 변화, 개발인력의 변화, 또는 Tester리소스의 감소로 인해 발생할 수 있다. 
4. 수평(과거와 거의 동일) : 개선은 아니지만 현재 개발대비 Testing투입 리소스는 적정한 것으로 판단.

3의 경우 개발팀에서는 개발환경에 대한 개선을 고려해 볼 수 있으며 테스팅 팀에서는 향후 이 프로젝트에 Testing리소스를 추가투입함으로서 역시 이 지표를 과거 수준으로 낮추는 노력을 해야 한다.