상세 컨텐츠

본문 제목

Test management: the greatest risk (번역)

테스팅 번역 자료들

by techbard 2007. 6. 28. 09:23

본문

반응형


http://www.professionaltester.com/magazine/

Articles from the April 2003 issue중 Test management: the greatest risk Felix Redmill analyses the influence of test managers의 번역입니다.

Test management: The greatest risk

위험 관리 전문가 Felix Redmill은 테스트 매니저의 결정에 따라 프로젝트나 팀 그리고 산출물까지 영향을 받는 다는 것을 상세히 고려해야 한다고 말한다.

개발중인 하나의 시스템을 테스트 하는 것은 그 자체로도 하나의 프로젝트이다. 효과적으로 수행 하기 위해서 신중한 계획이 필요하다. 테스터들이 테스트 계획대로 움직이지 못하게 강제하는 수많은 요인들이 있기 때문에 동적인 프로젝트 관리가 요구된다. 테스트 매니저는 프로젝트 매니저가 되어야 할 필요가 있으며 단지 그때 그때 마다 적절한 매니저가 아닌 탁월한 매니저가 되어야 한다.

모든 매니저들은 결정을 내려야 할 필요가 있다. 그들은 진행을 계획하고 모니터링하며 가장 필요한 곳으로 직원을 배치한다. 그들은 변경 사항을 예상해야 하고, 변경 사항이 발생했을 때 변경 사항을 뒤집을 것인지, 약간 바꿀 것인지, 그것을 우선시 할 것인지 결정을 내려야 한다. 의사 결정의 업무는 관리 업무일 수는 있지만 그렇게 두드러지진 않으며, 관리자의 몫은 아니다.

프로젝트는 목적을 달성하기 위한 다양한 접근 방법이며 의사 결정은 목적을 달성하는데 있어 매우 중요하다. 변경이란 빈번하게 발생할 수 있으며 항상 불가피하게 계획으로 부터 벗어나게 될 수 있다. 변경의 영향을 컨트롤하는 것은 매우 어렵지만(가끔은 갑자기 발생한 변화 조차도), 변화들을 예측하는 능력과 그 변경으로 인해 발생할 수 있는 영향을 초기에 무력화 시키기 위해 조치를 취하는 것은 더 필요하다.
변화의 양에 따라 완전히 압도당 할 수도 있고, 가끔은 프로젝트 매니저를 완전히 반발 모드로 돌변시킬 수도 있다. 하지만 훌륭한 프로젝트 매니저는 변경된 상황으로 이끄는 원인을 찾을 수 있으며, 그 변경이 발생시킬 수 있는 효과를 예상하고 그와 반대로 행동하거나 오히려 그 상황에서 이득을 찾아내기도 한다. 이러한 프로젝트 매니저들은 매우 조심스럽게 계획을 세우지만 그 계획을 자신의 목적을 달성하기 위한 도구로 인식한다. 그들은 목표에 맞추어 계획을 끊임없이 체크하며, 계획이 목표에서 벗어날 때를 발견하고 쓸모 없게된 계획을 새로운 것으로 대체한다. 이런 행동은 계획을 세우는데 시간이 필요하기 때문에 용기가 있어야 하며, 궁극의 목적은 원래의 목표를 달성하는 것이다.

모든 매니저들은 자신의 목표를 위협하는 위험 요소를 인식하고 있어야 한다. 프로젝트는 그 속성상, 특별히 위험이 많을 수 있다. 테스팅 프로젝트가 올바르게 셋업 되어 있지 않거나, 상위 개발 프로젝트에 정확하게 통합되어 있지 않거나, 최고 수준의 활동적인 관리하에 있지 않다면 매우 위험해질 수 있다. 시간과 예산의 여유 양쪽다 자주 시작하기에는 너무나 모자라고, 제한된 범위 이상으로 재 테스트의 필요가 발생할 수도 있다. 스케쥴은 계획을 세우기 어렵고 개발팀으로 부터 아주 늦게 릴리즈가 전달되어 오는 경우 혼돈에 빠질 수 있다. 작업 인원 요구 사항의 변경은 자주, 빈번하게 발생할 수 있으며 그 폭은 중요해질 수 있다.

모든 프로젝트 매니저들에게는 때때로 적절하지 못한 정보를 기초로 판단을 내릴 필요가 있다. 하지만 결정에 필요한 것을 미리 예견하고 시간이 없더라도 사전에 필요한 정보를 얻으려고 착수하는 것은 가능하다. 훌륭한 의사 결정은 모든 프로젝트 매니저의 필수 조건이고 의사 결정의 특성은 특별히 테스팅 프로젝트의 매니저에게 매우 필요하다.

