'exit criteria'에 해당하는 글 2건

 본 게시물의 목적달성을 위해 우리에게 insignificant(하찮은), minor(중요하지 않은), significant(의미있는), major(중대한) 그리고 critical(치명적인) 의 5가지 결함 등급이 주어졌다고 가정하자.
우리가 프로젝트의 한 단계를 종료하고 다음 단계로 접어들 때, 우리는 테스트 매니저에 의해 설정되는 기준을 인지할 필요가 있으며 이것이 꼭 수반되어야 한다. 보통 한 단계의 종료 기준이 다음 단계를 위한 시작기준이 된다. 예를 들면 대규모의 통합 테스트에서 테스트 매니저는 그 자신만의 시작기준을 정의할 것이며 기본적으로 이것이 이전단계에 대한 종료기준이 되는 것이다. 이는 제품의 출시 시점에서 이상적인 수단이 된다.

내가 강조하고 싶은 것은 두 가지 핵심 요소이다. 출시 시점에 남아있는 결함이 하나도 없을 것이라고 말하는 테스트 매니저는 마치공상의 세계에서 살고 있는 것과 같다. 이것은 평생 테스트 할 수 있기를 바라고, 완벽한 코드를 출시하고자 하는 테스트 매니저이다. 이는 현실적으로 불가능한 일이다. 비즈니스의 현실은 프로젝트를 착수하고, 사업 요구사항을 만족시키며, 첫번째 예시에서 프로젝트를 정당화하기 위해 사용된 비즈니스 혜택들을 제공하기 위해 어느 정도의 리스크는 수용될 수 있는 것이다. 


