[Study] CSTS 5장 - 위험 기반 테스트

일반적으로 테스트에 시간과 비용을

많이 투입할수록 더욱 많이 결함을 검출할 수 있고,

품질에 관해 확인된 결과의 정확성은 더 높아질 수 있다.

 

그러나 소프트웨어 프로젝트처럼 테스트는 주어진 비용,

일정 현실적으로 주어진 자원이라는

제약 내 테스트 목적을 달성해야 한다.

그리고

주어진 비용, 일정은 테스트 전략을 선택할 때뿐 아닌

테스트 범위를 결정할 때도 고려사항이 된다.

 

자세히 말해 테스트 비용의 범위 내 컴포넌트 테스트,

통합 테스트 및 시스템 테스트의 수행 강도를 결정하고

컴포넌트 테스트를 수행할 대상이 되는 모듈도 결정할 수 있다.

그리고

시스템 테스트를 수행할 때

테스트 할 기능 및 비기능적 특성 쉽게 말해

테스트 하고자 하는 피처를 한정할 수도 있다.

 

테스트 대상을 결정하고

선택된 테스트 범위를 전체 시스템 일부로 한정하면,

테스트 비용을 줄일 수 있는데, 테스트 안된 부분에서

장애가 발생할 가능성이 있으니까

결국에 소프트웨어 품질에 악영향을 미칠 수 있다.

따라서

테스트 대상과 범위를 결정할 때는

테스트를 수행하지 않음으로 발생할 위험도 고려해야 한다.

쉽게 말해서 테스트를 안 했어도 그에 따른 위험 수준이 낮은 것들은

테스트 대상에서 제외될 수 있지만,

테스트 제외에 따른 위험 수준이 높은 것은

테스트 대상에 포함되어야 한다.

---

위험 분석

위험 요소 식별

위험 분석 기반 테스트를 수행할 때

계회 수립의 시작은 우선 테스트가 필요한

피처들을 모두 나열하는 것이다.

 

쉽게 말해 테스트 범위로 기술되는

시스템의 기능 및 비기능적 모든 요소를 나열하는 것이다.

그렇게 나열된 피처는

이후 수행 되는 위험 분석의 대상이 되며

위험 분석 결과에 따라 테스트 계획이 수립된다.

 

피처

소프트웨어 요구사항 명세서를 바탕으로 구한다.

요구사항 명세서는 시스템에 요구되는

기능적 측면과 성능, 신뢰도, 가용성, 보안성 등과 같은

비기능적 측면의 요구사항을 담고 있다.

 

요구사항 명세서

테스트를 수행할 때 기준으로 삼는 가장 중요한 문서이니

이 문서에 나열된 요구사항들을 우선 피처로 사용할 수 있다.

시스템 유형에 따라 강조되는 품질 요소가 다를 수 있다.

ex)

많은 수의 사용자 또는 클라이언트 시스템을 지원해야 하는

서버 또는 미들웨어 시스템이라면

사용자 및 클라이언트 시스템 수가 증가해도

적절한 수준의 성능을 제공할 수 있어야 하는

확장성이 일반적으로 요구되는 품질 요소일 것이다.

 

그리고 충분하지 않은 컴퓨팅 성능을 가진 장치에서

일반적으로 수행되는 임베디드 소프트웨어라면

시스템 자원을 매우 효율적으로 활용해야 하는 성능이

중요한 품질 요소가 된다.

또한

주변 장치의 오작동에도 소프트웨어는

적절히 동작해야 하니 신뢰성 및 결함 허용성도

중요한 요소가 될 수 있다.

 

나열되는 피처 후보는 이후의 위험 분석이

가능토록 명확히 구체적으로 기술되어야 한다.

 

계락적, 추상적인 설명은 해당 피처 후보에 대한

발생 가능성, 심각성, 긴급성을 판단하기 어렵기 때문이다.

예로 ATM 시스템에서는 "현금 입출금 기능이 제공된다."라는

