테스트 조직 관리

테스트 팀의 역활은 나쁜 뉴스를 발견해서 보고하는 것이다. 그것을 듣고 프로젝트의 중지를 경영진이 결단하는 경우도 있고 스케쥴을 조정하여 출하를 늦추는 경우도 있다.
프로젝트가 지연되면 작업이 늘어나는 것 뿐만 아니라 벤처 기업의 경우는 도산할 수도 있다. 테스트 관리는 매우 스트레스가 쌓이는 작업이다.

적은 월급에 젊은 부하 직원 관리에 골 머리를 썩힌다. 그런데도 거의 칭찬받는 경우가 없다.  회사가 특별히 테스트 팀을 설치하는 것은 품질을 개선하는 비용을 삭감하는 효과가 있기 때문이다.  테스트 팀이 좋은 역활를 하기위한 필요한 것을 열거해 보자.

-        능력
테스트를 담당은 테스트 기술에 정통하지 않으면 안된다. 그리고 건설적인 의견을 교환할 필요도 있다. 프로 의식을 공유하는 것이다. 테스트가 자신의 일이고 테스트에서는 누구에게도 지지않는 다는 의식이 중요하다.

-        공수 (테스트 기간)
테스트 담당자는 테스트를 위해 배치해야 만 한다. 테스트의 공수는 테스트를 완료하기 위해 확보는 것이지  프로그램밍과 문서 작업을 위한 것이 아니다. 프로그래머가 한가할 때 하는 테스트와는 틀린 것이다.

-        독립성
테스트 결과는 프로젝트 매니저가 아니고 테스트 팀의 매니저에게 보고 되어야 할 것이고 중요한 장해를 놓치거나 숨길 경우에는 엄하게 질책할 필요가 있다. 역으로 출하 직전에 대량의 버그, 치명적인 장해를 보고해 왔을 경우는 반드시 칭찬을 하자. 그렇게 하면 예를 들어 프로젝트 매니저가 버그를 잠시 숨기고 싶어도 테스트 담당은 자신의 역활을 철저히 할 수 있을 것이다.
 
실수를 범해서는 안된다. 테스트 관리는 인내를 필요로 하며 이동이 많은 역활이기도 하다 . 이유 로서 스트레스가 크기 때문에 다른 부문으로 옮기려고 하기 때문이다. 또 하나는 안됐지만 자신의 문제이다. 인간관계의 파탄을 초래 하거나 제품을 형편 없이 만들거나 같이 일해온 사람의 생활을 어렵게 많들어 버리기도 한다. 이러한 것은 바람직하지 못한 일이다. 원만한 인간관계를 유지하면서 직권의 남용도 부하의 혹사도 하지않고 품질의 개선에 크게 공헌하는 훌륭한 테스트 팀의 관리가 결코 불가능한 것이 아니다.  성실하며 프로의식, 윤리관, 인격을 손상하지 않도록 테스트 팀을 관리하지 않으면 안된다.

테스트 팀의 역활
테스트 팀은 4종류가 있다. 각각의 조직의 방침에 기초하여 서로다른 권한을 부여하고 있다.
-        품질관리 (QC： Quality Control) Type：표준과 규칙을 준수 시킨다.
-        품질보증 (QA： Quality Assurance) Type：품질을 어떠한 방법으로 보증한다.(적어도 보증하려고 한다)
-        테스트 기술 Type：프로젝트 매니저 (회사)에 버그의 발견과 보고라고 하는 특수기능을 제공한다.
-        개발 기술 Type：프로젝트 매니저에게 테스트를 하려고 하는 각양각색의 기술 서비스를 제공한다.  

품질관리 (QC： Quality Control) Type의 그룹
QC Type의 그룹은 커다란 권한을 갖고 있다. 표준데로 작업이 수행되어 지적한 장해가 수정될때 까지 제품의 출하를 거부할 수도 있다. 테스트 기능 타이프와 개발 기능 타이프의 그룹은 부러워할 수도 있지만 실제로 이러한 권한을 갖기 위해서는 큰 보상이 따른다.
소프트웨어의 QC그룹은 공장의 긴 생산 라인에서 토마토 통조림을 몇개 추출하여 검사를 하는 것이 아니다. 회사에 단 1라인 밖에 없는 생산라인을 수 일에서 수 주간  때로는 수 개월 정지 시키기 때문에 경영진은 QC그룹의 출하정지에  곧바로 따를 필요성이 있는지 또는 프로젝트 매니저의 간원을 받아드려 출하를 지시할 때도 있다.

                            「경영진이 진정한 품질관리 그룹이다」