프로젝트의 이런 상황에서 고려되어야 할 세 가지 중요한 위험 요소 범주가 있다.

첫째로, 테스터의 관점에서 볼 때 '앞으로의 위험'인 시스템의 운영에 관련한 위험 요소가 있다. 이것들은 '위험 요소 기반의 테스팅'의 계획을 기초로 해서 다루어질 수 있다.

둘째로, 소프트웨어 개발팀으로 부터 오는 소프트웨어의 불확실성과 낮은 수준의 품질이 테스팅 프로젝트에 강요하는 '후방으로 부터의 위험'이 있다.

세째로, 테스팅 프로세스 그 자체에서 만들어진 위험 요소가 있다. 이것들은 내재되어 있는 리더쉽, 팀워크, 훈련, 테스팅 활동의 할당 및 배분, 작업의 우선 순위 조정 등으로 부터 발생한다.

만일 앞으로의 위험을 테스트 계획에서 알 수 있다면, 그것들은 고려되어야 한다. 테스트 매니저는 그 위험들을 구별해내고 분석해서 테스트 계획에 반영해야 하며 그런 다음 무언가 잘못되어 질때 재계획의 기초로 그것을 재사용한다. 이것은 사소한 부분이 아니며 이전 관련 기사들에서 다루어졌었다.

두 번째 유형인 후방으로 부터의 위험은 처음에는 테스팅 프로젝트의 통제를 받지 않는 것처럼 보일 수 있다. 하지만 테스트 매니저가 프로젝트 회의 자리에 않게 되면 프로젝트 계획에 휘말리게 되어 그녀는 개발과 테스트 계획 모두에게 동등한 영향을 미칠 수 있다. 더우기, 테스트 매니저의 개발 매니저는 동료로만 관계가 있는 것이 아니라 공급자와 고객으로 까지 확장된다. 그녀는 계획되고 관리되어야 하는 테스팅 서비스를 제공하는 공급자이다. 그녀는 또 시간과 품질의 통과 기준에 적합한 소프트웨어를 제공하는 개발팀에 의지하는 고객이기도 하다. 구조적이지 않거나, 잘못된 문서화 그리고 불충분한 코드 검토, 기한 미 엄수 들이 기준이 될 수는 없다. 하지만 받아 들여져서는 안된다. 전문가 기질이란 '일을 잘하는 것'에 국한되지 않고 우리가 의지하는 다른 사람들의 훌륭하고 믿을 수 있는 업무를 요구한다. 전문가들에게는 그들 사이의 업무 처리를 위해서 훌륭한 특정 품질 요구 사항이 있을 것이다. 적절한 사전 합의는 당황하지 않고 '예외'나 '실수'에 대해서 정상적인 반응을 보이는 좋지 않은 품질에 대해서 거부하게 한다. 만일 테스트 매니저가 정기적으로 개발 매니저와 만나서 릴리즈 전달과 테스트 수용 기준, 문제 사항 협의, 제안 발의 및 수용 그리고 계획 개선에 대해서 동의한다면, 테스트 매니저는 위험 요소만 감소 하는게 아니라, 그녀의 관리 대상들에게 전달할 정보를 얻게 된다.

따라서, 테스트 매니저가 테스팅 프로젝트의 후방으로 부터의 위험을 상당히 감소시킬 수 있는 여러 가지 방법이 존재한다. 훌륭한 테스트 매니저는 위험 기반의 접근법을 사용해서 감소 되어야 하는 모든 위험 요소와, 실제 구별해 내고 감소시키는 절차를 결정해서, 다른 이들이 염려하는 형식적이고, 피할 수 없고 제어되지 않는 문제를 극복할 수 있다.

테스팅 프로젝트 내에서 만들어지는 세번째 위험 요소는 다양한 원인을 가지고 있지만 모든 것은 테스트 매니저의 판단 범위 내에 있다.(테스트 매니저가 제거할 수 있다고 말하지 않는) 프로젝트나 실제 모든 종류의 관리 업무는 의사 결정으로 부터 발생할 수 있는 위험을 제어하는 것이다. 테스팅 프로젝트가 의사 결정이 많기 때문에, 특히 위의 내용이 적용된다. 어떤 의사 결정은 첫째 카테고리인 '앞으로의 위험'을 발생시킨다. 예를 들어, 우리는 무엇을 테스트 할지, 어떻게 테스트 할지만 결정해야 하는 것은 아니며 무엇을 가장 먼저 테스트해야 할지도 결정해야 한다. 위험 요소가 존재하기 때문에, 시간이 부족한 경우 무엇이 충분히 테스트 되어야 할까?
그런 다음에 어떻게 그것을 알 수 있을까? 이 모듈이나 하부 시스템을 테스트 하지 않았을 때 발생할 수 있는 내재된 결과를 이해할 수 있을까? 결과를 분석하지 못하는 테스트 매니저는 안에 들어 있는 위험 요소를 알기 위해 솔직하게 요구할 수 없으며, 그녀의 결정에 대해서도 확신하지 못하게 된다.