현금 입금 기능과 현금 출금 기능으로 세분화될 수 있으며,

입금과 출금 기능에 따라서 장애의 발생 가능성,

장애의 심각성과 처리의 긴급성이 다를 수 있다.

따라서 피처 후보는 발생 가능성, 심각성, 긴급성을

부여할 수 있는 수준으로 구체적으로 상세히 파악되어야 한다.

 

---

위험도 산정

앞서 도출된 각 피처 후보 중

"무엇을 테스트 대상에 포함할 것인가?"에 관한

결정 및 효과적인 테스트 전략의 결정을 위해

위험도를 산정해야 한다.

 

각 피처 후보의 위험도 산정

발생 가능성, 심각성, 긴급성을 바탕으로 수행된다.

위험도 산정의 각 항목 수준은 정략적 분석을

위한 적절한 등급값이 부여될 수 있다.

위험도 산정 항목은 3가지 등급

또는

5가지 등급으로 세분화될 수 있다.

 

방생 가능성은 해당 피처와 관련된 장애가

실행 시 발생할 가능성을 의미한다.

ex)

ATM 시스템에서 "계좌 잔액보다

큰 금액으로 출금 요청 시

잔액 부족 메시지를 출력한다"가

피처 후보라면, 계좌 잔액이 부족한데도

"잔액 부족" 메시지가 출력되지 않고

현금이 출금되는 장애 상황이 발생할

가능성이 조사되어야 한다.

---

장애 발생 가능성

첫 번째

기술적 복잡성측면

쉽게 말해 구현 자체에 복잡성이 많다면

장애 발생 가능성도 클 수 있는 것이다.

 

두 번째

해당피처와 관련된 결함이 소프트웨어 개발 공정에서

검출되어 제거될 수 있는지 고려할 필요가 있다.

 

쉽게 말해 해당 결함이 상세설계 명세서 또는

코드리뷰를 통해 발견되고 제거될 가능성이 크면

동적 테스트 활동에서는 관심을 덜 가져도 될 수 있다.

 

세 번째

사용자가 해당 기능을 사용하는 빈도도

장애 발생 가능성에 영향을 줄 수 있다.

사용자가 빈번히 이용하는 기능일수록

더 자주 관련 장애가 발생할 수 있기 때문이다.

 

발생가능성 등급 예시

등급	설명
1	거의 모든 환경, 사용자, 기능에서 장애가 발생할 수 있음
2	많은 환경, 사용자, 기능에서 장애가 발생할 수 있음
3	일부환경, 사용자, 기능에서 장애가 발생할 수 있음
4	제한된 일부 환경, 사용자, 기능에서 장애가 발생할 수 있음
5	발생 가능성이 작음

(발생 가능성이 가장 큰 경우 1, 가장 작은 경우 5)

 

심각성

관련 장애가 발생했을 때

즉, 피처에 기술된 시스템의 기능 및 비기능적 요소가

기대한 대로 동작하지 않을 때

사용자에게 미치는 영향의 정도를 나타낸다.

 

심각성 등급 예시

등급	설명
1	시스템 데이터의 유실 및 사용자를 잃을 수 있다.
2	시스템 주요 기능이 제한될 수 있다.
3	시스템 주요 기능이 제한되지만, 다른 대안이 있다.
4	주요 하지 않은 기능이 제한될 수 있다.
5	정상적으로 동작은 하나 일부 장애가 있다.

(높은 수준의 심각성이 가장 큰 경우 1, 가장 작은 경우 5)

 

1등급

장애가 발생할 겨우 시스템 주요 데이터와

시스템의 사용자마저 잃을 수 있는 심각한 상황에 해당한다.

 

2등급

1등급보다는 심각한 결과를 초래하지 않지만

시스템 주요 기능이 제공되지 않을 수 있는 상황을 뜻한다.

 

3등급

정상적으로 제공되지 않는 기능을 다른 방식으로

사용할 수 있는 경우에 해당한다.

 

