리스크 기반 테스팅 - Part 2

3.9.4 리스크 완화 혹은 리스크 제어(Risk Mitigation or Risk Control)

이미 리스크를 식별하고 그것을 평가했다면, 그 리스크들을 제어해야 할 것이다. 앞서도 언급했듯이, 어드밴스드 실라버스에서는 이를 리스크 완화(Risk Mitigation)라고 칭하고 있는데, 이는 정확한 표현이 아니다. 우리는 아래와 같은 4가지 방법을 통해 리스크를 제어할 수 있다.

 

■ 완화(Mitigation). 리스크가 발생할 가능성과 그로 인해 발생하는 영향을 줄이기 위해 취하는 예방 조치(Preventive measure)

■ 비상계획(Contingency). 리스크가 발생했을 때의 영향을 줄이기 위해 우리가 가지고 있는 계획 혹은 다중의 계획들.

■ 전이(Transference). 발생하는 리스크의 결과를 수용할 다른 그룹을 가지고 있을 때.

■ 마지막으로, 리스크와 이로 인해 발생할 결과를 무시(Ignoring)하거나 수용(Acceptance)함.

 

모든 리스크 아이템에 대해 이 중 하나 이상의 선택 사항이 결정되어야 한다. 이로 인해 이득이 발생하거나 기회(Opportunities)가 창출될 뿐만 아니라 심지어는 추가 비용이 들기도 한다. 잠재적으로는 이러한 리스크 제어를 통해 이와 관련된 추가적인 리스크들이 만들어지기도 한다.

분석적인 리스크 기반 테스팅은 테스트 분석가를 포함해 테스트 팀에게, 특히 품질 리스크를 완화시켜 줄 것이다. 리스크 기반 테스팅은 소프트웨어의 라이프사이클 전체에 걸쳐서 테스팅을 통해 품질 리스크를 완화하는 것이다.

리스크 완화에 적용할 수 있는 표준도 존재한다. 우리는 이미 그러한 표준 중의 하나를 살펴보았는데, 미연방항공국(USFAA; United States Federal Aviation Administration)의 DO-178B가 바로 그것이다. 그러한 표준 중 다른 하나를 짧게나마 살펴보자.

프로젝트 리스크가 제어되어야 한다는 것은 무척이나 중요한 사실이다. 테스트 분석가들은, 특히 테스트가 영향을 미칠 수 있는 아래와 같은 프로젝트 리스크와 깊은 관련을 가지고 있다.

 

■ 테스트 환경과 툴의 준비 사항(Test environment and tools readiness)

■ 테스트 인력 가용성과 능력(Test staff availability and qualification)

■ 테스팅 입력값의 낮은 품질(Low quality of inputs to testing)

■ 테스팅 입력값에 대한 너무 많은 변경 트래픽(Too high change traffic for inputs to testing)

■ 표준, 규정, 그리고 테스팅 업무에 대한 기법의 부재(Lack of standards, rules, and techniques for the testing effort)

 

비록 일반적으로 이러한 리스크를 제어하는 것이 테스트 매니저의 업무이기는 하지만, 이러한 영역에 대한 적절한 제어가 취해지지 않을 경우 이는 테스트 분석가에게도 영향을 미치게 된다.

테스팅의 기본 원리인, 얼리 테스팅과 QA의 원리(The principle of early testing and QA)가 파운데이션 실라버스에서도 다루어지고 있다. 이 원리는 테스팅의 예방적인 역할을 역설하고 있는 것이다. 예방 차원의 테스팅은 분석적 리스크 기반 테스팅의 일부분이라고 할 수 있다. 우리는 테스트가 수행되기 이전에 리스크를 완화하려고 노력할 필요가 있다. 여기에는 테스트웨어의 신속한 준비, 테스트 환경에 대한 프리테스트, 테스트 레벨이 시작되기 전에 초기 버전에 대한 프리테스트, 테스팅을 위한 좀 더 광범위한 진입 기준의 주장(insisting on tougher entry criteria to testing), 테스트 가능성을 위한 요구사항과 디자인의 확인, 리뷰(초기 프로젝트의 행위에 대한 리뷰도 포함하는)의 참가, 문제 및 변경사항에 대한 관리, 프로젝트의 진행 사항과 품질에 대한 모니터링 회의에 참가하는 것들을 수반한다.