테스트 팀의 역활은 경영진의 판단을 돕는데 있다. 테스트 팀은 남아 있는 불량의 심각함을 보고하는 것으로 출하의 가부 결정은 경영진이 판단 하는 것이다. 따라서 QC그룹이 갖고 있는 실질적 권한은 경영진이 숙고해 판단할때 까지 출하를 정지해 두는 권한이다. 그러나 그것을 개발측과 QC그룹이 인식하고 있는 것은 거의 없고 QC그룹에 의한 출하 정지의 판단을 경영진이 뒤집어 버리면 QC그룹의 입장이 난처해져 버린다.

또 QC그룹이 강한 권한을 갖은 것 처럼 보이기 때문에 개발측은 공포와 불신감을 갖게될 수도 있다.

결과적으로 프로젝트 매니저는 QC그룹에게「적절」하다고 압력을 행사한다. 그러나「적절」함은 잘 정의되어 있는 것이 아니다. 예를 들어 이러한 테스트는 적절한 것인지?

-  테스트의 각 사이클에서 새로운 테스트 케이스를 추가 하는 것
-  실제에는 결코 입력 안되는 극단적인 값으로 테스트 하는 것
-  일부러 이상한 데이타를 읽어 들이는 것
-  현장에서 바로 테스트 케이스를 작성하는 것
-  특수한 경우에만 발생하는 조그만 버그를 보고하던지 설계의 잘못을 지적하는 것
-  장해 레포트에 개선요망 사항을 기록하는 것
-  장해 레포트에 설계서의 잘못을 기록하는 것

-        사전에 명시되어 있는 테스트에 합격되지 않았다고 테스트를 거부하는 것
-        해결하는데 시간이 걸린다고, 그저 1개의 불량 때문에 테스트를 거부하는 것

프로젝트 매니저 중에는 제품과 자신이 불리하게 될경우 모든것을 부적절 하다고 판단하는 사람도 있다.그래서 QC부문의 책임자가 부적절하다고 판단하는 것이 부적절 하다고 거절하는 경우도 있다.

적절한지 어쩐지는 놓아두고 QC라는 직책을 수행하고 있는 한은 적절한지 어쩐지에 관해 장시간 의논해야 한다는 것을 각오해야 한다. 
필자의 인식으로는 QC 그룹는 미움받고 잠재적으로 적대관계에 있다고 인식된다. 또한 평가는 낮고 품질에 대하여  그렇게 공헌을 하지 못 한다고 생각하고 있다.
또 QC그룹이 갖고 있는 권한은 실제 매우 한정되어 있어 간단하게 뒤집어 버리고 만다.

품질보증 (QA： Quality Assurance) Type의 그룹
QA타이프 그룹은「품질보증」을 위한 그룹이다. 그러나 테스트 만으로 품질을 보증하는 것은 불가능 하다. 품질 나쁜 프로그램을 철저하게 테스트해 버그를 수정해도「충분히 테스트한 품질 나쁜 프로그램」에 지나지 않다.  사실은 QA그룹은 전 개발공정에 관여할 필요가 있다. 표준을 책정해, Review방법을 생각하고 설계 또는 개발을 개선하는 방법을 지적한다. 즉 QA그룹의 성과는 불량의 예방에 있다. 물론 테스트도 하지만 그것은 업무의 일부 일뿐이다.

실로 QA그룹은 엄청난 기술을 갖고 있지 않으면 안된다. 이런 점에 주의할 필요가 있다. 분석, 설계 , 실행, 프로젝트 관리, 문서 작성등 모든 일에 유능할 필요가 있다. 그렇치 않으면 신뢰 받기 어렵기 때문이다.

「품질보증」이라고 부르는 방법은 매우 위험하다.  만약 어떤 그룹이 품질을 보증 한다고 하면 다른 부문은 보증하지 않아도 괜찮은 것인지. 이 문제는 Juran(1989)으로 부터 제기된 것으로 독립된 QA그룹을 배치 한다는 생각은 제 2차세계대전 전에 생겨 났으나 안타깝게도 제대로 기능을 하지 못했다.  적어도 소프트웨어 개발조직에서 작업을 한 경험이 있다면 프로젝트 매니저의 불만을 들은 적이 있을 것이다.  「나의 일은 납기까지 제품을 완성 시키는 것이지 품질을 확보하는 것은 나의 일이 아니고 QA의 일이다 」 품질의 책임을 경영진 이외의 부문에 집약 시키면 실패한다.

