5. 테스트 관리

5.1.1. 테스트 조직과 독립성(Test Organization and independence)

-독립성(테스트 조직을 독립적으로 운영하는 것)의 장점은 아래와 같다.

1) 결함을 보는 시각, 결함을 발견하는 방법이 개발자와 달라 상대적으로 객관적이다.

2) 개발단계에서 작성된 명세와 구현 산출물을 객관적으로 검증할 수 있다.

3) 테스트 전문가로서 결함을 효과적이고 효율적으로 찾아내는 전략적 접근이 가능하다.

4) 테스팅 프로세스 평가를 통해 테스팅을 개선할 수 있다.

- 독립성의 단점은 아래와 같다.

1) 독립성 수준이 강하면 강할 수록 개발 및 제품관련 정보로부터 고립될 가능성이 높다.

2) 독립적 테스트를 마지막 체크포인트로 활용한다면, 프로젝트의 병목으로 작용할 수 있다.

3) 개발자가 품질에 대해 책임을 지지 않으려고 할 수 있다.

 

5.1.2. 테스트 리더와 테스터의 임무(Tasks of the test leader and tester)

- 테스트 리더는 테스팅 활동과 업무를 계획하고 모니터링하고 제어하는 역할을 수행하며, 프로젝트 관리자, 개발 관리자, 품질보증 관리자 또는 테스트 그룹 관리자가 테스트 리더의 역할을 수행할 수 있다.

- 테스트 리더의 전형적인 역할과 임무는 다음과 같다.

1) 조직의 테스트 정책 및 테스트 전략을 작성하고 리뷰 한다.

2) 프로젝트의 테스트 전략과 테스트 계획을 작성하고 리뷰 한다.

3) 테스트 전략과 계획을 프로젝트 관리자 및 이해관계자와 합의 및 조정한다.

4) 테스트 목적과 리스크에 대한 이해와 정황을 고려하여 테스트 계획을 수립한다.

5) 테스트 접근법을 결정한다.

6) 테스트에 소요 되는 시간, 노력, 비용을 추정하여 자원을 획득한다.

7) 수행 해야 할 테스트 레벨 및 테스트 사이클을 정의하고, 결함관리 계획을 수립한다.

8) 테스트 결과와 진척을 모니터링 하여 계획 활동을 조정하고 문제점을 보완하기 위해 추가 임무를 수행한다.

9) 추적성 확보를 위해 테스트웨어의 형상관리 방안을 구상한다.

10) 테스팅 및 제품의 품질을 평가하고, 테스트 진행상황을 모니터링 하기 위한 적절한 측정방법을 제시한다.

11) 자동화되어야 할 대상, 범위, 방법 등을 결정한다.

12) 테스트 지원 도구를 선정하고 사용자 교육 및 훈련을 계획한다.

13) 테스트 환경 구축과 관련된 사항을 결정한다.

14) 테스트 수행 과정에서 수집한 정보를 근거로 테스트 결과 보고서를 작성한다.

- 테스터의 역할과 임무

1) 테스트 계획 및 테스트 전략을 리뷰한다.
2) 테스트 용이성(Testability)을 평가하기 위해 요구사항, 명세, 모델을 리뷰 한다. 

3) 테스트 명세(Test specification)를 작성(설계)한다. 

4) 테스트 환경(Test environment)을 구축한다.

5) 테스트 데이터 준비 및 획득을 담당한다.

6) 테스트 구현, 실행, 로그 기록 및 테스트 실행 결과 평가, 결함 보고의 임무를 수행 한다.

7) 테스트 운영 및 관리 도구, 테스트 모니터링 도구를 사용한다.

8) 테스트 자동화 구현 및 자동화 요구사항을 구체화 한다.

9) 컴포넌트나 시스템의 성능을 측정한다.

10) 테스트 명세서를 리뷰 한다. 

 

5.2. 테스트 계획과 추정(Test planning and estimation)

5.2.1. 테스트 계획(Test planning)

- 계획 수립은 우리가 주어진 시간 안에 끝내야 할 '무엇'인가를 효과적이고 효율적으로 달성하기 위해 업무를 정의하고, 자원을 배치하고, 일정을 수립하는 등의 활동을 일컫는다. 

- 테스트 계획(Test planning)은 비단 개발 및 구현 프로젝트에서뿐만 아니라 시스템 유지보수과정에서도 같은 의미로 정의 될 수 있다. 

- 테스트 계획 단계에서 계획서를 문서화하고 이해 관계자와 공유하는 것이 중요한데, 이런 문서들로는 프로젝트(마스터) 테스트 계획서(Project test plan), 각 테스트 레벨 또는 테스트 유형 별 테스트 계획서가 있다. 

