여러분이 테스팅의 어느 단계에서 다음 단계로 통과할 때 관리가 필요하다. 이 포스트의 목적을 달성하기 위해, 우리는 공급자로써 이전 단계와 고객으로써의 현재 단계를 언급할 것이다. 공급자는 그것이 출시 준비가 된 것으로 간주될 시기까지 그들의 테스팅 단계 관리를 지속해야 할 필요가 있다. 고객은 공급자에 의해 수행된 테스팅이 만족할 수 있을 정도로 충분히 높은 표준으로 달성되었음을 보장받고 싶어한다.
이를 달성하기 위한 수단들이 공급자에게는 종료 기준, 그리고 고객에게는 시작 기준으로써 언급된다. 그런 기준들은 테스트 플랜에 문서화되고 그 문서에 의해 설명된 테스트 단계에 진입하고 빠져나오는데 수행되어야 될 규범들을 규정한다.
그 기준은 테스트 매니저나 지목된 후보자들에 의해 규정된다. 비록 특정한 심각성과 우선순위를 가진 결함의 양에 더 많은 기반을 두고 있지만, 그것들은 공급자로부터의 테스트 자산에 추가적으로 테스트 매니저가 필요하다고 간주하는 어떤 형태를 취할 것이다.
특정한 프로젝트 팀들, 개발 대행업체 등을 다루는 경험들을 이끌어내는 데 있어 다른 정보의 활용에는 심사숙고가 필요하다. 이것은 테스트 매니저가 프로젝트의 순수한 테스팅의 측면 외에 다른 것들을 생각하고 그것에 영향을 줄 수 있는 다른 것들을 보고 이해할 수 있어야 함을 필요로 한다. 테스트 매니저의 본질에 더 접근하자면, 테스트 환경과 형상관리 같은 주제들이다. 환경은 테스팅의 원동력 중 하나이며 테스트 실행 개시 2주 이전에 가용할 수 있어야 한다. 광범위한 형상관리 없이는 개발에서 잘 관리된 산출물이 테스팅으로 전달될 가능성이 현저하게 낮아진다. 그런 이벤트들과 의존성들은 훌륭한 기준을 만들고 그 다음에 오는 테스팅 단계에 진입하지 않는 것에 대한 온당한 이유가 된다.
테스팅 구성요소만 볼 때, 테스트 매니저들이 각 테스팅 단계의 공급자가 연관된 테스트 자산의 생산에 대한 책임을 가지고 있다는 것을 확실히 해둬야 한다. 결함의 양은 자주 논란의 일부분으로 간주된다. 테스트 매니저들은 완전 무결을 보증하는 언급을 하거나 잣대를 너무 높이 설정하여 진입 또는 종료 기준을 성취할 수 없게 만드는 것을 피해야 한다. 그것들이 비현실적이라는 이유로 그런 기준을 느슨하게 하는 것은 테스팅 목적의 무결성을 부패시키고 테스트 매니저의 신용도를 깍아먹는다. 그런 기준들을 정할 때, 그들이 회사의 주주가 되는 것을 보장하는 프로젝트 매니저와 함께 작업하고, 문서상의 서명에만 의존하지마라. 이것은 더 높은 수준의 매입을 일으키고, 향후 기준에 대한 어떤 변경이 테스트 매니저와 프로젝트 매니저 모두를 통해 엄수될 것을 보장한다. 언제나 그런 변경들이 정식으로 관리된 변경임을 확실히 하라.
시작 단계에서 한꺼번에 크게 통합될 때, 가장 높은 우선순위나 심각성을 가진 눈에 드러나는 결함들이 없는 것이 권장된다. 이것은 결함이 전혀 없어야 한다는 것을 말하는 것이 아니라, 가장 높은 우선순위를 정당화하는데 있어서, 비스니스에 매우 중요한 항목들만이 우선순위로써 결정되어야 한다는 것을 말한다. 가장 높은 심각성을 가진 결함들은 아마도 더 논란이 될 뿐만 아니라 높은 심각성을 가진 결함들을 가진 항목이 전달되는 것은 테스팅의 기본요소들이 완료될 수 없음을 말하고 산출물이 명시되고 예상되었던 기능의 수준에 훨씬 못 미친다는 의미이다.
만일 주변 상황이 시작 또는 종료 조건을 뒤바꿀 것을 강요한다면, 최소한의 위험 저항자는 그 영향과 완화를 위한 조치들을 세분화하고 발생한 이를 반영하기 위해 갱신될 필요가 있다. 이것은 문제에 봉착하고, 현재 일정이 아주 촉박한 프로젝트에 대한 일반적인 직설법임을 인지할 필요가 있다.
Grant Obermaier |
|
번역: 본인
원문 출처: 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