4등급

주요하지 않은 기능에서 발생하는 장애를 뜻한다.

 

5등급

정상적으로 동장하나 사용자 인터페이스

또는

약간의 지체 등과 같이 일부 장애가 있고

개선할 여지가 있는 상황을 뜻한다.

 

긴급성

해당 피처와 관련된 장애가 발생하였을 때

얼마나 시급한 수정이 필요한가를 나타낸다.

 

우선,

많은 사용자가 빈번히 사용하는 기능은

더욱 긴급히 결함을 수정하는 것이 바람직하므로

높은 긴급성 등급을 지정한다.

 

뿐만 아닌,

사용자들이 자주 이용하는 기능은 아니지만

해당 소프트웨어와 관련된 계약 및 법규등의 제약으로

장애 발생 시 즉각 정인 수정이 요구될 수 있다.

따라서 시스템과 관련된 사용자 및 이해당사자를 모두 파악하고

이해당사자별로 시급한 기능/비기능을 조사해

이를 긴급성에 반영하도록 한다.

 

긴급성 등급 예시

등급	설명
1	즉각적인 수정이 필요하다.
2	현재 릴리스에 반드시 수정을 해야한다.
3	수정되지 않으면 시스템이 사용자 및 고객에게 제공하던 가치가 크게 손상된다.
4	예산과 일정이 허용되면 현재 릴리스에서 수정을 한다. 그렇지 않으면 다음 릴리스에서 수정을 한다.
5	향후 릴리스에서 가능하면 수정한다.

 

장애가 발생했을 때

사용자 고객 및 그 외 이해당사자들에게

미칠 영향에 따라 즉각적인 수정이 필요한 1등급,

현재 릴리스에서 반드시 수정을 요하는 2등급,

수정되지 않으면 시스템이 사용자 및 고객에게 제공하던

가치가 크게 손상될 수 있는 3등급,

예산과 일정이 허용되면 이번 릴리스에서 수정을 하고

그렇지 않으면 다음 릴리스로 미루는 4등급과

향후 릴리스에서 가능하면 수정을 하는 5등급으로 분류된다.

 

위험 분석의 예

 

유형	피처	발생 가능성	심각성	긴급성	위험도
기능성	삽입된 카드를 인식한다.	4	2	2	16
	사용자 입력 시간 초과 확인	3	5	4	60
	사용자 입력이 필요할 때마다 취소가 가능함	2	3	1	6
성능	주어진 시간 내에 입금/출금/이체를 수행한다.	3	3	3	27
신뢰성	각종 H/W 장애에도 잔액의 무결성을 유진한다.	2	1	1	2
보안성	일정 횟수 이상의 부정확한 암호 입력을 확인 한다.	4	1	1	4
---	---	---	---	---	---

 

삽입 된 카드를 정확히 인식하지 못하는 것은

일부 ATM 기기에서 발생할 수 있다고 가정을 한다면,

발생 가능성은 4등급에 해당한다.

 

카드가 인식되지 않았을 경우

입금/출금/이체 등과 같은

시스템의 주요 기능이 제공되지 못하니

심각성은 2등급에 해당하고

 

삽입된 카드가 정확히 인식되지 않는다면

해당 ATM 기기를 사용하는 고객을 잃을 가능성이 있으니

현재 릴리스에서 반드시 수정해야 한다.

 

반면, 사용자 암호, 출금/이체 금액 등을 입력할 때

입력 시간 초과를 확인하지 않는 것은

사용자가 지정된 시간 내 입력을 하지 않거나

못하는 상황을 초래할 수 있으니

발생 가능성은 3등급이 될 수 있다.

 

그러나 입력 시간 초과 확인에 장애가 발생해

입력 시간이 초과된 것을 확인하지 않고

계속해서 사용자 입력을 기다리는 상황이 발생해도

입금/출금/이체등의 기능을 사용자가 이용하는 것에

아무런 문제가 발생하지 않는다.