- 테스트 계획은 테스트 수명주기(Life cycle) 전반에 관연하는 지속적인 작업이다. 즉, 테스트 수행동안 변화하는 프로젝트 환경, 요구사항들에 의해 새롭게 도출되거나 변경되는 리스크를 감지하고, 테스트 대상의 품질 상황과 정보를 획득하여 지속적으로 테스트 계획을 조정하고 제어해야 한다. 

5.2.2 테스트 계획 활동 내용(Test planning activies)

- 테스트 계획 활동을 상세하게 나열 해 본 것이다.

1) 테스트 범위(scope)와 리스크를 결정하고, 테스팅의 목적을 식별한다.

2) 테스트의 총체적인 접근법(테스트 전략)을 정의한다.

3) 테스트 레벨과 각 테스트 레벨 별 시작과 종료 조건을 정의한다.

4) 테스팅 활동과 소프트웨어의 획득, 공급, 개발, 운영, 유지보수 단계의 수명주기 활동을 통합하고 조정한다.

5) 무엇을 테스트 하고, 누가 해당 테스트 활동을 수행하고, 어떻게 수행하고, 테스트 결과는 어떻게 평가 할지를 결정한다.

6) 테스트 분석과 설계 일정을 계획한다.

7) 테스트 구현, 실행 및 평가의 일정을 계획한다.

8) 정의된 다양한 테스트 활동에 자원을 할당한다.

9) 테스트 문서의 분량, 상세함의 정도, 구조와 템플릿을 정의한다.

10) 테스트 준비와 실행, 결함과 리스크 이슈를 모니터링하고 제어하기 위한 측정기준을 선정한다.

11) 충분한 정보를 제공하여 테스트 준비와 실행을 재현 가능하도록 테스트 프로시저의 상세 수준을 결정한다.

5.2.3. 완료 조건(Exit criteria)

- 테스트 완료 조건의 전형적인 사례이다.

1) 코드 커버리지, 기능 커버리지, 리스크 커버리지와 같은 보장성 또는 충분함에 대한 측정치(Thoroughness measures)

2) 추정된 결함 밀도 또는 신뢰성 측정치

3) 잔존 리스크(예, 수정되지 않은 결함 또는 테스트 커버리지가 부족한 테스트 영역 등)

4) 테스트 비용과 예산

5) 시장 출시 시기에 따른 스케줄

6) 수정되지 않은 결함 수(심각도 고려)

7) 시간당 결함 수(0에 근접할 때)

8) 재테스트(Re-test) 횟수

9) 모든 테스트 케이스를 1번 이상 수행하고 심각한 결함이 없거나 특정 수 이하일 때(테스트 케이스가 리스크 기반 전략에 의해 설계된 경우, 기법, 커버리지 내용을 포함) 

10) 예방된 피해(Damage)와 소요되는 테스트 비용 비교(예, 예방된 피해가 테스트 비용보다 적을 때)

11) 위 테스트 완료 조건의 몇 가지 조합(다른 추가적인 완료 조건들과 조합을 이룰 수도 있음)

5.2.4. 테스트 추정(Test estimation)

- 테스트 노력을 산정하는 추정(Estimation)은, 테스트 매니지먼트의 일환으로, 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정하는 것이다. 

- 테스트 추정 방법 중 대표적인 것은 메트릭 기반 접근법과 전문가 기반 접근법이다. 

1) 메트릭 기반 접근법(Metrics-based) : 과거 프로젝트나 유사 프로젝트의 메트릭을 근거로 또는 전형적인 가치를 근거로 테스트 노력 또는 업무량(Effort) 에측 

2) 전문가 기반 접근법(Expert-based) : 전문가나 업무(Tasks) 수행 주체에 의한 예측

- 수행 할 예정인 테스트 업무를 세분화하여 각 업무에 적절한 자원을 배분 하고, 이를 수렴하는 식의 워크 브레이크다운 스트럭쳐(WBS, Work Breakdown Structure) 방식을 택할 수 있다. 

- 테스팅 활동의 비용, 노력, 기간을 추정할 때 고려 해야 할 요소들이다.

1) 테스트를 시작할 수 있는 시점

2) 테스트 용이성

3) 개발자 및 관련자들의 숙련도(테스트 시작 전에 보장 될 수 있는 품질 수준)

4) 잠재결함이 얼마나 많은가

5) 개발자의 문제해결 시간

6) 테스트 환경의 가용성 및 안정성

7) 테스트웨어의 재사용성

8) 제품의 특성 : 테스트 베이시스의 품질, 제품 사이즈, 도메인 복잡성, 신뢰성 및 보안성 요구사항, 문서화 요구 등

9) 개발 프로세스의 특성 : 조직의 안정성, 도구 경험 여부, 테스트 프로세스, 투입 인력의 숙련도, 시간적 압박 정도 