예방적인 개념의 테스팅에서, 우리는 소프트웨어의 라이프사이클 전체에 걸쳐서 품질 리스크에 대한 제어 행동을 취한다. 테스트 분석가들은 다양한 기법을 활용해 이러한 리스크를 제어하기 위한 기회를 찾아야만 한다.

 

■ 적합한 테스트 디자인 기법 선택하기

■ 리뷰와 인스펙션

■ 테스트 디자인 리뷰

■ 다양한 테스팅 레벨에 적합한 독립성 수준

■ 테스트 업무에서 가장 많은 경험을 가진 인력의 투입

■ 확인 테스팅(리테스팅)과 리그레션 테스팅을 위해 선택된 전략

 

예방적 차원의 테스트 전략이라는 개념은 광범위한 행동, 즉 전통적인 “테스팅” 개념으로 정의내릴 수 없는 다수의 행동들로 품질 리스크가 완화될 수 있고 또 그렇게 되어야 한다고 주장한다. 예를 들어, 요구사항이 제대로 작성되어 있지 않다면, 결국에는 제대로 된 디자인이 나오지 않을 것이고 이로 인해 궁극적으로는 쓸모없고 엉망인 코드를 만들것이다. 이러한 상황에서 바로 테스트를 수행하는 것보다, 제품의 품질을 향상시키기 위해서는 부실한 요구사항에 대한 리뷰를 먼저 수행해야 할 것이다.

물론, 테스팅이 모든 종류의 품질 리스크에 대해 효과적인 것은 아니다. 대부분의 경우 일반적인 테스팅 및 특정 리스크 항목에 적합한 테스트 기법을 사용함으로써 리스크를 감소시키는 효과를 볼 수 있을 것이다. 하지만 테스트 효율이 낮은 분야에서 리스크를 감소시키기 위해 테스팅을 사용하는 것은 결코 합리적인 일이라고 할 수 없다. 예를 들어, 허술한 코멘트나 구조화되지 않은 프로그래밍 기법를 사용한 코드를 유지보수하는 단계에서 발생하는 문제들은, 테스팅이 수행되는 초기에는 쉽게 드러나지 않는 경향이 있다. 
 

일단 테스트가 시작되기만 하면, 테스트 수행을 품질 리스크를 완화하기 위한 수단으로 사용할 수 있다. 테스팅 도중 결함이 발견된다면, 테스터는 그 결함에 대한 정보를 제공함으로써 리스크를 감소시키고 릴리즈 이전에 이를 처리할 수 있는 기회를 제공하게 되는 것이다. 테스팅 도중 결함을 발견하지 못했다면, 테스팅은 특정 환경 하에서 시스템이 정상적으로 동작한다는 것에 대한 확신을 줌으로써 리스크를 감소시킬 수 있다.

나는 앞서 리스크 기반 테스팅에서, 테스트에 대한 우선순위를 부여하기 위해 리스크의 레벨(Level of risk)이라는 개념을 사용한다고 말했었다. 이것은 여러가지 의미로 해석될 수 있지만, 여기에는 주로 2가지 방법이 적용되는데, 깊이 우선(Depth-first) 방법과 넓이 우선(Breadth-first) 방법이 그것이다. 깊이 우선의 방법에서는, 가장 높은 리스크에 대한 테스트가 모두 수행되고 나서 다른 낮은 리스크에 대한 테스트가 수행되며, 테스트는 엄격하게 리스크의 순서에 따라 수행된다. 넓이 우선의 방법에서는, 리스크 수준을 사용해 식별된 모든 리스크를 한 번에 망라할 수 있는 샘플 테스트를 선택하는데, 이는 동시에 한 번 이상 모든 리스크의 커버리지를 확인하면서, 선택된 테스트에 대한 가치를 평가하기 위한 것이다.