따라서 심각성은 5등급이 될 수 있다.

 

그러나 ATM 사용시간을 제한해 더 많은 고객을

서비스하는 것이 바람직할 수 있으니

예산과 일정이 허용되면 이번 릴리스에서

수정하는 것이 바람직하다.

 

ex)

ATM 시스템에서는 암호 입력, 금액 입력, 계좌번호 입력 등과 같이

사용자 입력이 요구될 때마다 "취소"가 가능해야 한다.

 

"취소" 기능이 필요한 상황이 복잡하여

관련된 코드에 결함이 발생할 가능성이 클 수 있으니

발생 가능성은 2등급이 될 수 있고, 설령 "취소" 기능에

장애가 있더라도 사용자가 실수 없이

암호/금액/계좌번호 등을 정확하게 입력해

"취소" 장애를 회피하거나 일정 시간 동안 입력을 하지 않아서

입력 시간 초과로 취소될 수 있으니 심각성 3등급에 해당된다.

 

"취소" 장애를 회피할 방법은 있지만

적지 않게 불편함을 초래해 고객/사용자를 잃을 위험이 크니

즉각적인 수정이 필요할 수 있다.

보안성 측면 요구사항

일정 횟수 이상의 부정확한 암호 입력인 경우

정상적인 사용자라면 발생 가능성은 크지 않을 수 있지만

만약 이 기능에 장애가 발생하여

여러 회 반복적으로 부정확하게 입력되는 암호를 확인하지 않으면

습득한 카드로 불법적인 출금/이체를 할 수 있으니

심각성은 1등급이 된다.

 

그리고

은행 신용도 및 금전적인 손실을 초래할 수 있으니

즉각적 수정이 필요할 수 있다.

 

피처별로 위 세 가지 요소에 관한 등급을 결정한다.

위의 위험 분석의 예를 보면 발생 가능성,

심각성, 긴급성에 부여될 값을 곱하여

피처별로 위험도를 산출하였는데,

이 위험도 값은 "해당 피처를

얼마나 강도 높게 테스트하는 가?"를

결정하는 기준으로 사용된다.

---

위험 기반 테스트 수행

위험 분석 결과

효과적/효율적인 테스트를 수행하기 위한

계획을 수립할 때 사용된다.

 

쉽게 말해서 주어진 일정과 비용 내에서

중요한 테스트 대상을 결정하고

더욱 집중적으로 테스트할 피처들을 선정하는 데

위험 분석 결과가 사용된다.

위험 분석 기반 테스트 계획

위 위험 분석 기반 테스트 계획을 보면

발생 가능성, 심각성, 긴급성을 바탕으로 결정된

위험도 기반의 테스트 계획 수립 과정을 보여준다.

 

먼저, 산정된 위험도 값을 바탕으로

수행할 테스트의 강도를 결정한다.

 

쉽게 말해서 위험 수준을 바탕으로

해당 피처의 테스트에 투입할 자원과

비용 등을 결정한다.

 

세 가지 위험도 구성 항목은

1~5까지의 값을 가질 수 있으니

위험도는 1~125까지의 값을 가질 수 있다.

 

테스트 관리자

적절한 기준값을 사용해 위험도를 등급화하고

이를 바탕으로 테스트 강도를 결정할 수 있다.

 

아래 그림처럼 세 가지 기준 값을 적절히 선택해 

테스트 강도를 고강도 테스트, 균형적 테스트, 부가적 테스트, 

결함 보고의 4가지 등급으로 분류한 모습을 보여준다.

위험도에 따른 테스트 강도

 

고강도 테스트

매우 높은 위험도를 가지는 피처들은 이 등급으로 분류된다.

쉽게 말해 피처와 관련된 결함의 발생 가능성이 높고,

발생하였을 때 시스템에 심각한 피해를 줄 수 있으며,

즉각적인 수정이 요구되는 결함에 해당되는 피처는

가능한 한 많은 자원을 사용해 높은 강도로 테스트를 수행한다.

 