10) 테스트 결과 : 발견된 결함 수와 요구되는 재 작업

11) 리스크 수준 및 테스트 깊이(Depth) : 선택된 테스트 설계 기법(개수 및 요구되는 지식수준), (예상되는) 테스트 케이스 수 

- 소프트웨어 개발 사이즈 분석 도구인 기능점수(FUnction point) 분석과 유사한 테스트 추정을 지원하는 도구인 TPA(Test Point Analysis)가 존재한다. 

- 개발의 어려움 정도를 반영 한 것이 기능점수라 한다면 TPA는 테스팅의 어려움을 분석하여 테스트의 노력을 체계적으로 산정한다. 

5.2.5. 테스트 접근법, 전략(Test approaches, test strategies)

- 소프트웨어 테스트 접근법 또는 전략이란 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등과 같은 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정하는 것을 의미한다.

- 이러한 테스트 접근법은 개발과정 중에 결함을 발견하는 예방적 접근법과 개발 이후에 테스트 실행을 통해 결함을 발견하는 사후적 접근법으로 분류 할 수 있다.

1) 예방적 접근법(Preventative approaches) : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계한다.

2) 사후(행동)적 접근법(Reactive approaches) : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계한다.

- 일반적으로 많이 선택하는 테스팅에서 접근법들을 나열하였다.

1) 분석적(Analytical) : 리스크 기반 테스팅(Risk-based testing)과 같이 제품의 리스크 분석을 통해 집중적으로 테스팅 해야 할 곳을 결정하는 것

2) 모델기반(Model-based) : 테스트 케이스 설계를 소프트웨어 설계 모델을 근거로 작성하고 이를 현행화 하는 과정을 거쳐 실제 테스트 수행을 하도록 하는 접근법 또는 확률론적 테스팅(Stochastic testing, random testing)을 통하여 장애율 통계를 바탕으로 설계하는 테스팅 

3) 방법론적(Methodical) : 오류 추측(Error guessing) 또는 장애 공격(Fault attack)과 같은 장애기반, 경험 기반, 체크리스트 기반, 소프트웨어 품질특성 기반 테스팅

4) 프로세스 및 표준 준수(Process or standard - compliant) : 산업 특화 표준 또는 다양한 애자일 개발 방법론에서 제시한 방법에 의한 테스팅

5) 동적/발견적(Dynamic and huristic) : 탐색적 테스팅(Exploratory testing)처럼 미리 계획되고 설계된 테스팅 이라기 보다는 사후적 접근법의 하나로, 실행과 평가가 동시에 이루어지는 테스팅

6) 자문기반(Consultative) : 외부 전문가의 조언과 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅

7) 리그레션 기피형(Regression-averse) : 보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 수트 등의 재사용을 통한 테스팅 

- 접근법의 선택은 다음과 같은 정황을 충분히 고려하여 선택해야 한다.

1) 프로젝트의 실패 리스크, 제품에 대한 위험 요소, 제품 장애가 인간, 환경, 회사에 미치는 리스크

2) 제안된 기법, 툴, 방법론에 대한 담당 인력들의 스킬과 경험

3) 테스팅 목적과 테스팅 팀의 임무

4) (개발 프로세스를 위한 내 외부 규정과 같은) 규정적 측면

5) 제품과 비즈니스의 본질적 특성

5.3. 모니터링과 제어(Monitoring and control)

5.3.1. 테스트 경과 모니터링(Test progress monitoring)

- 테스트 모니터링의 목적은 테스트 활동에 대한 피드백과 가시성(Visibility)을 제공하여 테스트 계획, 또는 조직차원의 테스트 정책이나 전략을 준수하여 테스팅이 수행되는 지를 관찰하는 것이다. 

- 모니터링 활동은 테스트 진행 보고서(Test status reports)를 검토 하거나 수집된 테스트 메트릭(Test metrics)을 분석하고, 이해관계자와 이러한 내용들을 공유하는 미팅 등을 수행하는 과정을 말한다. 이러한 활동을 통해 테스팅이 계획대로 수행되고 있는지를 알아낸다. 

- 프로젝트의 새로운 리스크 출현과 이미 알려진 리스크의 변화를 감지하고 이것이 테스팅에 영향을 줄 수 있는 것인지에 대하여 프로젝트 관리자 등의 이해관계자와 협의하도록 유도한다. 

- 특히, 모니터링 동안 수집된 정보 또는 메트릭(Metrics, 측정 요소)은 제품의 품질 평가, 테스트 진척도 파악은 물론 테스트 계획 단계에 합의한 테스트 완료 조건(Exit criteria) 달성 평가에도 사용할 수 있다. 

5.3.2. 테스트 리포팅(Test reporting)