우리는 테스트를 수행하면서 잔여 리스크(Residual risk)의 측면에서 테스트의 결과를 측정하고 보고해야 한다. 어떤 영역에서 테스트 커버리지가 높아진다면, 잔여 리스크가 나타날 확률은 더 낮아진다. 어떤 영역에서 버그가 더 적게 찾아질수록, 잔여 리스크가 나타날 확률은 더 낮아진다. 물론, 우리가 리스크 분석에 기반한 리스크 기반 테스팅을 수행한다고 가정한다면, 이는 우리에게 사각지대(Blind spot)를 남길 수도 있으므로, 우리가 어떤 것을 놓치고 있지 않는지 확인하기 위해 미리 정의된 테스트 프로시져에서 커버하지 못하는 부분을 테스팅 할 필요가 있다.

아울러 우리는 테스팅에 투입되는 시간이나 업무를 효과적으로 줄일 필요가 있는데, 여기서 리스크를 그 가이드로 활용할 수 있다. 만약 잔여 이슈가 수용할 만하다면, 우리는 그 시점에서 나머지 테스트를 생략할 수도 있을 것이다. 일반적으로, 수행되지 않은 테스트들은 이미 수행된 테스트들에 비해 중요도가 떨어진다는 것에 주의하라. 만약 우리가 나머지 남아있는 테스팅을 수행하지 않는다면, 리스크의 소유권이라는 측면에서 남아있는 리스크는 사용자, 고객, 헬프 데스크 그리고 기술 지원 부서 혹은 운영 부서에게 그 소유권이 전이된다.

충분한 테스트를 수행할만한 시간이 있다고 가정해보자. 이럴 경우, 우리는 지금까지의 테스팅을 통해 배운 것들을 기반으로 리스크 분석을 다시 조정하고, 그에 맞추어 우리의 테스팅 업무도 다시 조정해야만 한다. 첫째로, 우리는 우리의 리스크 분석 작업을 다시 조정해야 한다. 그 다음, 우리는 현존하는 테스트와 추가될지도 모르는 테스트에 대해 우선순위를 다시 정해야 한다.

리스크 분석을 조정해야 하는지 아닌지에 대한 결정을 내리기 위해 무엇을 살펴보아야 하는가?

다음과 같은 주요 요인들을 살펴보아야 할 것이다.  

 

■ 완전히 새롭거나 혹은 상당 부분이 변경된 제품 리스크

■ 테스팅 동안 불안정하거나 결함이 잠재되어 있는 영역이 추가로 발견되었을 때

■ 리스크, 특히 수정된 결함과 관련되어 있는 리그레션 리스크

■ 기대하지 않았던 버그 클러스터의 발견

■ 놓쳤던 비즈니스 크리티컬한 영역의 발견

 

자, 만약 당신이 새롭게 추가된 테스트를 수행할 시간을 가지게 된다면, 무엇보다도 먼저 품질 리스크 분석을 다시 조정해야 한다는 것을 잊지 말아야 한다. 또한 각 프로젝트 마일스톤의 품질 리스크 분석도 업데이트 해야함을 잊어서는 안된다.

 

그림 3-1. FMEA를 사용한 품질 리스크 분석 문서의 예

 

3.9.5 리스크 식별 및 평가 결과의 예(An Example of Risk Identification and Assessment Results)

그림 3-1에서, 품질 리스크 분석 문서의 예를 확인할 수 있다. 이것은 실제 프로젝트로부터 도출된 사례이다.  
이 문서에 적용된 기법은 FMEA(Failure Mode and Effect Analysis)이다.

보이는 것과 같이, 테이블 왼쪽에 특정 기능을 명시하는 것부터 시작한다. 그 다음 장애 모드(Failure mode)를 명시하고 그로 인해 발생 가능한 효과들을 명시한다. 치명도(Criticality)는 효과, 즉 심각도(Severity)와 우선순위(Priority)에 기반해 결정된다. 가능한 원인이 요구사항, 디자인, 그리고 구현(Implementation) 동안의 버그 예방 작업을 가능하게 하기위해 명시된다.