균형적 테스트

고강도 테스트 보다 낮은 위험도를 가지는

피처들은 균형적 테스트를 적용한다.

균형적 테스트에서는 프로젝트의 주어진 예산과 일정을 고려해

효과적이고 효율적인 테스트를 수행하는 데 초점을 둔다.

테스트예산과 일정에 제한이 있기에 심각성, 긴급성 등을 고려해

테스트 노력을 투입하도록 한다.

 

부가적 테스트

균형적 테스트로 분류되는

피처보다 낮은 위험도를 가지는

피처들은 부가적 테스트로 분류된다.

 

이 등급에 해당하는 결함들은

다른 등급의 결함들을 검출하기 위한 목적으로 수행되는

테스트 활동에 일부 추가적인 작업 - 일부 테스트 케이스의 추가,

일부 테스트 데이터의 추가 등 - 을 수행해 검출을 시도한다. 

 

균형적 테스트와 마찬가지로 예산과 비용이 한정되므로

심각성, 긴급성 등을 고려해 결함을 재연하거나 고립화하도록 한다.

 

결함 보고

가장 낮은 수준의 위험도를 가지는 피처들은

결함 보고 등급으로 분류된다.

테스터는 이 등급에 해당하는 피처들을

테스트 범위에 포함시키지 않는다.

 

쉽게 말해서 이 피처를 대상으로

테스트 설계 및 구현 활동을 수행하거나

테스트 실행 활동을 수행하지는 않는다,

다만, 발견된 결함에 관해 보고를 한다.

 

물론,

결함의 심각성과 긴급성을 고려해

발견 결함의 보고 여부도 결정될 수 있다.

 

위 위험 분석 기반 테스트 계획 그림에서 볼 수 있듯이

위험도를 바탕으로 결정된 테스트 강도 수준은

테스트 계획의 주요 항목에 영향을 줄 수 있다.

 

쉽게 말해 테스트 유형, 테스트 대상,

테스트 범위 등의 테스트 콘텍스트를 설정하거나

테스트 전략을 수립할 때 테스트 강도를 고려한다.

 

쉽게 말해서 테스트 강도가 높으면

테스트 대상과 테스트 범위가 확대되고,

더 높은 수준의 테스트 전략을 사용할 수 있다.

---

테스트 계획

테스트 레벨/유형 결정

테스트 강도

수행할 테스트 레벨 및 유형을 결정할 때 영향을 준다.

예로, 고강도 테스트 및 균형적 테스트로 분류된 피처는

테스트 레벨 전체에 걸쳐서 테스트를 적용해야 한다.

 

쉽게 말해서,

해당 피처와 관련된 모듈들을 파악해

컴포넌트 테스트를 수행하고,

해당 모듈들로 구성된 통합 시나리오에 대해

통합 테스트를 수행한 후 시스템 테스트를 수행한다.

 

만약, 피처가 비기능 유형이면

이 비기능 피처에만 초점을 둔 유형 테스트를

추가로 수행할 수도 있다.

 

예로, 성능 관련 피처가 고강도 테스트 등급으로 분류된다면

컴포넌트 · 통합 · 시스템 테스트에 추가로 성능 테스트를 수행할 수 있다.

 

반면에 부가적 테스트 등급에 해당되는 피처는

컴포넌트 테스트 및 통합 테스트를 수행할 때는

고려하지 않고 시스템 테스트를 수행할 때만 고려할 수도 있다.

 

테스트 대상 선정

위험 분석 결과 및 테스트 강도로

테스트 대상이 선정될 수 있다.

특히 컴포넌트 테스트를 수행할 때

위험 분석 결과를 고려해 테스트 대상이 되는

컴포넌트가 선정될 수 있다.

 

쉽게 말해서

시스템을 구성하는 전체 컴포넌트를 테스트하는 대신

높은 수준의 위험도에 포함되는 피처와

직접적 관련이 있는 컴포넌트를 테스트 대상으로 선정할 수 있다.

 