- 테스트 리포팅은 테스팅 동안의 노력 및 활동에 대한 정보 및 제품의 결함 정보를 요약하여, 이해관계자의 의사결정을 지원할 목적으로 보고서를 작성하고 보고하는 활동이다. 

- 테스트 보고서의 종류는 크게 두 가지로 분류 되는데, 테스트 계획서에 계획된 업무들을 수행하는 동안 주요 시점에 현재 상황을 보고하는 테스트 진행 보고서(Test status report)와, 특정 테스트 유형 및 테스트 레벨이 종료되는 시점에 테스트 결과를 보고하는 테스트 종료 보고서(Test completion report)가 있다. 

- 테스트 보고서에 포함해야 할 요소들이다

1) 테스팅 기간 동안 처리했던 주요 업무

1-1) 예, 테스트 완료 조건(Exit criteria)이 충족된 시점

2) 향후 업무에 대한 의사결정을 지원 할 만한 의미 있게 분석된 정보와 메트릭

2-1) 잔존 결함의 평가

2-2) 테스팅 수행의 경제적 이득

2-3) 부각된 리스크

2-4) 테스트된 소프트웨어에 대한 자신감의 정도 

- 이러한 메트릭 또는 관련 정보는 리포팅 시점에 적합한 형태로 요약하고, 보고하여 다음의 내용을 평가할 수 있도록 해야 한다.

1) 해당 테스트 레벨 또는 테스트 유형에 대한 테스트 목적의 적합성(Adequacy)

2) 적용된 테스트 접근법의 적합성

3) 테스트 목적에 부합하는 테스트 효과성 

- 테스트 보고서는, 테스트 계획 단계에서, 미리 계획하고 설계함으로써 완성도를 높일 수 있다.

- 테스트 보고서를 계획하고 설계할 때 고려해야 할 요소는 다음과 같다.

1) 소프트웨어 제품 품질

2) 테스트 생산성(마일스톤 대비 진척도)

3) 소프트웨어 제품의 리스크

4) 테스트 프로세스 품질(결함 반결 효과성/효율성)

- 이 밖에도 테스트 보고서의 계획 및 설계 시 추가적으로 고려 해야 할 요소는 다음과 같다.

1) 타입별/심각도별/우선순위별 결함 수

2) 결함 상태 별 결함 수

3) 소프트웨어 사이즈 대비 결함 수(코드 라인 당 결함 수)

4) 요구사항 별 테스트 일 수(Days Test Effort per Requirement)

5) 해결되지 않은 결함과 그 영향(Hot Spot Analysis)

6) 오랫동안 수정되지 않은 결함 분석(Defect Age Analysis)

7) 결함 원인 분석

8) 테스팅의 상태 

8-1) 시작되지 않음/설계 단계/테스트 중/X회 재 테스트 중/완료 

- 테스트 진행 보고서(Test status report)는 테스트 진행 중 합의 사항과 근시일 내에 진행할 테스트 활동에 대한 내용을 담고 있다. 

- 결국, 앞서 다룬 테스트 진척도를 측정하는 일반적인 메트릭의 대부분을 주기적인 진행 보고서(예, 주간 보고서, 월간 보고서)에서 다루게 된다.

- 테스트 진척도를 측정하는 테스트 메트릭을 다음과 같다.

1) 테스트케이스 작성 비율

2) 테스트 환경을 갖추는 작업 완료 비율

3) 테스트 실행 관련 메트릭(예를 들어, 합격 및 불합격된 테스트케이스 수)

4) 결함 정보 : 결함 밀도, 발견된 결함과 수정된 결함, 장애율, 재 테스트 결과

5) 요구사항, 리스크, 코드의 테스트 커버리지

6) 제품에 대한 테스터의 주관적 자신감

7) 테스트 마일스톤 일자

8) 테스트 비용 관련 메트릭

- 테스트 진행 보고서에 담길 구체적인 사항에는 소프트웨어 제품 품질, 테스트 생산성(마일스톤 대비 진척도), 소프트웨어 제품리스크, 테스트 프로세스 품질(결함 발견 효과성/효율성), 테스트 문제점 등이 포함될 수 있다. 

- 테스트 종료 보고서(Test completion report)는 크게 두 유형으로 분류 할 수 있는데, 특정 테스트 유형 또는 테스트 레벨의 종료 시점에 작성하는 보고서와 전체 프로젝트 종료 시점에 작성되는 최종보고서다. 

- 테스트 종료 보고서에서 다루는 내용은 다음과 같다.

1) 프로젝트 테스트 계획, 시스템 테스트 계획, 성능 테스트 계획과 같은 테스트 계획 대비 차이 

2) 오픈 되어 있는 제품 리스크와 예상되는 영향 