작업 스케쥴에 관련된 또 다른 결정은 세번째 카테고리 유형의 위험 요소를 테스팅 프로젝트 그 자체에 발생시킨다. 예를 들어, 하부 시스템 테스팅에 허용된 시간이 어느 정도인지 알려면 어떻게 해야 하는가? 첫번째 어림 짐작은 테스트 계획을 수행하는데 얼마나 오래 또는 얼마나 많은 맨아워가 필요한지 추정하게 한다.
하지만 이것은 최소한의 허용치이다. 어쨋든 테스트 매니저가 대략적인 추정을 해서 얼마나 확신하게 될까? 이것이 '교육된' 추정일까? 유사한 하부 시스템을 테스트한 경험에서 나온 것일까? 업무를 할당 받은 테스트의 지식을 근거로 한 추정일까? 만일 낙관적인 추정이고 경험이 없는 테스트가 일을 맡았다면, 스케쥴에 차질이 생기는 것은 거의 필연적인 결과이다. 재 테스트에 들어가는 시간과 리소스의 스케쥴링은 또 다른 문제가 되거나 위험한 결정을 수반한다. 만일 이러한 일이 개발팀에게 달려 있다면, 우리는 어떻게 알 수 있을까? 만일 개발 매니저가 경험이 없거나 문제가 있는 디자이너나 프로그래머를 수정 작업에 투입하거나, 관리를 소홀히 하거나, 검증 하는데 실패한다면, 재 테스트는 더 늘어나거나 반복되어야 할 것이다. 이렇게 될 가능성이 얼마나 되나? 만약 테스트 매니저가 그녀의 팀 내부에만 이 내용을 언급하는 것이 아니라 개발 매니저에게도 한다면 위험을 피할 수는 없지만 감소시킬 수는 있다.

다음으로 우연적으로 발생하는 일이 있다. 얼마나 많은 테스트 팀의 인원과 리소스가 투입될 수 있을까? 너무나 많이 투입되는 경우 테스트 예산이 불필요하게, 불확실하게 , 턱없이 증가될 것이다. 너무 적게 투입되는 경우 소소한 지연이 쌓이게 되어 프로젝트가 범위를 넘어서거나 테스트가 충분치 않게되고, 테스트의 목표에 부합하지 못하게 된다. 앞으로 발생할 수 있는 우연성 요구를 정확하게 예측하는 것은 가능하지 않지만 테스트 매니저는 위험 요소와 의사 결정의 균형을 맞추기 위해 질문의 양쪽 면에서 부터 증거를 모아야 할 필요가 있다. 테스트 매니저에게 있어서 결정은 업무와 재앙 양쪽 모두에 해당된다.

일반적으로 소프트웨어 개발 프로젝트는 문제가 많으며, 그 안에 속한 테스트 프로젝트는 특별히 더 그렇다. 현실적인 주요한 원인은 프로젝트 관리가 조악하다는 사실이 종종 간과된다. 우리의 타성은 지연과 비효율이 더 낫게 만들수도 있었던 결정의 결과로 생각하기 보다는 오히려 '당신이 예상하지 못했던" 것으로 치부되는 경우가 많다. 모든 결정은 위험이 수반되고, 의사결정은 진보된 정보를 수집해서 내려지고, 위험을 평가해서 지원되어야 한다. 그리고, 적절한 시점에서 위험 관리 활동에 의해 보호되어야 한다. 간단한 상황에서는 직관(감)에 의한 통찰이 충분하지만 많은 프로젝트의 상황에서는 위험 분석과 관리에 대한 이해를 필요로 한다.

테스트 매니저의 결정은 테스트 프로젝트의 성공에 결정적이다. 그들은 시스템의 운영에만 영향을 미치지 않고 테스트 팀의 능률과 효율에도 영향을 미친다. 부장 관리자가 재능있고 적합한 테스트 매니저 임명과 적시에 제공되고 충분히 지원되는 중요성에 대해서 알고 있는가? 그들이 내린 선택이 테스팅 프로젝트에 대단히 큰 위험을 가져 올 수 있는 결정일 수 있다는 사실을 인식하고 있는가? - PT -

반응형

관련글 더보기

댓글 영역