결함 추적 시스템은 정말 불필요한 것인가?

'린 소프트웨어 개발의 적용'에 결함 추적 시스템은 불필요하다라는 논지의 이야기가 있다.

과연 정말로 그런 것일까?

나에게 있어서 이런 논지는 옛날 어떤 테스터가 나에게 결함보고서는 왜 써야 하느냐며 목에 핏대를 세우던 기억을 떠올리게 한다.

정말로 그런 것인지 낱낱이 파헤쳐 보자.. 퐉퐉..

'린 소프트웨어 개발의 적용'에 적힌 논리는 다음과 같다.

개발할 때부터 결함이 생기지 않도록 노력한다면 결함은 적은수만 발생할 것이고(실제로 그렇다라고 적고 있다.) 결함이 적게 발생한다면 굳이 결함을 결함 추적 시스템에 적고 유지보수하고자 하는 노력은 낭비이다..

라는 것이다.

린에서는 낭비는 무조건 제거해야할 대상이기 때문에 위와 같은 논리라면 결함 추적 시스템은 분명 없어져야 할 시스템이다.

난 다시 한번 해당 챕터를 찬찬히 다시 읽어보고 또 읽어 보았다.

그리고 내린 결론은 일견 타당해 보이지만 이건 너무 편협한 의견이다라는 것이 내 결론이다.

아래 그림은 왜 결함 추적 시스템이 낭비인가에 대한 논리이다.

그리고 아래 그림은 왜 결함 추적 시스템이 불필요한가에 대한 논리이다.

일견 이 논리에는 별반 문제가 없어보이지만 내가 이 논리를 편협하다고 하는 것은 아래 2가지이다.

1. 이 책에서는 결함 추적 시스템을 단순히 개발자와 테스터간의 커뮤니케이션 도구 이상으로 생각하지 않는 다는 것이다. 물론 결함 추적 시스템의 가장 큰 역할 중의 하나는 커뮤니케이션이다.

하지만 우리가 잘 사용하지 않는 결함 추적 시스템의 또 다른 역할은 개선을 위한 데이터 추출 도구라는 것이다.

발견된 결함과 결함을 해결하기 위해 수행되었던 활동에 대한 기록은 결함 추적 시스템에 고스란히 남게 된다.

이러한 기록은 이후에 유사한 결함이 발견되거나 새로운 개발자 또는 테스터에게 매우 유용한 정보이다.

조직이 작거나 개발중인 제품이 작다면 '린 소프트웨어 개발의 적용'에서 말하는 논리는 맞을 수 있다. 하지만 우리는 하나의 제품에 수많은 팀들이 얽혀 있는 크로스 조직이나 글로벌 조직에서 일하는 경우도 많다.

수많은 조직에서 유사한 결함이나 동일한 결함이 공유되지 못하고 각자 해결된다면 종속성, 통합성의 의미에서 이것이 더 큰 낭비가 되지 않을까? 싶다.

그리고 결함 추적시스템이 왜 낭비인가? 하는 논리에서 가장 중요한 것은 테스터가 결함 추적시스템에 결함을 등록하고 그러한 결함이 대기상태로 낭비되는 주된 원인은 개발자가 실시간으로 결함을 해결해주지 않기 때문이다.

이것은 '린 소프트웨어 개발의 적용'에서 결함 시스템이 왜 불필요한가? 에 대한 해결책이다.

즉, 결함 추적 시스템이 있고 없고가 문제가 아니라 개발자가 결함을 왜 실시간으로 해결해주지 못하는가에 대한 문제이다.

두번째는 테스팅의 범위를 단위 테스팅과 개발자의 입장에 너무 국한되어서 생각하고 있다는 것이다.

테스팅은 단위 테스팅이나 인수 테스팅만 있는 것은 아니다. 테스팅은 개발 프로세스 전반에 걸쳐 매우 다양한 유형으로 수행된다. 그 중에는 개발자가 관여하지 않는 테스팅도 무척이나 많다. 물론 결함으로 판명된다면 수정하기 위해 개발자가 관여해야하는 것은 사실이지만 수행 자체에 개발자가 관여하지 않는 경우도 많다.

그러한 비중은 시스템이나 인수테스트와 관련된 유형의 테스트에 더욱더 많다. 그러한 경우 커뮤니케이션을 위해서라면 결함 추적 시스템을 필수 불가결하다고 생각한다.

수행에 참여하지 못한 개발자가 해당 결함을 해결하기 위해서는 테스터와 1:1로 커뮤니케이션을 하면서 수정할 수도 있지만 현실에서 그런 경우는 그렇게 많지 않다. 그런 경우 개발자가 결함에 대한 정보를 얻을 수 있는 통로는 결함 추적 시스템 뿐이다.

'린 소프트웨어 개발의 적용'에서는 결함은 발견되는 즉시 해결되어야 한다고 한다. 개발자와 테스터가 1:1이라면 가능한 얘기이다. 하지만 실제 우리의 작업환경이 그러할까? 그리고 개발자 1명 테스터 1명이 개발하는 경우라면 가능할 수도 있다. 하지만 아무리 작은 조직이라고 해도 최소한 개발자 3명 이상에 테스터는 2명이상이라고 한다면 그 사이의 커뮤니케이션은 매우 복잡해진다.

그리고 단위 테스팅과 같은 단계라면 결함이 발견되는 즉시 해결 가능하다고 할 수 있지만 개발이 진행될 수록 제품은 더욱더 복잡해지고 시스템이나 인수 테스팅 단계에서의 결함은 매우 복잡해지는 양상을 가진다.

이러한 결함은 발견 즉시 해결하는 것이 쉽지 않을 수 있다. 많은 수의 개발자가 협력해야할 수도 있다.

그러한 상황에서 가장 기본적인 데이터를 제공해 줄 수 있는 것은 결함 추적 시스템뿐이라고 해도 과언이 아니다.

나는 결함 추적 시스템 자체가 낭비라기 보다는 결함 추적 시스템에 입력하고자 하는 행동이 낭비라고 본다.

우리가 결함 추적 시스템을 기피하는 가장 큰 이유중의 하나는 입력해야할 값들이 너무 많다는 것이다.

결론적으로 결함 추적 시스템은 낭비가 될 수 없다. 만약 결함 추적 시스템이 낭비로 판단이 된다면 그것은 입력을 위한 값들이 너무 많기 때문일 것이다. 꼭 필요한 사항만을 입력할 수 있도록 개선해야한다고 생각한다.

그리고 개발 조직이 테스터가 발견한 결함을 즉시로 해결할 수 있도록 시스템과 규칙을 바꾸도록 개선한다면 결함 추적 시스템이 낭비가 되는 일은 없을 것이라고 생각한다.