2-1) 계획된 테스트가 이뤄지지 않은 부분

2-2) 계획보다 테스트가 부족한 부분

3) (제품 전체 또는 부분에 대해) 해결되지 않은 결함과 그로 인해 예상되는 영향

4) 시스템 파트의 현 상태와 커버된 리스크

5) 테스트 프로세스 품질

6) 테스트 프로젝트 수행 경험

7) 다음 번 테스트에 대한 조언

- 테스트 보고서를 더욱 의미 있께 작성 학 ㅣ위해서는 결함과 테스트 진척의 추이를 중심으로 일관성 있게 작성하되, 눈으로 쉽게 구분되는 색을 사용 하는 것이 좋다. 

- 테스트 보고서는 다음과 같이 활용될 수 있다.

1) 어플리케이션 출시(Application Release) 여부 결정

2) 결함의 심각도 및 유형 파악

3) (요구사항에 대한) 테스트 커버리지 확인

4) 어플리케이션 품질 결정

5) 다음 단계의 테스트를 위한 테스트 주요 요소 파악

- 테스트 보고서는 테스트 조직 또는 테스트 엔지니어의 가장 중요한 산출물 중 하나이다. 

- 좋은 리포팅 조건

1) 테스트 목적 및 요구사항과 일치 : 개발 프로젝트(의사결정)를 지원한다.

2) 테스트 전체와의 연계성 : 테스팅 계획(전략) 및 수행과의 연계성을 확보한다.

3) 단순한 결함 이상의 것들을 측정 : 리스크, 커버리지, 환경 등도 함께 측정한다.

4) 경향(Trend)을 리포팅 : 순간 포착식의 측정치는 지양한다.

5) 리포트 분량의 제한 : 리포트의 영향력(Impact)을 높이기 위해 분량을 적절하게 제한한다.

6) 리포팅의 일관성 유지 : 리포팅 내용, 스타일, 표현 방식 등에 일관성을 갖는다.

7) "측정"의 의미를 설명 : 당연한 것으로 가정하지 말고 독자를 위해 설명한다.

5.3.3. 테스트 제어(Test control)

- 테스트 제어는 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행 되도록 가이드 하거나 정정하는 활동이다. 이는 테스팅 전 영역을 범위로 하며 소프트웨어 수명주기 활동이나 업무에도 영향을 줄 수 있다.

- 다음은 테스트 제어 활동의 예이다.

1) 테스트 모니터링으로부터 얻은 정보를 기반으로 의사결정을 한다.

2) 프로젝트 리스크(예, 소프트웨어 개발 지연)가 실제 발생 하였을 때 테스트의 우선순위를 조정한다.

3) 테스트 환경의 가용성(Availability) 이슈가 있을 경우 테스트 일정을 변경한다.

4) 수정사항을 빌드(Build)에 반영하기 전에, 해당 수정사항을 개발자가 재테스트 하도록 요구하는 것과 같은 테스트 시작 조건(Entry criteria)을 정한다.

5.3.4. 테스트 완료(Test completion)

- 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에서 계획했던 모든 항목들이 완료 되면 시작하는 활동이다. 

- 테스트 자산 및 테스트 환경을 보존하고, 테스팅 활동에서의 교훈을 찾아내어 이해관계자와 공유하기 위함이다.

- 테스트 완료 단계의 주요 활동 및 내용을 살펴보면 다음과 같다.

1) 테스트 계획서, 자동화 테스트 절차 및 매뉴얼, 테스트 환경 구성도 등과 같은 테스트 자산을 식별하고, 형상관리 등을 통해 보존한다.

2) 다른 프로젝트 또는 다음 단계의 테스팅 활동에서 재사용 가능한 테스트 자산을 식별한다.

3) 재사용 가능한 테스트 자산 또는 환경을 문서화 하고 이를 이해관계자와 공유한다.

4) 테스트 환경을 다음 단계의 사용자를 위해서 정제(Clean up)한다.

5) 테스팅 활동 전반의 문제점 및 개선점을 찾아 교훈(Lesson Learned)으로 기록한다.

6) 교훈(Lesson Learned)을 공유한다.

7) 테스트 완료보고서에 테스트 계획대비 실적, 결함 상태, 리스크 등과 함께 테스트 자산의 보존 상황 및 교훈을 기록하고 이를 이해관계자에게 보고한다. 

5.4. 형상 관리(Configuration management)

형상 관리(Configuration management)의 목적은 프로젝트나 제품의 전체 수명주기에 걸쳐 시스템이나 소프트웨어(컴포넌트, 데이터, 문서)의 상태를 그대로 보전(Integrity), 보호(Umbrella)하고 유지하기 위함이다.

- 테스팅 측면에서 형상 관리는 다음의 내용을 보증한다.

