'커다란 조직'은 알 수 없는 녀석이다.
큰 조직에서 테스트 주도 개발이나 단위 테스트같은 프랙티스를 도입하는 과정에는 (거의) 언제나 지원부서가 관련된다. 크면 클 수록 지원부서의 종류도 다양하다.
여기 어떤 부서(A)가 있다. 소위 테스트 활동을 하는 부서다. 독립 테스트, 정적 테스트, 블랙박스/화이트박스 테스트 등 테스트에 관한 전반적인 활동을 지원하고 있는 부서가 있다고 하자.
또 다른 부서(B)가 단위 테스트가 중요하다고 생각되어 일을 추진하고 싶다. 잘된건지 그렇지 않은건지, 분명 A부서는 아직 단위 테스트를 하고 있지는 않다. 그런데 '테스트'라는 이름이 좀 걸린다.
여기서부터 문제가 시작된다. A부서와 B부서는 어떻게 하는 것이 옳을까? 여러분의 조직에서라면 어떤 상황이 벌어질까?
현실에서는 대개 B부서가 직접 일을 추진한다. 새로운 명분을 만들어서라도 별다른 협력체계없이 추진하는 일이 많다. 예를 들자면 테스트의 종류를 열거하며 서로 어떻게 다른지 정리할 것이다. 예를 들자면 사후테스트/사전테스트로 구분지을 것이다. 테스트 주도 개발은 개발자 테스트며 테스트라기 보다는 개발(설계) 활동으로 보아야 한다..... 등 이유는 많다.
그러나 진행하다 보면 결국 마찰이 있게 마련이다. 심지어 이런 일이 발생할 수도 있다. '테스트'라는 명칭 때문에 혼선이 빚어지니 다른 이름을 사용하라고. 혹은 부서간 업무의 벽을 깨트린 책임을 묻거나 (타 부서의 실적이 좋은 경우) 자신 부서의 업무 범위에 슬쩍 포함시켜버릴 수도 있다.
커다란 조직에서는 테스트를 테스트라 부르지 못하는 경우가 생길 수 있는 것이다.
(물론 모든 큰 조직이 이렇다는 것이 아니며, 마찬가지로 모든 부서들이 서로 협력없이 충돌하기만 하지는 않는 것은 당연한 거다. 이미 이름에 따른 혼선은 많이 논의된 문제이며 새로운 시도들이 많이 이뤄지고 있지만 여기서 말하고자 한 것은 조직이 이같은 문제에 접근하는 방식이다.)
::: 사람과 사람의 교감! 人터넷의 첫 시작! 댓글을 달아주세요! :::
저는 B라는 조직에 Unit Test등 개발단계에서 진행하는 테스트를 지원하는 A소속의 테스터입니다. 개발자의 Unit Test와 Integration Test Case를 작성해 주고 개발자에게 잘 작성할 수 있도록 Tool 지원과 프로세스 지원을 하고 있습니다. 조금 다른 상황 같지만 무엇이 필요한지 실무자들이 리더들들 잘 설득?하는 것도 중요한 것 같습니다. 저희도 리더들의 생각(실적?)과 실무자들의 생각의 차이가 꽤 있는 편입니다. 제가 말씀드린 A와 B 모두 커다란 조직이죠.
정의의소 님 안녕하세요~
실무자, 리더, 개발자 문제를 천천히 정리해봐야겠네요. 지원 부서의 실무자는 자신의 리더도 설득해야하고, 지원받는 당사자인 개발자도 설득해야 하고, 지원받는 부서의 리더도 설득해야 하고... 만만치 않은 일입니다. ㅠ.ㅠ
이해관계가 모두 다르기 때문에 '잘 설득'하기 위한 전략도 각기 달라야 할테죠. 좋은 아이디어나 경험 있으시면 부탁드립니다~ ^^
테스트를 테스트라 부르지 못하는... 현실이 어이가 없긴 하지만.. ㅠ_ㅠ
BDD 가 나오듯 뭔가 다른 방향으로 접근할 수 있도록 아이디어를 짜야겠습니다.