반대로 말해 위험도가 낮은 부가적 테스트

또는

결함 보고 강도에 해당하는 피처를 구현하는 컴포넌트는

테스트 대상에서 제외하는 것을 고려할 수 있다.

 

마찬가지로 통합 테스트를 수행할 때

위험 분석 결과를 고려해 통합 테스트의 대상에 포함될

컴포넌트 간의 연결을 결정할 수 있다.

 

쉽게 말해서

높은 수준의 위험과 관련된 연결은

통합 테스트 대상에 반드시 포함하도록 하는 반면,

결함 보고 테스트 또는 부가적 테스트 수준으로 분류될 수 있는

낮은 수준의 위험과 관련된 연결은

통합 테스트 대상에서 제외할 수도 있다.

 

테스트 범위 설정

위험 분석 결과

특히 테스트 범위의 결정에 영향을 준다.

예로 높은 수준의 위험도를 가지는 것으로 산정된

쉽게 말해 고강도 테스트로 분류된 피처는

가용한 모든 예산 범위 내에서

최대한 테스트 범위에 포함시킨다.

 

그리고 균형적 테스트로 분류된 피처는

예산을 고려해 테스트 범위에 포함할 것인지 결정한다.

 

반면, 부가적 테스트로 분류된 피처는

명시적으로 테스트 범위에 포함되지 않지만,

테스트를 실행할 때 타 테스트 케이스 및

테스트 절차를 활용해 테스트한다.

 

결함 보고 테스트로 분류된 피처는

테스트 범위에 포함되지 않으며

테스트 실행 활동에서도

이 피처에 특별한 노력은 하지 않는다.

 

테스트 전략

위험 수준이 높은수록 엄격한 테스트를 진행해야 한다.

쉽게 말해 테스트 전략을 더욱 엄격히 적용해

더 많은 결함을 검출해야 한다.

 

특히,

테스트 설계 기법, 테스트 종료 기준,

재테스팅 및 리그레션 테스팅 방법을 결정할 때

위험 수준을 고려해 결정하도록 한다.

 

테스트 설계 기법

위험 수준이 높은 피처

더 강도 높은 테스트 설계 기법을 적용한다.

예로 고강도 테스트로 분류된 피처는 동등 분할보다

높은 강도의 경곗값 분석 기법을 적용할 수 있다.

 

구조 기반 테스트 설계 기법을 적용할 때도

위험 수준을 고려해 위험 수준이 높은 피처는

더 강도 높은 테스트 방법을 적용한다.

 

예로 위험 수준이 높은 피처를 구현하는 컴포넌트는

문장 테스트 보다 결정 테스트를 결정 테스트보다는

결정/조건 테스트를 결정/조건 테스트보다는

MCDC를 적용할 수 있다.

 

테스트 완료 기준

위험 수준이 높은 피처를 구현하는 컴포넌트는

타 컴포넌트에 비해 상대적으로

높은 수준의 테스트 완료 기준을 적용할 수 있다.

 

예로 위험 수준 이 낮으면 결정 커버리지 80%를 완료 기준으로 하나

위험 수준이 높으면 결정 커버리지 95%를 완료 기준으로 할 수 있다.

 

그뿐 아닌 여러 가지 유형의 완료 기준을

함께 적용해 테스트 완료 기준을 강화할 수도 있다.

 

예를 들어,

테스트 케이스 실행률이 95% 이상이면서

결정 커버리지를  95% 충족해야 하고

동시에 2개 이하의 결함만을 허용하는

테스트 완료 기준을 사용할 수 있다.

 

결함 탐지 기반 방법, 복수 테스트 팀 기반 방법, 신뢰도

예측 모델 기반 방법 등의 분석적 방법을

추가로 적용해 테스트 완료 기준을 설정할 수도 있다.

 

재테스팅과 리그레션 테스팅

위험 수준

재테스팅과 리그레션 테스팅을 수행할 때도 고려될 수 있다.

 

