프로젝트의 품질 요소 측정은 매우 중요하다.
이를 통해서 중요한 의사결정을 해야하기 때문이다.
이 글에서는 프로젝트 품질 요소를 어떤형태로 측정하는지 사례를 정리해보는 것이 목표!
잘 모르는 분야라 계속 업데이트 하려고 함.
Bug 분석을 위한 Raw 데이터들
- 심각도/우선순위 : Low, Minor, Major, Critical, Medium, High, Showstopper..
- 출처 : Developer, Development, Sprint Test, End to End Test, Regression Test, Customer..
- 생성/변경정보 : 버그 등록시간, 버그 담당자(부서) 변경 시간, 버그 담당자(부서) 변경 횟수, 버그 수정완료 시간, 수정완료 확인시간, 버그 재 오픈 시간, 버그 재오픈 횟수..
- 버그 구분(Type) : Feature, Performance, Memory leak, Enhancement...
- 버그 완료/해결(Resolution)구분 : Fixed, Duplicate, Invalid, Cannot Reproduce, wontfix, moved(moved to other area), ETC
- 버그 Owner : 버그 Owner정보, 버그 Owner의 부서
- OS 정보
- Target Version정보
분석사례 모음
사례 별로 어떤 데이터가 필요한지 데데이터를 어떻게 다루는지 정리
심각도에 따른 버그 Trend분석
- ex) High 이상의 버그 갯수를 주단위로 측정하여 확인
- 프로젝트 품질이 시간이 지남에 따라 변화하는 걸 측정할 수 있을 듯 하다.
- 버그가 꾸준이 증가하고 있다면 원인을 파악해야 한다.
버그 Owner 부서/Component별 버그 갯수 분석
- 특정 영역에 버그가 얼마나 모여 있는지 확인
- 특정 영역에 버그가 몰려있다며 원인을 파악하여 이를 줄여야 한다.
- 리소스 문제일 수도 있고, 개발 난이도 문제일 수도 있고 원인은 여러가지 일 것 같다.
버그가 처리 시간 분석(Trend분석)
- 버그 Open이후 Close될때 까지 얼마의 시간이 걸리는지 확인.
- 평균적으로 얼마의 시간이 걸리는지 확인하고, 프로젝트의 기준을 정할 필요가 있음
- X일을 기준으로 한 후 Trend에서 이를 계속 초과하는 방향으로 간다면 원인 파악이 필요함.
- 난이도 높은 버그를 처리할 수 있는 리소스가 부족한 걸 수 있다.
- 또는 버그를 분석하기 위한 Tool의 부재나, 노하우의 부족일 수 있다.(Memory leak/Perfomance Bug의 경우 상대적으로 Junior가 처리하기 어렵다.)
버그의 출처에 따른 분석
- Development보다 Customer의 버그가 상대적으로 많다면 충분한 테스트를 하지 않는 것으로 볼 수 있다.
- Regression Test를 통해서 많은 버그가 나온다면, 개발단계에서 충분한 테스트를 하지 않고 코드를 올리고 있다고 볼수 있거나. 회귀테스트가 정상동작한다고 볼수 있을것 같다(억측인가?)
버그가 재오픈 되는 횟수
- 재오픈 되는 버그가 많다는 것은 버그를 제대로 수정하지 않고 Close한다고 볼 수 있다.
- 버그가 재 오픈된다는 것은 버그가 open되고 분석/수정하는 과정을 다시 거치는 것으로 시간이 2배 이상 소요될 것이다.
버그 완료/해결 Type분석
- Fixed대비 다른 Type이 상대적으로 많을 경우 이를 적절하게 다루는 것이 중요하다.
- 만약 Duplicate버그가 많다면, 개발자 입장에서는 이를 확인하는 시간이 소요 될 것이다. 버그를 Open하는 시점에 이를 잘 파악하고 올린다면 리소스 낭비를 줄일 수 있을 것이다.
Target Version별 분석
- 특정 Target에 버그가 몰려 있다면 원인을 분석하여, 비슷한 사례가 발생하지 않도록 해야한다.
안녕하세요~ :)