1) 테스트웨어(Testware) 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템(테스트 대상)과의 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성(Traceability) 확보.

2) 테스트 문서에서 참조하고 있는 모든 관련 문서 또는 소프트웨어 아이템이 모호하지 않게 관리됨.

- 테스터는 형상관리를 통해 테스트된 품목, 테스트 문서, 테스트(케이스)와 테스트 하네스(Harness) 등을 혼선 없이 관리하고 효율적으로 재사용 할 수 있다.

- 형상 관리 절차(Procedures)와 인프라(툴 지원)는 테스트 계획 단계에서 결정하고 문서화되어, 구현되어야 한다. 

5.5. 리스크와 테스팅(Risk and testing)

- 리스크는 이벤트, 위험 요소(Hazard), 위협(Threat) 혹은 상황의 발생 가능성과, 발생 했을 경우의 바람직하지 못한 결과 즉, 잠재적인 문제로 정의될 수 있다. 

- 리스크 수준은 의도하지 않은 이벤트가 발생될 가능성과 그 영향(의도하지 않은 이벤트로 인한 해로운 결과)에 의해 결정된다. 

5.5.1. 프로젝트 리스크(Project risks)

- 프로젝트 리스크는 프로젝트 목적을 달성하기 위한 프로젝트의 역량(Capability) 전반에 걸쳐 관련되어 있으며, 다음과 같은 리스크가 존재한다. 

- 조직적인 요소

1) 테스팅 전문 스킬과 인력의 부족

2) 개인적 이슈와 교육훈련 관련 이슈

3) 다음과 같은 정치적인 이슈

3-1) 테스터가 자신의 요구(Needs)와 테스트 결과를 커뮤니케이션 하는데 있어서의 문제

3-2) 테스팅과 리뷰에서 발견된 정보를 개발 프로젝트에 반영(Follow-up)하는 것에 실패
(이 경우, 개발과 테스팅 업무가 개선되지 않음) 

4) 테스팅에 대한 비현실적 태도나 기대치(테스팅 중에 검출한 결함의 가치를 인정하지 않음) 

- 기술적 이슈

1) 완성도 높은 요구사항을 정의하는데 있어서의 문제

2) 기 제약조건 하에서 요구사항이 수용되는 정도(범위) 

3) 설계, 코드, 테스트의 품질

- 공급자 이슈(Supplier issues)

1) 공급자인 제 3자 협력업체(Third party)가 역할 수행에 실패

2) 계약상의 이슈

5.5.2. 제품 리스크(Product risks)

- 리스크 제어 활동으로서의 테스팅은 심각한 결함을 얼마나 효과적으로 제거했는지를 측정하여 잔존 리스크(Residualrisk)에 대한 피드백을 제공한다.

- 이때, 해당 결함으로 야기될 수 있는 사고에 대비한 계획(Contingency plan)의 효과성도 측정하여 잔존 리스크에 대한 피드백을 제공한다.

- 리스크 기반 테스팅은 또한 제품 리스크를 식별해 주고, 해당 리스크를 이용해 테스트 계획 및 제어, 테스트 설계 및 명세화, 테스트 준비 및 실행을 가이드 한다. 

- 리스크 기반 접근법에서 식별된 리스크는 다음과 같이 사용될 수 있다.

1) 사용할 테스트 기법 결정

2) 테스트 수행 범위 결정

3) 심각한 결함을 조기에 발견하기 위해 테스트의 우선순위 결정

4) 테스트와 관련 되지는 않았지만 리스크를 줄이기 위해 필요한 활동(경험이 적은 개발 설계자에게 교육훈련 제공 등)을 수행해야 할지 결정

5) 리스크가 높은 부분에 개발 또는 품질 관련 교육(코딩 규칙 교육 등)을 적절하게 제공하여 미래의 리스크를 줄일 수 있음. 

- 리스크 관리 활동은 다음과 같이 체계적으로 접근하여 프로젝트 실패의 가능성을 최소화하여야 한다.

1) 잘못될 수 있는 것(Risk)을 평가하고 정기적으로 재평가 한다.

2) 어떤 리스크가 중요시 되어야 하는지 결정한다.

3) 리스크 수준에 맞게 적절하게 대응한다.

- 여기에서 테스팅은 새로운 리스크를 식별할 수 있게 지원하고, 어떤 리스크를 감소시킬지 결정하는데 도움이 되며, 리스크의 불확실성을 낮출 수 있다. 

- 테스트 레벨 별로 파악한 여러가지 리스크 영역 또는 요소에 리스크(장애 가능성 x 영향)를 부여

- 주어진 시간과 자원을 고려하여 리스크 높은 부분을 우선적으로 공식적인 기법을 적용하고 경험적인 테스트 케이스도 충분히 확보하여 강력하게 테스팅