쉽게 말해서

발견된 결함을 개발자가 올바르게 해결하였는지

검증하기 위해 재테스팅을 수행할 때

검출 결함과 관련된 피처의 위험 수준을 고려할 수 있다.

 

예를 들어,

위험 수준이 낮은 피처에 대한 결함이었다면

시간과 비용을 고려해 컴포넌트 레벨의 재테스팅을 생략하고

시스템 테스트에서만 재테스팅을 수행할 수도 있다.

 

마찬가지로 리그레션 테스팅을 수행할 때도

위험 수준을 고려할 수 있다.

 

예를 들어,

위험 수준이 낮은 피처를 변경할 경우

컴포넌트 테스트에서 리그레션 테스팅을 생략하고

시스템 테스트에서만 리그레션 테스트를 수행할 수 있다.

 

위험 수준이 높은 피처

Retest-all 전략을 적용하고 위험 수준이 낮다면

선택적 리그레션 테스트 전략, 테스트 퇴소화 전략,

그리고 테스트 우선 순위화 전략을 적용할 수 있다.

---

테스트 설계/구현 및 테스트 환경

테스트 설계 및 구현 활동에서 각 피처를

세부 피처로 구체화하고 피처 집합별로

테스트 전략을 수립할 때 위험 수준이 고려될 수 있다.

그리고 테스트 환경 구축 활동에서는

위험 수준을 고려해 테스트 환경을 구축하고

테스트 데이터를 준비할 수 있다.

 

피처 구체화 및 테스트 전략 구체화

테스트 설계를 수행하면서 높은 위험도를 가진 피처는

더욱 세밀히 피처를 구체화해 많은 테스트 케이스를 설계하므로

더 깊이 있는 테스트가 수행될 수 있도록 한다.

 

그리고 테스트 전략을 구체화하면서 위험 수준을 고려한다.

높은 위험 수준의 피처를 많이 가진 피처 집합은

더 강도 높은 방식으로 테스트 설계 전략을 구체화한다.

 

예를 들어,

위험 수준이 높은 피처는 경곗값 분석을 적용할 때

2-value 경곗값 보다 3-value 경곗값을 적용할 수 있다.

그리고 만약 상태 전이 테스트를 적용한다면

상태 테스트보다는 단일 전이 테스트를

그리고 단일 전이 테스트보다는

다중 전이 테스트 방법을 적용할 수 있다.

 

우선순위

위험 수준을 참고해 피처 집합, 테스트 케이스,

그리고 테스트 절차의 우선순위를 결정한다.

쉽게 말해서 위험 수준이 높은 피처들을 가진

피처 집합에 높은 우선순위를 부여한다.

그리고

위험 수준이 높은 피처를 세분화해

개발된 테스트 케이스와 테스트 절차에

높은 우선순위를 부여하도록 한다.

 

테스트 환경 요건 및 구축

위험 수준이 높은 피처는 별도로

테스트 환경을 구축할 수 있다.

 

예를 들어서,

인수 테스트뿐 아닌 통합테스트, 시스템 테스트에서도

테스트 환경을 가능한 한 운영 환경과 유사하도록 구축하므로

테스트 환경과 운영환경의 차이 때문에 발생할 수 있는

테스트 자체의 오류를 최소화할 수 있다.

 

테스트 데이터 요건 및 준비

위험 수준이 높은 피처를 테스트할 때는

테스트 설계 기법에 따라 생성된 테스트 데이터뿐 아닌

실제 사용 환경에서 수집된 테스트 데이터를 적용하므로

실제 운영 상황과 더욱 비슷한 환경으로 구축할 수 있다.

그리고

테스트 자동화 도구를 적용해

동일한 시간이라도 더 많은 테스트를 수행할 수 있다.

---

테스트 실행 및 결함 보고

위험 분석 결과

테스트 실행 활동 및 결함 보고 활동에서 고려된다.

쉽게 말해서

위험 수준이 높은 피처와 관련된