다음으로, 발견 방법(Detection methods)을 볼 수 있는데, 이 방법들은 어떻게든 이 프로젝트에 적용할 수 있는 것들이어야 한다. 장애 모드가 더 발견하기 힘들면 힘들수록, 발견 횟수(Detection Number)는 적어진다. 리스크 우선 순위는 심각도, 우선순위, 그리고 발견 횟수에 따라 계산된다. 숫자가 적을수록 더 심각하다. 심각도, 우선순위 그리고 발견 횟수는 각각 1에서 5까지의 값을 가지므로, 리스크 우선순위의 범위는 1부터 125까지가 된다.

이 테이블은 가장 높은 수준의 리스크 아이템만을 보여주고 있는데, 그 이유는 내가 리스크 우선순위 정도를 기준으로 선별했기 때문이다. 이러한 리스크 아이템을 위해, 우리는 더 많은 추가적인 리스크와 이에 따른 적합한 리스크 제어 행동들을 기대할 수 있다. 이 시점에서 몇 가지 추가적인 행동들이 할당되었으나, 아직 각 리스크에 대한 소유자가 지정되지 않았다는 것을 확인할 수 있다.

테스팅 행위가 이러한 리스크 아이템과 연관됨으로 인해, 리스크가 증가할수록 테스트 케이스와 테스트 데이터의 양, 그리고 테스트 커버리지의 정도가 모두 증가한다는 것을 알 수 있다. 리스크 아이템이 가지는 리스크 레벨에 상응하는 어떤 테스트 프로시져도 수행이 가능하다(Notice that we can allow any test procedures that cover a risk item to inherit the level of risk from the risk item). 리스크 레벨에 기반해 테스트 프로시져의 우선순위를 기록해야 한다.  

 

3.9.6 라이프사이클 전체에 적용되는 리스크 기반 테스팅

(Risk-Based Testing throughout the Lifecycle)

나는 이미 리스크 기반 테스팅이 적절하게 수행된다면, 소프트웨어 라이프사이클 전체에 걸쳐서 리스크를 관리할 수 있다고 언급했었다. 테스트 프로젝트에서 내가 일상적으로 사용하는 기법을 기반으로 그것이 어떻게 수행되는지 살펴보자.

테스트 계획을 수행하는 동안, 리스크 관리가 처음으로 시작된다. 나는 프로젝트의 초기에 품질 리스크 분석을 수행하는데 이상적으로는 첫 번째 요구사항 명세서를 볼 수 있을 때부터 시작한다. 그러한 첫 품질 리스크 분석으로부터 평가(Estimate)를 만들고 이에 대해 프로젝트의 이해당사자들 및 관리자들로부터 합의를 이끌어내거나, 가급적이면 바로 승인을 받았으면 하는 것이 나의 바램이다.

프로젝트의 이해당사자들과 관리자들이 리스크 평가에 대해 동의한다면, 그때부터 테스트에 대한 계획을 시작한다. 테스팅 업무를 할당하고 테스트 순서를 정하는 것은 품질 리스크의 레벨에 바탕을 둔다. 테스팅에 영향을 끼칠 수 있는 프로젝트 리스크에 대해서도 계획을 수립한다.

테스트 제어가 수행되는 동안, 나는 프로젝트 전 기간에 걸쳐 주기적으로 리스크 분석을 조정할 것이다. 이로 인해 테스트 커버리지가 추가되거나, 증가하거나, 혹은 감소할 수도 있고, 테스트의 우선순위에 따라 테스트가 수행되지 않거나, 연기되거나 혹은 계획됐던 것보다 더 빨리 수행될 수도 있다.

테스트 분석과 디자인이 수행되는 동안에는, 나는 테스트 팀과 함께 리스크에 기반해 테스트 개발과 수행 업무를 할당한다. 나는 리스크라는 측면에서 테스트 결과를 보고하기를 원하기 때문에, 우리가 품질 리스크의 추적성을 지속적으로 유지보수 해야 한다고 확신한다.

