테스트 조직 관리1부_기존 조직 정비하기

(사진이 너무 재미나죠?^^ 윈도우를 설치한 노트북이랍니다.^^)

오늘은 테스트 조직에 대한 이야기를 해보려 합니다.
테스트 조직은 이미 세팅되어 있거나, 새로 세팅해야 하는 두 가지로 구분이 됩니다.

 

오늘은 이미 세팅되어 있는 조직에 대한 이야기를 해보려 합니다.

이미 세팅되어 있는 조직은 지속적인 Brain storming과 improve & improve가 관건이 됩니다.
기존에 test object에 따라 조직의 TO가 결정될 것이고…
그것에 따라 할당된 인원에 따라 프로세스 내지는 프로덕트 단위로 인원이 할당될 것입니다.

기존 조직에 대한 개선은 STA나 유수의 조직 컨설팅해주는 회사들이 있습니다.
말 그대로, 조직의 output을 늘리기 위해 프로세스, 조직등의 전반적인 것을 모두 수정할 수 있도록 도와주는 업체들이죠.

하지만, QA조직이 있는 경우에서 컨설팅까지 받아야 할 경우는 제 생각에는 아주 아주 드물다고 생각합니다. 조직이 상당히 방대하거나, 아니면 담당자들로 하여금 Risk를 무시하고 넘어갈 정도로 망가진 조직이 아니라면, QA조직내부에서 진행이 가능할 것으로 생각됩니다.
물론 수반되는 기간이 길어지거나, 관리자로 하여금 엄청난 커뮤니케이션 능력을 요구할 수도 있습니다.

 

가령, 어떤 QA팀에서 손실되는 일정, 금전적인 부분을 발견했을 때의 대처 방법들은 모두 다르게 되어 있습니다. QA권한이 큰 곳에서는 그만큼 그 어필의 능력 마저도 크기 때문에… 구체적인 제제를 가할 수 있지만, QA권한이 CS파트쯤으로 생각하는 회사에서는 눈에 보이는 Risk도 넘기고, 또 넘기고… 그러다 보면 내성이 생겨서 언젠가는 봐도 모른척하는 그런 일들이 생길 것입니다.
(실질적으로 필자는 말한 것과 같은 상황을 수도 없이 겪었고, 지금 상황이 그렇지 못해 제안 및 제시 후 넘어 갈 수 밖에 없었습니다. – 항상 메일로 증거를 확보 해두었죠 ㅡㅡ^)

 

그럼, 실질적으로 개선을 할려고 노력을 하려면 참고해야 할 부분이 필요한데… 어떤 것들이 있을까요?

IEEE나 ISO에 대한 내용을 참고해보시면 어느 정도 도움이 되고, 규격으로 기술된 문서에 지쳐버리신 분들은 여러 오픈되어 있는 방법론에 대한 고찰을 통해서 진행하는 것도 좋겠습니다.
Agile 개발 방법론이라는 것이 있습니다. 김창준님의 블로그(http://agile.egloos.com/)를 참고하시면 많은 도움이 될 것 같습니다.

그리고 린소프트웨어 개발 방법론이라는 것이 있습니다. 이 부분에 대한 것은 애자일로부터 파생된 내용도 있고 실제 적용해서 성공사례들도 많이 찾아볼 수 있답니다. 네이놈에서 조금만 검색을 해보신다면 서평 및 갖은 내용들을 접해 보실 수 있습니다.

마지막으로 테스트 주도 개발이라는 것이 있습니다. 이것은 QA조직 개선이라기 보단, 개발과 QA관계의 새로운 개선이 필요할 때 알아보시는 것도 좋을 것 같습니다. 일반적으로 개발자님들께선 QA에 대해서 상당히 신뢰하고 있지 못하고 있는 것 같습니다. 특히 소스코드 한줄 한줄이 돈이 될지도 모르는 대한민국이라는 국가 형편상… 개발 단계에서 무조건 화이트 박스테스트를 해야 하는 것은 아니지만, 코드 한 줄이 돈이 되서 인지 오픈 하지 않더군요.

 

이 정도로 간단하게 정리 해보았습니다.
물론 구체적인 지식이 기재된 것도 아니고… 그렇다고 아주 멋진 말도 글도 그림도 없습니다.

하지만, 단 한분이라도 이런 내용이 있었구나라고 리푸레쉬 된다면 언제든 블로깅하겠습니다.
대한 민국의 모든 회사에 QA팀이 최고의 권한을 가지고, 회사에서 가장 먼저 QA 팀을 세팅하는 그날까지 블로깅할까합니다.(그게 가능한 이야기 일까?^^)

 

End
Written by 밤의카사노바