본문 바로가기
ISTQB 공부/CTFL

6. 테스트 관리

by Testengineer 2020. 12. 11.
반응형

1. 테스트 조직(Test organiztion)

테스트 조직과 독립성

테스트 조직의 독립성 수준은 해당 조직의 테스트 요구사항과 테스트 대상 제품의 특성, 요구되는 품질 수준, 프로젝트 조직 구조 등을 고려하여 적절하게 조정하여야 한다.

독립성의 장점 : 결함을 보는 시각, 결함 발견 방법이 개발자와 달라 상대적으로 객관적이다. 개발 단계에서 작성된 명세와 구현 산출물을 객관적으로 검증할 수 있다. 테스트 전문가로서 결함을 효과적이고 효율적으로 찾아내는 전략적 접근이 가능하다. 테스팅 프로세스 평가를 통해 테스팅을 개선할 수 있다.

독립성의 단점 : 독립성 수준이 강할수록 개발 및 제품 관련 정보로부터 고립될 가능성이 높다. 독립적 테스트를 마지막 체크포인트로 활용한다면, 프로젝트의 병목으로 작용할 수 있다. 개발자가 품질에 대해 책임지지 않으려 할 수 있다.

 

테스트 리더와 테스터의 임무

여기서 테스트 매니저, 팀 리더, 분석가의 역할을 묶어서 테스트 리더 그리고 테스트 분석가, 수행가, 네비게이터의 역할을 묶어서 테스터로 분류한다. 테스트 리더는 테스팅 활동과 업무를 계획하고 모니터링하고 제어하는 역할을 수행하며, 프로젝트 관리자, 개발 관리자, 품질보증 관리자 또는 테스트 그룹 관리자가 테스트 리더의 역할을 수행할 수 있다. 테스터는 수립된 테스트 전략과 방향, 계획 및 테스트 리더의 지침에 따라 테스트 명세를 구현하고 테스트를 실행하는 역할을 수행한다. 단순 반복적인 테스트가 많을 경우 이를 자동화하거나 일회성의 성격이 강한 테스트의 경우에는 필요에 따라 테스트 수행 전문 외주 인력을 관리하는 역할도 테스터의 업무에 해당한다. 

 

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

테스트 계획

소프트웨어 테스팅에서의 계획은 테스팅 목적, 범위, 필요한 자원 그리고 일정을 결정하는 등의 업무를 수행하는 활동을 의미한다. 테스트 계획은 비단 개발 및 구현 프로젝트에서뿐만 아니라 시스템 유지보수 과정에서도 같은 의미로 정의될 수 있다. 

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

 

테스트 계획 활동 내용

테스트 계획의 주요 활동에는 테스트를 성공적으로 수행하기 위한 전략을 수립하는 것과 소프트웨어 수명주기 단계별로 적합한 테스팅 관련 작업들을 결정하고, 테스트 대상, 범위 그리고 전략에 기반한 투입 자원 및 일정을 계획하는 활동을 포함한다.

 

완료 조건

테스트 완료 조건 수립의 목적은 하나의 테스트 레벨 또는 특정 목적의 테스팅이 언제 종료할지를 정의하는 것이다.

예를 들면, 코드 커버리지, 기능 커버리지, 리스크 커버리지와 같은 보장성 또는 충분함에 대한 측정치, 추정된 결함 밀도 또는 신뢰성 측정치, 테스트 비용과 예산, 재테스트 횟수 등이 있다.

 

테스트 추정

테스트 노력을 산정하는 추정은, 테스트 매니지먼트의 일환으로 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정하는 것이다. 대표적인 것으로는 메트릭 기반 접근법과 전문가 기반 접근법이다.

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

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

어떤 접근법을 선택하든 추정은 리스크 분석과 테스트 전략을 근거로 산정해야 하며, 수행할 예정인 테스트 업무를 세분화하여 각 업무에 적절한 자원을 분배하고, 이를 수렴하는 식의 워크 브레이크다운 스트럭쳐(WBS) 방식을 택할 수 있다. 이렇게 테스트 업무량이 산정되면 테스트에 투입할 리소스를 식별하고 스케줄링을 할 수 있다.

소프트웨어 개발 사이즈 분석 도구인 기능점수 분석과 유사한 테스트 추정을 지원하는 도구인 TPA(Test Point Analysis)가 존재한다. 개발의 어려움 정도를 반영 한 것이 기능점수라면, TPA는 테스팅의 어려움을 분석하여 테스트의 노력을 체계적으로 산정한다.

 