회사전체, 특히 경영진이 품질에 책임을 갖지 않으면 안된다. 이것은 일본과의 경쟁에 의해서 얻은 교훈으로 (Deming 1982), TQM(통합적품질관리)의 기초가 되는 생각이다
실제에는 QA라고 불리는 그룹이 품질보증은 하지 않고 테스트 만을 하고 있는 경우가 많다.
혼돈하는 것도 무리는 아니지만 QA그룹의 역활은 테스트 만이 아니다 라는 것을 이해하면 할수록  테스트만 수행하는 QA그룹의 사람은 즉 테스트에만 제한되어 있다고 생각하게 되며 테스트 담당자 로서 완벽해도 타의 임무를 소화하지 못해 하고 싶은 열정을 잃게 된다.

테스트 기술 Type 그룹
프로젝트 매니저에게 테스트 기능을 제공하는 것이 테스트 기술 Type그룹이다. 주어진 역활은「프로그램 버그」를 발견하여 상세하게 설명하여 알려야 할 사람에게 확실하게 정보를 제공하는 것이다. 테스트 기술그룹에는 제품을 출하하는 권한도 출하를 정지하는 권한도 없다. 프로그램의 불량과 테스트 실시의 상황 등을 보고하면 경영진이 최종판단을 내리게 된다. 그룹에 따라서는 제품의 일부 만을 테스트 하는 경우도 있다. 특히 각 사이클의 테스트에서 전부를 테스트하는 경우는 없다. 또 회사의 방침으로 프로그램머가 테스트를 주로 담당하고 테스트 그룹은 보조 작업만을 하는 경우도 있을지 모른다. 테스트 기술그룹의 작업은 상세한 기능 일람의 작성과 순서를 기술하는 것으로 필요 하다면 테스트의 자동화를 수행한다.  테스트의 분석 , 설계, 설치, 실시, 기록의 모든 책임을 지는 역활이다. 프로 로서의 프라이드를 부하에게 갖도록 하자.

프로젝트 매니저 중에는 테스트기술의 제공 보다도 품질관리의 책임을 테스트 기술그룹에 희망하는 사람도 있다. 무리하게 QC타이프로 하려고도 한다. 테스트의 책임은 전부 테스트 팀에 있고 프로그램머는 화이트 박스 테스트 조차 필요 없다고 선언하는 경우도 있다. 테스트 팀이 발견 못한 버그는 수정하지 않아도 좋다고 말하며 버그를 발견 못한 것을 비난 하기도 한다. 이러한 태도는 품질에 대한 책임을 포기 하려고 한다고 이해할 필요가 있다. 품질을 강요하는 듯한 책략을 사용할 때에는 강하게 저항 하도록 하자. 이럴 경우는 분명히 난제에 봉착하게 된다.

다른 전부문과 대립하는 상황이 되기 쉬우니 상사에게 업무의 조율를 부탁하도록 한다.

「프로젝트 매니저야 말로 진정한 품질보증의 리더 이다. 테스트 기술그룹은 기술적인 정보를 제공하고 설명하는 것으로 품질에 관한 판단을 돕는데 있다. 」
이와 같은 정의는 테스트 기술그룹의 책임을 회피하는 것이 아니고 테스트의 실시며 문서의 작성 테스트 결과의 해석에 관해서  질 높은 작업을 신속하게 제공할 책임이 있기 때문이다. 품질에 관한 판단을 하지 않지만 테스트 기술그룹은 전문가 로서 도움이 된다 라는 현실을 부정할 것은 못된다. 또 품질에 관한 판단을 포기 했다고 해서 테스트 기술그룹의 권한을 실질적으로 전부 거둬 버리는 것도 아니다. 프로젝트 매니저와 의논하거나 경영진에 정보를 제공하는 권한이 아직 남아 있다. 이와 같은 권한을 잘 살리기 위해서는 데이타의 수집 능력과 표현 능력의 향상이 필요하게 된다. 생산라인의 정지며 새로운 순서의 제시 보다도 데이타를 기초로 해서 정확한 표현으로 설득하는 편이성과가 크다.
   

개발기술 Type 그룹
개발기술 타이프의 테스트 팀은 테스트 기술 타이프를 확장한 것으로 기술을 제공하지만 관리며 판단은 하지 않는다. 정치적인 교섭도 하지 않는다. 테스트의 전문기술을 더해 품질의 개선, 개발측의 지원, 개발자가 전문성을 배양할 수 있도록 품질 향상 기술의 제공이 개발 기술그룹의 역활이다.

개발기술 그룹에 있어서 테스트는 주 업무이고 어떠한 조직에 있어서도 요구되는 것이다.
-        디버그
-        고객에 대한 기술지원
-        메뉴얼 교정
-        메뉴얼의 기술적인 평가 (보통 테스트 담당자보다 훨씬 강한 권한으로 기술적 검증을 수행한다)
-        조작성 테스트
-        호환성 테스트
-        고객 만족도 조사