테스트를 우선 수행하는 것이다.

그리고

위험 수준이 높은 피처에 실시된 테스트에서 검출된 결함은

높은 심각도와 우선순위로 보고해서

더욱 신속히 해결하고 엄격히 재테스팅을 수행한다.

 

테스트 절차 선택

위험 수준이 높은 피처에 대한 테스트를 먼저 수행한다.

그리고

테스트 설계 및 구현 활동에서 개발된

수많은 테스트 절차 중에서

위험 수준이 높은 테스트 절차를 우선 선택한다.

위험 수준이 피처 집합, 테스트 케이스,

그리고

테스트 절차에 반영되었다면,

우선순위가 높은 테스트 절차를 선정하는 것은

위험 수준이 높은 피처에 대한 테스트 실행을 우선한다고 볼 수 있다.

 

결함 기록

위험 수준은 검출된 결함에 대한 보고에도 고려된다.

위험 수준이 높은 피처에 대한 테스트 절차를 실행해

검출된 결함은 상대적으로 심각하고 긴급한 해결이 필요할 가능성이 크다

쉽게 말해서

검출된 결함에 대한 보고를 할 때 위험 수준은

결함의 심각도와 수선순위에 반영될 수 있다.

 

결함 추적

위험 수준은 보고된 결함에 대한 해결과

종결까지의 과정에서 고려된다.

예를 들어서 위험 수준이 높은 피처에 대해 검출된 결함은

위험 수준이 낮은 피처에 대해 검출된 결함보다

우선시하여 해결하도록 한다.

 

또한

우선순위가 높은 피처의 결함은 재테스팅을 수행하여

결함이 올바르게 수정되었는지 확인하는 반면에 위험 수준이 낮은 경우에는

생략되거나 시스템 테스트 레벨에서만 재테스팅이 수행될 수도 있다.

---

테스트 모니터링/제어 및 테스트 종료

위험 분석 결과는 테스트 모니터링 및 제어 활동과

테스트 종료 활동에서도 고려된다.

 

쉽게 말해서

위험 수준이 높은 피처의 관련 테스트에 관해

더욱 자세히 모니터링을 수색하고

신속히 제어 활동을 수행하는 것이다.

그리고

위험 수준이 높은 피처들에 대한 테스트 결과를

별도로 정리할 수도 있다.

 

테스트 모니터링 및 테스트 활동 제어

위험 수준은 테스트 진행에 대한 현황 보고에도 고려된다.

쉽게 말해서

위험 수준이 높은 피처들에 대한 테스트 진행은

별도의 현황보고로 더욱 세밀히 진행될 수 있다.

 

예를 들어,

위험 수준이 높은 피처에 대해

테스트 절차 및 테스트 케이스 실행률, 통과된 테스트 절차 및

테스트 케이스 비율 등의 테스트 실행 유형에 대한 모니터링뿐 아닌

요구 사항 커버리지, 설계 커버리지, 코드 커버리지 등의

커버리지 유형에 대한 모니터링도 수행할 수 있다.

또한

검출 결함 수, 상태별 결함 수, 결함 나이 등의

결함 유형에 대한 모니터링도 수행할 수 있다.

위험 수준이 높은 피처들에 대한 테스트 모니터링을

더욱 빈번히 수행하게 되면 이를 바탕으로 테스트 활동에

변경이 필요할 때 이를 신속히 적용할 수 있다.

 

테스트 종료 보고

위험 수준이 높은 피처들에 대한

테스트 종료 보고는 별도로 진행할 수 있다.

쉽게 말해서

위험 수준이 높은 피처들과 관련된 테스트 실행 결과를

위험 수준이 낮은 피처들의 테스트 실행과 구분해서

보고서를 작성할 수 있다.

위험 수준이 높은 피처들에 대한 테스트 결과로써

특히 테스트 메트릭, 결함 목록, 잔존 위험,

테스트 완료 평가등을 별도로 보고할 수 있다.