테스트 접근법, 전략

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

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

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

접근법 내용
분석적(Analytical) 리스크 기반 테스팅과 같이 제품의 리스크 분석을 통해 집중적으로 테스팅 해야할 곳을 결정하는 것
모델기반(Model-based) 테스트 케이스 설계를 소프트웨어 설계 모델을 근거로 작성하고 이를 현행화 하는 과정을 거쳐 실제 테스트 수행을 하도록 하는 접근법 또는 확률론적 테스팅을 통하여 장애율 통계를 바탕으로 설계하는 테스팅
방법론적(Methodical) 오류 추측 또는 장애 공격과 같은 장애기반, 경험 기반, 체크리스트 기반, 소프트웨어 품질 특성 기반 테스팅
프로세스 및 표준 준수(Process or standard-compliant) 산업 특화 표준 또는 다양한 애자일 개발 방법론에서 제시한 방법에 의한 테스팅
동적/발견적(Dynamic and heuristic) 탐색적 테스팅처럼 미리 계획하고 설계된 테스팅이라기보다는 사후적 접근법의 하나로, 실행과 평가가 동시에 이루어지는 테스팅
자문기반(Consultative) 외부 전문가의 조언과 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅
리그레션 기피형(Regression-averse) 보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 수트 등의 재사용을 통한 테스팅

 

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

테스트 경과 모니터링

테스트 모니터링 목적은 테스트 활동에 대한 피드백과 가시성을 제공하여 테스트 계획 또는 조직차원의 테스트 정책이나 전략을 준수하여 테스팅이 수행되는지를 관찰하는 것이다. 모니터링 활동은 테스트 진행 보고서를 검토하거나 수집된 테스트 메트릭을 분석하고, 이해관계자와 이러한 내용들을 공유하는 미팅 등을 수행하는 과정을 말한다. 이러한 활동을 통해 테스팅이 계획대로 수행되고 있는지를 알아낸다.

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

 

테스트 리포팅

테스트 리포팅은 테스팅 동안의 노력 및 활동에 대한 제품의 결함 정보를 요약하여, 이해관계자의 의사결정을 지원할 목적으로 보고서 작성, 보고 하는 활동이다. 테스트 보고서의 종류는 크게 두 가지로 분류되는데 테스트 계획서에 계획된 업무들을 수행하는 동안 주요 시점에 현재 상황을 보고하는 테스트 진행 보고서와, 특정 테스트 유형 및 테스트 레벨이 종료되는 시점에 테스트 결과를 보고하는 테스트 종료 보고서가 있다.

테스트 진행 보고서 : 테스트 진행 중 합의 사항과 근시일 내에 진행할 테스트 활동에 대한 내용을 담고 있다. 테스트 진척도를 측정하는 일반적인 메트릭의 대부분을 주기적인 진행 보고서에서 다루게 된다. 진행 보고서에 담길 구체적인 사항에는 소프트웨어 제품 품질, 테스트 생산성, 소프트웨어 제품 리스크, 테스트 프로세스 품질, 테스트 문제점 등이 포함될 수 있다.

테스트 종료 보고서 : 특정 테스트 유형 또는 테스트 레벨의 종료 시점에서 작성하는 보고서와 전체 프로젝트 종료 시점에 작성되는 최종 보고서로 나눌 수 있다. 종료 보고서에는 프로젝트 테스트 계획, 시스템 테스트 계획, 성능 테스트 계획과 같은 테스트 계획 대비 차이와 오픈되어 있는 제품 리스크와 예상 되는 영향, 해결되지 않은 결함과 그로 인해 예상되는 영향 등을 다룬다.

 

테스트 제어

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

제어 활동의 예로는 테스트 모니터링으로부터 얻은 정보를 기반으로 의사결정을 한다거나 프로젝트 리스크가 발생하였을 때 테스트의 우선순위 조정, 테스트 환경의 가용성 이슈가 있을 경우 일정 변경 등이 있다.

 

테스트 완료

테스팅 프로젝트의 마지막 단계라고 할 수 있는 완료 활동 역시 테스트 관리의 중요 활동이다. 이는 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에 계획했던 모든 항목들이 완료되면 시작하는 활동이다. 주요 목적은 테스트 자산 및 테스트 환경을 보존하고, 테스팅 활동에서의 교훈을 찾아내어 이해관계자와 공유하기 위함이다.

 

4. 형상관리(Configuration management)