테스트 구현 및 테스트 수행 기간 동안 나는 리스크 레벨에 기반해 테스트 프로시져의 순서를 정한다. 테스트 팀이 탐색적 테스팅을 활용하고 그밖의 다른 즉각대응 기법(Reactive technique)을 사용해 예상하지 못했던 리스크 지역을 탐색할 것을 권장한다.

종료 기준 평가와 보고 기간 동안, 나는 리스크에 비해 얼마나 많은 부분이 테스트에 의해 커버되었는지를 측정하기 위해 테스트 팀과 함께 작업을 진행한다. 테스트 결과를 보고할 때(그리고 그로 인해 릴리즈 준비가 결정될 때), 나는 테스트 케이스가 수행되고 그로 인해 발견된 버그라는 측면 외에도, 잔여 리스크(Residual risk)라는 측면에서도 함께 테스트 결과를 보고한다.

 

3.9.7 리스크 기반 테스팅 표준(Risk-Aware Testing Standards)

2장에서 살펴보았듯이, 미연방 항공국의 DO-178B 표준은 실패의 잠재적인 영향에 대해서까지 테스트가 확대되어야 한다, 즉 화이트박스 코드 커버리지라는 측면에서 측정되어야 한다는 것을 당연한 것으로 받아들이고 있다. 이것이 DO-178B를 리스크 숙지 테스팅 표준으로 만들어준다.

품질 리스크 관리를 포함하는 리스크 관리가 얼마나 복잡하고 안전 최우선 시스템 같은 엔지니어링 시스템에서 어떻게 수행되는지를 다루고 있는 또 다른 흥미로운 예는 어드밴스드 실라버스에서 언급하고 있는 ISO/IEC 표준 61508에서 찾아볼 수 있다.

“안전과 관련된 전자/전기/프로그램 가능한 시스템의 기능적 안전성(Functional safety of electrical/electronic/programmable electronic safety-related systems)”이라는 제목에서도 알 수 있듯이, 이 표준은 안전과 밀접한 관련을 가지고 있는 시스템을 제어하는 임베디드 소프트웨어에 적용될 수 있다.

이 표준은 말 그대로 많은 부분을 리스크에 초점을 맞추고 있다. 우선 리스크 분석이 요구된다. 이 표준은 리스크의 수준과 발생 가능성, 그리고 그 영향을 결정하는 것을 2가지 주요한 요소로 간주한다. 프로젝트가 진행되는 동안, 특히 시스템의 전기, 전자적 애플리케이션이나 소프트웨어의 향상을 통해 잔여 리스크 수준을 용인할 수 있는 수준으로까지 경감시켜야 한다.

이 표준은 리스크에 대한 고유한 철학을 가지고 있다. 이 표준은 전체 시스템에 대해서든, 혹은 하나의 단일 리스크 아이템에 대해서든지 간에, 리스크가 깨끗하게 모두 사라지는 수준을 확보할 수 없다는 사실을 알려준다. 또한 이 표준은 특히 안전과 관련된 프로젝트의 시작 단계에서부터 품질을 만들어나가야 하며, 프로젝트가 끝나가는 무렵에 가서야 품질을 증대시키려고 노력해서는 안된다는 것을 말해주고 있다. 그러므로, 우리가 요구사항 작성, 디자인 그리고 코드 리뷰를 당연하게 받아들이는 것처럼, 결함 예방 행위 역시 당연한 절차로 받아들여야 하는 것이다.

표준은 아울러 어떤 것이 허용할 만한 리스크인지와 그렇지 않은 리스크인지를 분간할 수 있게 하고, 허용할 수 없는 리스크를 감소시키는 단계를 밟도록 한다. 이러한 단계들이 테스팅 단계라고 한다면, 우리는 소프트웨어 안전 검증 계획과 함께 소프트웨어 테스트 명세서, 소프트웨어 테스트 결과, 소프트웨어 안전 검증, 확인 보고서, 그리고 소프트웨어 기능적 안전 보고서와 같은 문서들을 작성해야만 한다.

