저 유명한 Testing Embedded Software에서 Hans Schaefer가 발표했다고 하면서 아래의 가이드를 제시했다.
결함이 자주 발견되는 지역은 다음과 같다.
복잡한 컴포넌트
완전히 새롭게 작성된 컴포넌트
자주 변경되는 컴포넌트
어떤 툴이나 기법이 최초로 적용되는 컴포넌트
개발 도중에 개발자가 변경된 컴포넌트
극심한 시간적인 압박하에서 작성된 컴포넌트
일반적인 경우보다 더 빈번하게 최적화가 되어야 하는 컴포넌트
이전에 많은 결함이 발견된 컴포넌트 (예를 들면, 이전 릴리즈나 이전 리뷰에서)
수많은 인터페이스를 가진 컴포넌트
또 실패의 확률은 아래의 경우 더 커진다.
경험이 부족한 개발자
유저의 입장을 대변하는 인력의 불충분한 참여
개발 과정에서 품질 보증 활동이 미흡한 경우
저수준 테스트의 품질이 미흡한 경우
새로운 개발 툴과 개발 환경을 도입한 경우
개발팀의 규모가 거대한 경우
개발팀간 또는 개발팀 내부의 의사 소통이 원할하지 않은 경우 (예를 들면, 지리적으로 상이한 곳에 있거나 개인적인 감정으로 인해)
조직 내부에서 해결되지 않은 갈등을 가진 정치적인 압력하에서 개발된 컴포넌트
쥔장이 보기엔 각자들 상황은 다르지만 다들 이런 경험들이 있을 것이다. 만일 본인이 테스트를 해야하는 모듈이나 컴포넌트가 이러한 상황과 부합한다면 극도로 주의해야 할 것이다! 하지만, 반대로 생각해 보면 그런 컴포넌트라는걸 알고 있다면 오히려 찾아낼 것이 많기 때문에 좋은 것은 아닐지? ^^
댓글 영역