담당자에 따라 기술과 취향에 차이가 있어 이러한 작업이 캐리어의 발전에 도움이 되는 경우가 있는가 하면 지겨워 죽을 정도로 하기 싫어하는 작업으로 느끼는 경우도 있다. 테스트 이외의 일을 포함하여 무슨 작업을 하고 싶은지 질문하여 도움이 될 수 있도록 하자.

필자는 QC와 QA라고 하는 종래의 개념을 초월한 4타이프 그룹의 테스트 팀 개념을 강하게 추천하고자 한다. 특히 개발기술 타이프의 그룹의 발상은 마음에 들지만 충분히 시험한 것이 아니며 적용시에는 주의가 필요하다. 테스트 기술 타이프 그룹은 잘 운영 되지만 부하 직원의 케리어에 주의하지 않으면 필시 전직해 버릴 것이다.

테스트 팀은 하늘의 도움이 아니다.

테스트 팀이 없는 개발부문에서는 코드가 정확하게 동작하는 것을 자신이 보증하지 않으면 안된다. 그러나 테스트 팀이 있으면 긴장이 풀려 버그를 놓치게 된다. (결국 테스트 팀이 부담을 갖게 되는데 정말로 이래도 되는 것일까) 개발자 자신이 테스트 해서 정상인지 아닌지 신경써 주기를 테스트 팀에서는 바라고 있다. 확실하게 버그를 발견할 수 있고 비용을 낮출 수 있기 때문이다.
버그의 대부분은 프로그램머가 먼저 발견하기 때문이다 .  누구 보다도 코드를 이해하고 있고 버그가 있을만 한 곳을 잘 알고 있다. 테스트 팀은 프로그램머가 놓쳐버린 버그를 발견 하지만 프로그램머 도 물론 테스트에서는 놓쳐버린 버그를 발견할 수 있다.

프로그램머는 비교적 낮은 비용으로 버그를 발견한다. 문제의 발견이 빠르면 빠를수록 발견과 수정에 드는 비용이 감소한다. 그 이유를 열거해 보자.
-        문제를 파악하기 위해 몇번이고 테스트하여 재현할 필요가 없다. 버그가 있을만 한 부분을 직접 조사할 수 있고 더구나 발견되면 즉시 수정이 가능하다.
-        타인에게 불량을 설명할 필요가 없다.
-        설계서를 확인 하거나 장해 보고를 한다던지 수정 사항을 보고할 필요가 없다. 보고서를 작성할 시간에 버그를 수정하는데 힘을 쏟을 수 있다

애석하게도 프로그램머에 의한 테스트는 점점 줄고 있다.  개발측의 매니저는 테스트에 시간이 걸리는 것을 인식하고 있기 때문에 프로그램머에게 테스트를 생략 하도록 지시하여 개발이 빨리 완료 되었다고 하려고 한다. 자주 일어나는 일이지만 심한 경우는 프로그램머가 테스트를 거의 하지 않아 테스트 작업시 파닉크 상태에 빠지기도 한다.
테스트 팀을 조직할 때는 마음 속으로 준비해 두어야 할 사항이 있다. 종래의 사내표준에 따라 테스트 한다고 해도 대단한 작업이기 때문에 테스트 팀은 자신을 포함하여 최저 4명 이상으로 구성할 필요가 있다.

    
테스트 전문 아웃소씽
사내에서 전업무를 테스트 할 필요는 없다. 테스트 전문 기업에 메뉴얼과 프로그램을 위탁하면 프로그램이 문제없이 동작 할 때까지 몇번이고 열심히 테스트해 줄 것이다.
「소프트웨어 테스트에 관한 문헌을 읽어보면 제 3자가 독립적으로 테스트를 수행 해야만 제품의 신뢰성이 향상된다」라고 강한 신념이 묻어 있다는 것을 알 수가 있다.」
필자의 경험으로는 전문회사에의 테스트가 만능도 절대적인 것도 아니며 주의해야 할 문제를  나열해 보자.

-        생각만큼 독립적인 테스트가 가능한지
개발측과 거리를 두고 테스트 팀의 독립성을 보장 한다는 역활과 계약은 없다. 테스트중에 계약해지 당하고 싶지 않고, 다음 제품의 테스트 작업도 수주하고자 생각하고 있다.

그리고 개발측의 눈치를 보며 잘 보이려고 하여 버그를 발견하지 않으려고 할지도 모른다.