형상관리 목적은 프로젝트나 제품의 전체 수명주기에 걸쳐 시스템이나 소프트웨어의 상태를 그대로 보전, 보호하고 유지하기 위함이다. 

테스팅 측면에서 형상관리는 테스트웨어 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템과의 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성 확보, 테스트 문서에서 참조하고 있는 모든 관련 문서 또는 소프트웨어 아이템이 모호하지 않게 관리됨을 보증한다.

테스터는 형상 관리를 통해 테스트된 품목, 테스트 문서, 테스트(케이스)와 테스트 하네스 등을 혼선없이 관리하고 효율적으로 재사용할 수 있다. 형상 관리 절차와 인프라는 테스트 계획 단계에서 결정하고 문서화되어, 구현되어야 한다.

 

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

리스크는 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성과, 발생 했을 경우의 바람직하지 못한 결과(=잠재적인 문제)로 정의될 수 있다. 리스크가 높다는 것은 사용빈도가 높으면서 결함 가능성도 높고 발생된 결함 또는 장애로 인한 손실이 크다는 것이다.

프로젝트 리스크는 프로젝트 목적을 달성하기 위한 프로젝트의 역량 전반에 걸쳐 관련되어 있으며 조직적인 요소, 기술적 이슈, 공급자 이슈와 같은 리스크가 존재한다.

제품 리스크는 소프트웨어나 시스템에서 의도하지 않은 향후 이벤트나 위험요소가 존재하는 잠재적인 장애영역이다. 제품 리스크는 프로젝트의 성공과 관계된 특별한 한 가지 종류의 리스크이다. 리스크 제어 활동으로서 테스팅은 심각한 결함을 얼마나 효과적으로 제거했는지를 측정하여 잔존 리스크에 대한 피드백을 제공한다.

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

- 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석

- 장애 발생 빈도(Likelihood)와 장애로 인한 영향(Impact)을 식별

- 리스크 우선순위를 결정

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

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

 

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

인시던트 관리의 목적은 테스트에서 발견한 이슈에 대해 추가적으로 수행해야 할 일에 대해 보고하고 이를 추적하기 위함이다. 실제결과와 기대 결과 사이의 불일치를 인시던트 보고서로 작성하고, 기 발생된 결함에 대한 재테스트인 경우에는 인시던트 보고서의 상태를 변경한다.

인시던트는 발견되어 분류되는 시점부터 수정되고 확인될 때까지 추적되어야 할 대상이다. 

 

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

1) 조직을 셋업하고 운영하는 관점에서의 조직 테스트 프로세스

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

2) 프로젝트 전체 또는 특정 레벨 및 유형의 테스트를 위한 테스트 매니지먼트 프로세스

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

3) 마지막으로 테스트 수행 관점에서는 동적 테스팅과 정적테스팅을 구분하여 각각의 프로세스

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

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

  TMMi TPI
(커버하는)테스트 레벨 하위레벨과 상위레벨 테스팅을 유사한 수준으로 다룸 상위레벨 테스팅에 보다 집중함
성숙도 평가 접근법 하향식 개선 프로세스를 지향하는 조직 차원에서의 성숙도 평가(5레벨로 평가, 테스트 매니지먼트 영역) 상향식 모델로 특정 프로젝트나 프로그램에 대한 테스트 개선을 적절하게 조언(프로세스별 차별적 평가, 테스트 엔지니어링 영역)
테스트 핵심영역 간 의존성 여부 핵심 영역간 의존성을 정의하지 않음 핵심 영역 간의 의존성 정의
모델의 태생 학계에서 개발하여 업계에서 발전시킴 시스템 테스팅 전문업체에서 개발하여 확산
공식 레벨 부여 여부 TMMi Foundation 공식인증제도(선임심사원 운영) 부여하지 않음
관련 모델 CMMI(시스템 개발 프로세스 심사모델)와 밀접한 관련이 있음 TMap 테스트 방법론과 강한 열결고리가 존재

 

출처 : 개발자도 알아야 할 소프트웨어 테스팅 실무 제3판

반응형

'ISTQB 공부 > CTFL' 카테고리의 다른 글

CTFL 시험 후기  (0) 2020.12.26
7. 테스트 지원 도구  (0) 2020.12.16
5. 테스트 설계기법 - 상태전이 테스팅  (2) 2020.11.29
4. 테스트 설계 기법  (0) 2020.11.26
3. 정적 기법  (0) 2020.11.19

댓글