그래서 다음 질문은 리스크의 수준과 수용될 수 있는 것이 무엇인가이다. 이는 프로젝트의 특성에 따라 좌우될 것이다. 안전과 밀접하게 연관된 어플리케이션을 포함하는 것은 소규모 비즈니스에서 두 사람에 의해 사용되는 것 보다는 훨씬 더 높은 수준의 품질 요구사항을 가질 것이다. 일반대중이나 많은 고객들에게 노출되는 것 역시 내부적으로만 사용되는 것 보다 훨씬 더 높은 품질을 보장할 필요가 있을 것이다. 테스트 매니저의 능력은 어플리케이션의 사용 목적을 평가하는 것이며 허용할 수 있는 결함의 수준을 정의하는 것이다. 시작, 종료기준을 언급한 문서(http://tcl-india.blogspot.com/2008/06/entry-and-exit-criteria.html)에서 이전에 정의한 것처럼 프로젝트 후반에 지원을 보장하기 위해 프로젝트 매니저가 그런 단계들이 실행될 수 있도록 해야한다.

지금 당장 우리는 수용될 수 있는 결함들을 살펴봐야 한다. 일반적인 오해는 치명적인 결함이 우선순위나 심각성이 '0' 인 수준을 확인하는 것이지만, 사소한 결함의 수준에 대한 제한이란 존재하지 않는다. 이는 현실에서 그대로 드러난다. 하나의 사소한 결함이 출시를 가로막지는 않지만, 다수의 사소한 결함들이 어플리케이션의 출시를 허락하지 않을 수 있다.

나는 우리가 일단 결함의 심각성에 집중하기를 제안한다. 우리는 다수의 insignificant 가 하나의 minor 와 같고, 다수의 minor 가 하나의 significant 와 같다는 식으로 비례적으로 이해할 필요가 있다. 이는 어플리케이션의 용도에 따라 바뀔 수 있다. 그래서 각기 다른 어플리케이션 유형에 대한 몇가지 제안을 제시한다.

안전과 밀접한 어플리케이션
Proportions: 1 Critical = 2 Severe : 1 Severe = 3 Significant : 1 Significant = 5 Minor : 1 Minor = 10 Insignificant
Final Exit Criteria: 0 Critical : 0 Severe : 0 Significant : 5 Minor : 10 Insignificant


일반적인 상용 어플리케이션
Proportions: 1 Critical = 3 Severe : 1 Severe = 5 Significant : 1 Significant = 10 Minor : 1 Minor = 20 Insignificant
Final Exit Criteria: 0 Critical : 0 Severe : 3 Significant : 10 Minor : 20 Insignificant


내부적인 용도로 사용되는 어플리케이션 (20 + Users)
Proportions: 1 Critical = 4 Severe : 1 Severe = 7 Significant : 1 Significant = 15 Minor : 1 Minor = 50 Insignificant
Final Exit Criteria: 0 Critical : 1 Severe : 5 Significant : 10 Minor : 40 Insignificant


내부적인 용도로 사용되는 어플리케이션 (0 to 20 Users)
Proportions: 1 Critical = 5 Severe : 1 Severe = 10 Significant : 1 Significant = 20 Minor : 1 Minor = 100 Insignificant
Final Exit Criteria: 0 Critical : 2 Severe : 5 Significant : 10 Minor : 50 Insignificant


WRITTEN BY
하이런

,

 

 

여러분이 테스팅의 어느 단계에서 다음 단계로 통과할 때 관리가 필요하다. 이 포스트의 목적을 달성하기 위해, 우리는 공급자로써 이전 단계와 고객으로써의 현재 단계를 언급할 것이다. 공급자는 그것이 출시 준비가 된 것으로 간주될 시기까지 그들의 테스팅 단계 관리를 지속해야 할 필요가 있다. 고객은 공급자에 의해 수행된 테스팅이 만족할 수 있을 정도로 충분히 높은 표준으로 달성되었음을 보장받고 싶어한다.

이를 달성하기 위한 수단들이 공급자에게는 종료 기준, 그리고 고객에게는 시작 기준으로써 언급된다. 그런 기준들은 테스트 플랜에 문서화되고 그 문서에 의해 설명된 테스트 단계에 진입하고 빠져나오는데 수행되어야 될 규범들을 규정한다.

그 기준은 테스트 매니저나 지목된 후보자들에 의해 규정된다. 비록 특정한 심각성과 우선순위를 가진 결함의 양에 더 많은 기반을 두고 있지만, 그것들은 공급자로부터의 테스트 자산에 추가적으로 테스트 매니저가 필요하다고 간주하는 어떤 형태를 취할 것이다.

특정한 프로젝트 팀들, 개발 대행업체 등을 다루는 경험들을 이끌어내는 데 있어 다른 정보의 활용에는 심사숙고가 필요하다. 이것은 테스트 매니저가 프로젝트의 순수한 테스팅의 측면 외에 다른 것들을 생각하고 그것에 영향을 줄 수 있는 다른 것들을 보고 이해할 수 있어야 함을 필요로 한다. 테스트 매니저의 본질에 더 접근하자면, 테스트 환경과 형상관리 같은 주제들이다. 환경은 테스팅의 원동력 중 하나이며 테스트 실행 개시 2주 이전에 가용할 수 있어야 한다. 광범위한 형상관리 없이는 개발에서 잘 관리된 산출물이 테스팅으로 전달될 가능성이 현저하게 낮아진다. 그런 이벤트들과 의존성들은 훌륭한 기준을 만들고 그 다음에 오는 테스팅 단계에 진입하지 않는 것에 대한 온당한 이유가 된다.

테스팅 구성요소만 볼 때, 테스트 매니저들이 각 테스팅 단계의 공급자가 연관된 테스트 자산의 생산에 대한 책임을 가지고 있다는 것을 확실히 해둬야 한다. 결함의 양은 자주 논란의 일부분으로 간주된다. 테스트 매니저들은 완전 무결을 보증하는 언급을 하거나 잣대를 너무 높이 설정하여 진입 또는 종료 기준을 성취할 수 없게 만드는 것을 피해야 한다. 그것들이 비현실적이라는 이유로 그런 기준을 느슨하게 하는 것은 테스팅 목적의 무결성을 부패시키고 테스트 매니저의 신용도를 깍아먹는다. 그런 기준들을 정할 때, 그들이 회사의 주주가 되는 것을 보장하는 프로젝트 매니저와 함께 작업하고, 문서상의 서명에만 의존하지마라. 이것은 더 높은 수준의 매입을 일으키고, 향후 기준에 대한 어떤 변경이 테스트 매니저와 프로젝트 매니저 모두를 통해 엄수될 것을 보장한다. 언제나 그런 변경들이 정식으로 관리된 변경임을 확실히 하라.

시작 단계에서 한꺼번에 크게 통합될 때, 가장 높은 우선순위나 심각성을 가진 눈에 드러나는 결함들이 없는 것이 권장된다. 이것은 결함이 전혀 없어야 한다는 것을 말하는 것이 아니라, 가장 높은 우선순위를 정당화하는데 있어서, 비스니스에 매우 중요한 항목들만이 우선순위로써 결정되어야 한다는 것을 말한다. 가장 높은 심각성을 가진 결함들은 아마도 더 논란이 될 뿐만 아니라 높은 심각성을 가진 결함들을 가진 항목이 전달되는 것은 테스팅의 기본요소들이 완료될 수 없음을 말하고 산출물이 명시되고 예상되었던 기능의 수준에 훨씬 못 미친다는 의미이다.

만일 주변 상황이 시작 또는 종료 조건을 뒤바꿀 것을 강요한다면, 최소한의 위험 저항자는 그 영향과 완화를 위한 조치들을 세분화하고 발생한 이를 반영하기 위해 갱신될 필요가 있다. 이것은 문제에 봉착하고, 현재 일정이 아주 촉박한 프로젝트에 대한 일반적인 직설법임을 인지할 필요가 있다. 

 

Grant Obermaier
Transition Consulting Limited - India

 


 

번역: 본인
원문 출처: http://ezinearticles.com/?Entry-and-Exit-Criteria&id=1282644

'IT와 생활' 카테고리의 다른 글

entry criteria vs exit criteria  (0) 2008.11.06
Severity Vs Priority  (0) 2008.11.03
Benchmark (벤치마크)  (0) 2008.10.30
Overview of the TPC Benchmark C  (0) 2008.10.27
What is the TPC  (0) 2008.10.27

WRITTEN BY
하이런

,