또한 표준은 문서 작성자의 편견에 의해서 발생하는 문제들에 대해서도 논하고 있다. 파운데이션 실라버스에서도 언급되었듯이, 이것은 자기가 만든 것을 자기가 테스트할 때 나올 수 있는 문제로, 당신이 만든 것을 테스팅 하는 것은 일종의 맹점을 가지고 있으며 이로 인해 잘못된 가정을 할 수도 있다는 것을 잊어서는 안된다. 표준은 테스터의 독립성에 대해서 이야기하고 있으며, 안전과 관련된 어떠한 테스트가 수행될 때에도 이러한 독립성이 반영되어야 한다고 주장하고 있다. 그리고 테스팅은 시스템이 테스트 가능한 상태로 작성되었을 때 가장 효율적으로 수행될 수 있으므로, 이 또한 요구사항에 포함되어야 하는 것이다.

이 표준은 안전 무결성 수준(SIL; Safety Integrity Level)이라는 개념을 제시하고 있는데, 이는 특정 컴퍼넌트나 서브 시스템에서 장애가 발생할 가능성에 기반하고 있다. SIL은 리스크와 관계된 다양한 결정에 영향을 미치는데, 여기에는 테스팅과 QA 기법의 선택도 포함된다.

다양한 기능적 기법 및 블랙박스 테스팅 디자인 기법들들은 이 책에서 다루게 될 것이다. 기법들 중의 많은 부분이 테크니컬 테스트 분석가를 위한 또 다른 볼륨에서 다뤄질 것인데, 여기에는 개연성에 기반한 테스팅(Probabilistic testing), 동적인 분석(Dynamic analysis), 데이터 저장과 분석(Data recording and analysis), 퍼포먼스 테스팅(Performance testing), 인터페이스 테스팅(Interface testing), 정적인 분석(Static analysis), 복잡성 메트릭(Complexity metrics) 등이 포함된다.

추가적으로, 놓친 버그의 발생 가능성을 경감시키는 데에는 리그레션 테스팅 기간을 포함해 면밀한 커버리지가 중요하기 때문에, 표준은 적합한 자동화 테스트 툴을 사용하는 것을 권장한다.

SIL이라는 개념에 의하면, 표준에 따르기 위해 다양한 테스팅 레벨을 요구될 수도 있다. 이러한 레벨에는 모듈 테스팅, 통합 테스팅, 하드웨어-소프트웨어 통합 테스팅, 안전 요구사항 테스팅 그리고 시스템 테스팅들이 포함될 수 있다.

만약 어떤 테스트 레벨이 요구된다면, 표준은 이를 문서화하고 이에 대한 독립적인 검증을 요구한다. 즉, 테스팅 활동에 대한 감사(Auditing)나 외부의 리뷰를 요구할 수도 있는 것이다. 여기에 더해, “Guarding the guards”라는 테마에 따라, 표준은 테스트 컨디션 하에서의 데이터 무결성을 검증하는 것과 더불어 테스트 케이스, 테스트 프로시져, 테스트 결과에 대한 리뷰도 요구한다.

아울러 표준은 구조적인 테스트 디자인 기법을 사용할 것을 요구한다. 구조적인 커버리지 요구사항은 SIL에 기반해 적용된다(이것은 DO-178B와 유사하다). 이러한 요구사항은 시스템의 안전 최우선이라는 측면에서 무척 중요한 사항이므로, 완벽한 요구사항의 준수를 한 번이 아니라, 다양한 테스팅 레벨에서 각기 여러 번 준수할 것을 요구한다.

SIL에 기반해 테스트 커버리지의 정도가 달라진다는 것을 다시 한 번 상기하자.

당신이 SIL이나 리스크 기반 테스팅에 대한 생각이 잡히지 않는 상태였다면 지금까지의 내용이 좀 과한 것처럼 보일 수도 있을 것이다. 하지만, 이제부터라도 당신이 움직이는 두 개의 금속판 사이 – 예를 들어 엘리베이터의 문 – 로 발을 옮길 때, 그 움직임을 제어하는 소프트웨어에 얼마나 많은 리스크가 남아있기를 원하는지 스스로에게 물어보라.