-        아웃소씽 업체의 표준이 사내표준 보다 질이 낮을수 있다.
특히 설계에 관해서는 언급하지 않는 경향과 설계서, 메뉴얼과 일치하면 버그라고 하지 않는 경향이 있다.  테스트를 아웃소씽 할 경우는 테스트 설계를 철저히 하는 역활의 배치도 필요하다.

-        테스트 전문 업체라고 해도 기술이 높지 않은 경우도 있다.
-        중요한 테스트를 놓치는 것은 사내도 아웃소씽 업체도 같다.
-        관리업무와 기술지원을 수행하지 않는 경우도 있다.
-        아웃소씽이 비용절감은 아니다.
-        제품 고유의 지식을 갖고 있지 않다.
-        보고된 장해를 사내에서 전부 재현해 둘것
-        관련된 장해를 찾아 볼것
-        GUI는 사내 첵크할 것

아웃소씽 업체의 테스트와 무관하게 테스트해 둘 것
-        테스트 대상 업무가 누락된 것은 없는지 확인할 것

테스트 스케쥴 작성 방법
테스트 팀의 매니저는 프로젝트의 스케쥴에 관한 책임을 일부 갖고 있다. 테스트 스케쥴은 상류 공정에 의존하기 때문에 작성의 어려운 점이 많고 개발이 늦어 지거나 예상 보다 버그가 많이 발생 하거나 또 유저 인터페이스의 변경 등으로 테스트 시간이 늘어나기도 한다. 정말로 어려운 국면에 처해 있지만 도망갈 수도 없고 변명도 할 수 없다.  
스케쥴 작성의 중요한 목적 4가지를 열거한다.

-        프로젝트 메니저에게 프로젝트의 진행 사황을 전달하기 위함
프로젝트 메니저는 테스트에 필요한 작업과 각각 어느 정도 시간이 걸리는지 알아 둘 필요가 있다.
-        일정을 앞당길 수 있는지 엄수해야 할 일정은 언제인지 판단을 할 수 있는 자료로 활용
-        무리한 작업으로 테스트 작업의  미스를 방지 
-        생산성을 최대로 높이기 위해
인간은 달성 가능한 스케쥴 이라면 어려워도 열심히 일을 한다.  달성 불가능한 스케쥴을 세워서는 안된다. 잔업, 휴일출근이 많으면 필요 최저한만 일을 하게 되어 버리며 일정을 늦추는 결과를 초래하며 제품의 개선 등의 제안을 하지 않게 된다.
   
테스트의 스케쥴이 정직하고 확실하게 작성되면 스케쥴 작성 목적은 전부 만족하게 된다.  

테스트 공수 산정 방법
1. 실적과 생산성 이용 방법
-  평균 테스트 사이클 횟수
       보통의 프로그램을 릴리스 가능한 품질까지 테스트 하는데 평균 8사이클의 테스트가 필요하다. 많을 경우는 12 사이클, 적을 때는 7사이클 이하의 큰 차이가 있다.
-  1회 사이클 테스트에 걸리는 시간
-  1일 보고되는 버그 수
-  테스트 1건당의 소요 시간
-  1시간당 Review 가능한 Page수
    물론 토큐멘트의 종류와Review의 목적에 따라 다르다.
-  1시간당 테스트 가능한 에라 메세지 수
     　 에라 처리의 테스트에는 어느정도 공수가 필요한지
    -  1시간당 실시 가능한 테스트 항목 수

2. 작업의 일람표 이용 방법
  필요한 테스트의 작업을 전부 열거하여 일람표를 작성한다. 특히 누락 항목이 없도록 주의할 것
-   간단하게 테스트할 수 없는 작업을 알 수 있다
    -   작업에 우선순위를 부여할 수 있다
    -   부분적으로 실시하여도 작업을 명확화 할 수 있다.
    -   자동화 하여 생산성을 올릴 수 있는 작업의 선별이 가능하다.
    -   주어진 일정으로 테스트를 완료할 수 없는 이유, 요원의 증원, 시간 , 자금 등 상세하게
        설득력 있는 문서 작성이 가능하다.

3. 프로젝트의 분류에 의한 방법
-   제품의 복잡성으로 판단한다.
    -   테스트 대상 프로그램의 신뢰성으로 판단.
        어떤 프로젝트 메니저와 어떤 프로그램머가 개발 했는지에 따라 신뢰성의 점수를 부여한다.
    -   공수 산정 테이블을 작성한다.
        제품의 복잡성과 신뢰성으로 테이블 작성

http://www.ncicom.co.kr/board/view.php?id=data&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=9