'심각성'에 해당하는 글 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
하이런

,

Severity Vs Priority

IT와 생활 2008. 11. 3. 10:12

결함이 발견될 때, 테스터 그리고 다른 사람들에게도 마찬가지로 생기는 공통적인 혼란이 생긴다. 결함의 심각성과 우선순위에 어떤 차이가 있단말인가?

우선 사전에 나와있는 정의를 살펴보는 것부터 시작해보자.

심각성 - 매우 큰 고통, 난관, 화, 손해 등을 야기하는 것
우선순위 - 매우 중요하고 다른 것들보다 먼저 다뤄져야만 하는 어떤 것

우린 두 단어가 완전히 다른 의미를 가지고 있음을 알 수 있다. 그런데 왜 그 둘 사이에 혼란이 있는 것일까?

심각성은 테스터의 도메인이고 테스터는 이것을 기록할 수 있어야 한다. 테스터에게 심각성이란 그 어플리케이션과 테스트를 지속할 수 있는 가능성에 대한 결함의 영향력을 말한다. 우선순위는 비즈니스 도메인이며 그들(개발자)에게 수정의 중요성을 보여주기 위해 제기된 결함들에 각각에 대하여 그들(개발자)에 의해 직접 입력되어져야 한다.

예를 들면, 맞춤법 오류는 테스터에겐 낮은 심각성으로 간주될 수 있다. 하지만 이 실수가 회사 이름이나 주소에서 발생한다면, 이것은 비즈니스 측면으로써 높은 우선순위로 분류될 것이다. 거의 사용되지 않는 메뉴 옵션에 접근 불가능은 비즈니스 관점에서 낮은 우선순위가 될 수 있다. 하지만 그 옵션에 대한 접근에 연관된 모든 일련의 테스트가 수행될 수 없을 때 그 심각성은 높을 것이다.

우리가 여러 차례 보아왔던 실수는 테스터가 우선순위 또한 기록할 수 있어야 한다고 가정하는 것이다. 테스터가 잘 훈련받은 추정을 할 가능성이 있을지라도, 우선순위는 제품이 출시되기 이전에 고쳐져야 할 것이 무엇인지 그리고 결함 수정에 적용되어야 할 노력의 순서를 규정하는 비즈니스 수단이다. 일정 기간동안 한정된 어플리케이션에 관여하는 테스터들은 이것이 가능할지도 모른다. 하지만 결함 라이프 사이클과 결함 관리 프로세스에서 그 프로젝트와 그것들의 연관성에 대한 적절한 비즈니스 관점의 설명을 하는 것이 필수적이다.

프로젝트에서 테스트를 수행할 때, 초점은 가장 높은 우선순위를 가진 결함을 수정하는데 있을 것이다. 이는 미해결된 낮은 우선순위를 갖는 결함을 안고 어플리케이션이 출시될 것이라는 것을 의미한다. 우선순위가 가장 중요하다고 해서 심각성이 무시되지 않도록 보장하기 위해 프로젝트 매니저에 의한 주의가 필요하다. 필요한 것은 비즈니스 우선순위를 고려하는 균형있는 접근방식이다. 프로젝트 말기에는 높은 심각성과 높은 우선순위를 가진 결함들의 양이 최소한도로 줄여져야한다..

요약:
우선순위 = 비즈니스 = 수정의 순서
심각성 = 테스터 = 어플리케이션의 실패

 

 

번역: 본인(fromatoz)
원문 링크: http://ezinearticles.com/?Severity-Vs-Priority&id=1251817
 

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

S/W 벤치마크테스트 평가모델 개발 이슈  (0) 2008.12.12
entry criteria vs exit criteria  (0) 2008.11.06
Entry and Exit Criteria  (0) 2008.11.03
Benchmark (벤치마크)  (0) 2008.10.30
Overview of the TPC Benchmark C  (0) 2008.10.27

WRITTEN BY
하이런

,