- 리스크가 낮은 부분은 시간이 허용하는 범위에서 자유롭게 테스팅을 진행 하는 것이 일반적임
(시간과 자원이 허용되면 테스팅 기법을 적용하여 테스팅 할 수도 있음)

- 리스크 관리(Risk management) 방법에 근간을 두고 있다. 

1) 리스크 식별 : 테스트 대상을 리스크 분석 단위인 아이템으로 분류하고 식별

2) 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석
3) 결국, 장애 발생 빈도(Likelihood)와 장애로 인한 영향(Impact)을 식별

4) 리스크의 우선순위를 결정

5) 리스크 계획 활동 : 리스크 정보를 근거로 대처 방안 수립(테스트 전략 수립)

6) 리스크 추적 : 리스크 완화 활동(테스팅)에 대한 모니터링 및 제어 

- 리스크 식별(Risk Identification) 단계

1) 리스크는 다양한 방법으로 식별이 가능한데, 일반적으로 테스트 대상을 기능적 또는 기술적 아이템으로 분리하여 각각의 아이템에 리스크가 존재하는 것으로 보는 것이다.

2) 이 밖에도 요구사항 분석서에서 상위레벨 테스트(High level test)를 필요로 하는 항목과 아키텍처에서 하위레벨 테스트(Low level test)가 필요한 항목들을 도출하면 이것들도 리스크 아이템이 된다. 

3) 리스크 아이템은 브레인스토밍 세션을 이용하여 효율적으로 식별할 수도 있다. 

4) 도출한 리스크 아이템을 의미 있는 그룹으로 묶어 리스크 분석 단위를 만든다. 

5) 가급적이면, 하나의 리스크 분석단위에 너무 많은 리스크 아이템이 들어가는 것은 좋지않다. 

- 리스크 분석(RIsk analysis) 단계

1) 리스크 분석은 중요하고, 복잡하고, 잠재적으로 결함이 많은 소프트웨어나 시스템의 부분을 분석하여 장애 발생 가능성(Likelihood)과 장애로 인한 영향 또는 손실(Impact)을 예측하여 리스크 우선순위를 결정하는 것이다. 

2) 이 단계에서는 결함 패턴 등 기존 프로젝트에 기반하여 장애 발생 가능성을 높여주는 리스크 요소(Risk Factors)와 장애로 인한 영향 또는 손실을 높이는 리스크 요소를 결정한 후 이해관계자(Stakeholders)를 참여시켜 이들의 타당성을 검토한다. 

3) 리스크 요소(Risk factors)는 여러 가지 방식으로 도출 될 수 있겠지만, 아래와 같이 테스팅 경험에서 도출한 간단하면서 효과적인 리스크 요소를 활용하여 상황에 맞게 변형시켜 사용하고, 가중치(Weightings)를 적용하는 것도 가능하다. 

3-1) 장애 발성 가능성(Likelihood)

3-1-1) 복잡성(Complexity)

3-1-2) 새로운 개발의 정도(기존에 개발된 것의 재사용 수준)

3-1-3) 상호관계(Interrelationship, 인터페이스 개수)

3-1-4) 프로그램 소스 코드의 크기

3-1-5) 사용된 기술의 난이도/최신성

3-1-6) 개발팀의 경험 미흡

3-2) 장애로 인한 영향(Impact)

3-2-1) 사용자에 의한 취급 중요도(잘 팔리는 아이템)

3-2-2) 경제적, 안전적, 회사 이미지 피해

3-2-3) 사용 빈도(Usage intensity)

3-2-4) 외부적 가시성(External visibility)

4) 리스크 요소가 결정되었으면 리스크 아이템 별로 해당 리스크 요소가 어느 정도의 수준인지를 결정한다. 이때, 이해관계자(Stakeholders, 개발리더, 고객지원, 마케팅, 사용자 등)의 참여가 필수적인데, 이들에게 리스크 아이템의 리스크 요소 별 점수를 매기도록 요청하면 모두 중요하고 답변하는 것이 일반적이므로 신중하게 의견을 모아야 한다. 

- 리스크 계획 활동(Risk planning) 단계

1) 리스크 계획 활동은 리스크 분석 결과를 근거로 대처 방안 수립, 즉 리스크를 줄이는 "테스트"를 생성하는 것이다. 

2) 리스크 분석 단계에서 합의/결정된 리스크 아이템별 리스크 요소의 점수를 이용하여 리스크 매트릭스에 표시한다. 

3) 리스크가 가장 높은 영역(장애 발생 가능성과 영향이 모두 높은 부분)에 있는 리스크 아이템은 공식적으로 테스트를 설계하고, 경계값 분석 기법을 적용하고, 구문 커버리지를 90%확보할 수 있도록 하며, 완전한 코드 인스펙션을 수행한다.

