테스트팀을 두는 이유.

우리는 개발자가 테스트해요. 
테스트팀의 존재이유에 대해 좋은 글이 올라왔다.
조금 다른 각도에서 테스트팀의 필요성에 대해 보도록 하자.

하나의 활동을 모니터링하다보면
비용대비 효율이 완연히 낮은 구간이 눈에 띈다.
적당한 용어가 있는지 모르겠지만 개인적으로 '정체구간'이라 부르는데
이러한 정체구간을 알아차리고 개선전략을 수립하는 것이 비용절감과 직결됨을 체감해왔다.
'정체구간'은 태스크 내에 성숙도가 떨어지는 영역을 말한다.
하나의 단위활동에 다른 성격의 태스크들이 묶여 있고
그중에서 약점부분이 세밀한 단위의 측정을 통해 발견되곤한다.
(측정단위를 큼직하게 잡았을 때는 이러한 정체구간을 발견하기 어려워진다.
(측정단위는 곰곰히 되새겨볼 중요한 부분..
정체구간을 일단 기억해두고 테스트에 대한 얘기로 돌아가보자.


먼저 일반적인 SI 대형프로젝트에서 테스트중인 상황을 일단 가정해보겠다.
- 프로젝트 팀은 계약당시부터 리소스부족이란 리스크를 안고 있었다.
- 현재로써는 구현생산성을 혁신적으로 개선할 수 있는 여지가 없다.
- 개발자로부터 제공된 프로그램들은 PL과 고객에 의해 수많은 결함들이 발견되어지고 있다.
- 현재 프로젝트팀에서 가장 바쁜 것은 PL이다.(협의,조율,결정,확인)
- 특정일자까지 모모프로그램 완료라는 성과판단기준에 묶여
  중요한 일을 확정하는 것은 뒤로 제쳐두고 코앞의 일정준수와 결함조치율에 매달리고 있다.
- 결함여부, 결함처리완료여부에 대해서 개발팀과 고객간 분쟁이 발생하는 일도 있고
  서로의 이익을 위해 투명하지 않게 합의를 하는 일도 종종 눈에 띄고 있다.  

설명하지 않아도 프로젝트가 여러가지 문제에 봉착해있다는 것을 알 수 있다.
SI 프로젝트에서 자주 반복되는 일반적인 상황인데 '정체구간'은 어디일까..?
어떻게 해야 성공에 다가갈 수 있을까?
언급했던 프로젝트 상황에서 보여지는 많은 문제들은
고객과 수행팀간 합의나 성과기준과 같은 근본적인 부분으로
프로젝트 초반에 해결이 될 수 있고 문제가 되지 않았을 부분들도 있다.
하지만 정치나 권력 등으로 이와같이 될 수 밖에 없는 상황도 있다.(SI노예계약)
그러면 해결될 수 없는 문제원인은 그대로 두고 결과를 개선해가면서
서서히 문제를 약화시키는 우회적 해결방법을 선택해야 한다.
테스트활동은 그런 우회적 방법으로 결과를 통해 현상을 개선해나가는 방법으로 효과적이다.

추천하는 방법은 '테스트팀 만들기'정도가 되겠다.
테스트팀을 두면 되면 극적인 반전을 가져올 수 있는 경우가 의외로 많다.
이상한 이야기다. 리소스가 부족한데 테스트에 리소스를 소요해서 극적인 반전을 가져온다니..
다음 그림을 보면서 그 이유를 천천히 들어보시라..

[품질기대치에 따르는 테스트팀의 리소스소요 및 품질향상기회]

성과기준이 특정시기에 결함이 있더라도 SW를 출시하는 것이 국내SI문화이므로
출시책임을 가진 PL들은 품질기대치를 고객의 품질허용한도 최하수준까지 떨어트린다.
그림에서 보여지듯 품질기대치가 error수준에서 fault, failure수준으로 떨어질수록
defect size도 커지지만 결함조치비용과 더불어 테스트비용도 끝도 없이 오르게 되는데 문제가 있다.
또한 고객신뢰수준이 점점 떨어진다는 문제가 있고 이것은 당장 드러나진 않지만 간과할 수 없는 큰 문제이기도 하다.
모든 결함들이 구현중에 발생하는 약간의 논리적 오류정도라면 행복하겠지만 
품질기대치를 떨어트린 경우 요구분석 당시부터 잘못되어 있던 결함들이 생기기 마련이고
이러한 경우는 그 여파로 코딩한두줄이 아니라 프로젝트가 캔슬되는 범위까지 확대되기도 한다.
이런저런 프로젝트에서 흔히 볼 수 있는 것들이다.

개선할 수 없는 환경에 있지만 운영하기 나름이다.
주어진 일정까지 결함조치율 100%를 달성하라는 고객의 요구에 따라
개발자와 PL 팀원 기타 인력들을 생산이 아닌 결함확인에 집중하는 것은 자멸의 지름길이다.

떨어진 품질을 정해진 일정을 무기로 적정수준으로 조정하는 것에는 많은 조정/합의/결정이 따른다.
책임을 행사하는 PL이나 고객은 위와 같은 이유로 품질이 떨어진 프로젝트일수록 매우 바쁘다.
하지만 이들이 검증과 확인에 전적으로 몰두할 수 밖에 없는 상황에 놓이게 되면 
생산적인 활동에 몰두할 수 없게되고 프로젝트 성공은 이러한 상황이 오래방치될수록 점점 더 멀어진다.
전적으로 고객과 개발자가 개입되는 user acceptance test도 항상 바람직한 것만은 아니다.
위에 언급된 것과 같이 품질을 합의해야 하는 경우에는 최악의 걸림돌이 될 수 있다.
품질을 합의해야 하는 다소 바람직하지 않은 환경에서 PL과 고객관계는 절대적이다.
낮은 품질에 대한 합의가 원활할거라 상상하는가? 합의가 다른 태스크에 어떻게 영향을 미칠까..?
생산성악화, 관계망치기, 다른태스크 연쇄악화의 지름길이 될 수도 있다.
따라서 현재 환경을 정확히 주시해야 한다.
우린 전혀 생산적이지 않은 사이클로부터 프로젝트팀이 벗어나도록 해야 한다.
어떻게? 확인, 검증, 리포트, 문제양상 분석과 같은 되돌아보기 활동들을
테스트팀이 떠안아 줌으로 인해서 일단 생산적인 프로세스로 넘어갈 수 있다
.
결함과 현상에 대한 투명성 문제와 고객신뢰문제 발생소지를 없애는 완충막도 될 수 있다.
그러고 나면 생산성은 올라간다.. 컨텍스트스위칭도 줄어들면서 주욱~ 주우우욱~
이것은 결합이다..아니다, 해결된것이다..아니다..
이와같이 별거아닌 잡다한 것으로 고객과 PL관계를 망쳐서야..;;
중립적인 조직이 있고 그들이 관계를 유연하게 유지하기 위한 화살받이 역할을 하고
핵심적으로 확인, 확정이 필요한 부분을 끄집어내거나 수행팀과 고객사에 요구하고 확인함으로 인해서
프로젝트 성공에 직접적으로 기여할 수 있는 역할을 수행할 수 있게 된다.
물론 개발팀에는 리소스까먹는 잡짓하는 사람들이 들어온것으로 보일수도 있겠지만 말이다....


결론, 품질합의가 필요한 일반적인 SI상황에서
정체구간은 테스트시점에 '롤'로 인해 생기기 마련.
이 때 테스트관리자와 테스트팀이 좋은 전환점이 될 수 있음. 그래서 테스트팀이 필요.. 끝;;

p.s 태스크나 일자체를 횡이나 종으로 잘라서 고효율을 유지하도록 하는 방법이 있는데
     가령 정치와 비정치, 당장하는 것과 시간을 들여 숙성시키는 것.. 등 생각하고 고안하기 나름인듯..
     테스트이야기를 떠나서 정체구간 분석놀이는 프로젝트를 고민하는 사람들의 숙제..

덧글

댓글 입력 영역