5.6. 인시던트 관리(Incident management)

- 인시던트 관리(Incident Management)의 목적은 테스트에서 발견한 이슈(Issue)에 대해 추가적으로 수행해야 할 일에 대해 보고하고 이를 추적하기 위함이다. 

- 신규 테스트 실행에서 발생한 이슈, 즉 실제 결과와 기대 결과 사이의 불일치를 인시던트 보고서(Incident Report)로 작성하고, 기 발생된 결함에 대한 재 테스트인 경우는 인시던트 보고서의 상태(Status)를 변경 해야 한다. 

- 인시던트는 발견되어 분류되는 시점부터 수정되고 확인 될 때까지 추적 되어야 할 대상이다. 이를 효율적으로 관리하기 위해서는 프로세스가 수립되어야 하며, 분류 규칙도 반드시 포함해야 한다. 

- 인시던트 혹은 결함(Defect)은 프로그램 개발, 리뷰, 테스팅 혹은 소프트웨어 제품 사용 중에 발견되거나 발생할 수 있다. 

- 인시던트가 발생 되는 곳은 프로그램 코드, 운영 중인 시스템, 요구사항 문서, 개발 문서, 테스트 문서, 도움말이나 설치 가이드(사용자용 정보 또는 문서) 등이 있다.

 - 인시던트 리포트는 다음과 같은 목적을 갖는다

1) 개발자와 프로젝트 관련자에게 문제점을 식별하고, 격리하고, 필요하면 정정하도록 피드백을 제공

2) 테스트 리더에게 시스템의 품질 또는 테스트 진척을 추적할 수 있는 정보를 제공

3) 테스트 프로세스 개선(Test process improvement)에 대한 아이디어 제공 

- 인시던트 리포트에는 다음과 같은 내용들이 포함될 수 있다.

1) 이슈 발생 날짜, 이슈를 제기한 조직, 작성자(Author)

2) 기대 결과와 실제 결과

3) 테스트 항목(Configuration item)과 환경(Environment)의 식별

4) 소프트웨어나 시스템의 수명주기에서 인시던트가 발견된 시점

5) 로그, 데이터베이스 덤프, 화면 덤프 등을 포함한 인시던트 재현이 가능한 상세 설명

6) 이해관계자의 이익에 영향을 주는 범위 또는 정도

7) 결함이 시스템에 미치는 심각도 

5.7. 테스트 프로세스 평가(Test process assessment)

- 조직 차원의 테스트 프로세스는 조직이 테스팅을 하는 이유 및 목적을 기술하는 테스트 정책과 테스팅 접근에 대한 조직 차원의 테스트 전략을 수립하고 적용하며 개선하도록 하는 프로세스이다.

- 테스트 매니지먼트 프로세스는 소프트웨어 개발 프로젝트에서 총괄적으로 수행해야 할 테스팅을 레벨 별로 또는 유형 별로 수행되도록 관리하고 통제 하는 프로세스를 의미한다. 

- 정적, 동적 테스트 프로세스는 소프트웨어 개발 수명주기 전반에 걸친 정적 테스트를 위한 준비 단계, 리뷰/분석 단계, 후속 처리 과정에 대한 프로세스와 각 테스트 레벨 또는 특정 테스트 유형에서 수행해야 할 분석 및 설계, 구현 및 실행, 결함 보고, 환경 구성 및 유지보수 활동등의 동적 테스트 프로세스를 의미한다. 

- 이러한 테스트 프로세스를 얼마나 체계적으로 만들고 수행하느냐에 따라 그 조직의 테스팅 성숙도가 달라진다. 

- 테스트 프로세스 성숙도가 높아지면, 다음과 같은 효과를 기대 할 수 있다.

1) 정렬되고 조직화되며 반복적이 된다.

2) 전문적이고 공학적인 활동으로 인식된다.

3) 개발 활동과는 독립적으로 수행된다.

4) 결함 발견 활동에서 결함 예방 활동으로 변화된다.

5) 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악하게 된다.

6) 지속적으로 개선되고 향상된다.

7) 테스트 비용을 절감시키고 조직 구성원의 만족감을 고취시킨다. 

- 테스트 프로세스 평가 및 개선 모델 중 가장 대표적인 것으로는 TMMi(Test Maturity Model Integration)와 TPI(Test Process Improvement)를 들 수 있다. 

- TMMi와 TPI는 테스트 수행 조직의 테스트 프로세스 성숙도 평가에 널리 사용되고 있어 그 유용성이 이미 여러 형태로 입증되었다. 

 

 

도움이 되셨다면 광고 한번씩 클릭 부탁드립니다 😁