[2011 실라버스 - Chapter.5] 테스트 관리를 위한 요소들에 대해서 알아보자

※ "개발자도 알아야 할 소프트웨어 테스팅 실무"를 기반으로 요약 ※ 

 

Part 5. 테스트 관리

5.1 테스트 조직

5.1.1 테스트 조직과 독립성

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

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

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

테스트 리더의 역할과 임무
- 조직의 테스트 정책 및 테스트 전략 작성,리뷰
- 테스트 목적과 리스크에 대한 이해와 정황을 고려하여 테스트 계획을 수립한다.
- 수행해야 할 테스트 레벨 및 테스트 사이클을 정의하고, 결함 관리 계획을 수립한다.
- 테스팅 및 제품의 품질을 평가하고, 테스트 진행상황을 모니터링 하기 위한 적절한 측정방법을 제시한다. 
- 테스트 지원도구를 선정하고 사용자 교육 및 훈련을 계획한다.
- 테스트 수행과정에서 수집한 정보를 근거로 테스트 결과 보고서를 작성한다.

테스터의 역할과 임무
- 테스트 계획 및 테스트 전략을 리뷰한다.
- 테스트 명세를 작성한다.
- 테스트 환경을 구축한다.
- 테스트 구현, 실행 , 로그 기록 및 테스트 실행 결과 평가, 결함 보고의 임무를 수행한다.
- 테스트 명세서를 리뷰한다.

 

5.2 테스트 계획과 추정

5.2.1 테스트 계획 

테스트 계획 :  
- 테스팅 목적 , 테스트 범위 , 필요한 자원 , 일정을 결정하는 등의 업무를 수행하는 활동 
테스트 계획은 조직 차원의 테스트 정책 및 전략 , 테스트 범위 , 목적 , 제품의 리스크 , 프로젝트 리스크, 제약사항 , 심각성 , 테스트 용이성 , 자원의 가용성에 영향을 받는다. 

5.2.2 테스트 계획 활동 내용 

테스트 계획 활동 
- 테스트 범위와 리스크를 결정하고 테스팅의 목적을 식별한다. 
- 테스트의 총체적인 접근법을 정의한다. 
- 테스트 레벨과 각 테스트 레벨 별 시작과 종료 조건을 정의한다. 
- 테스팅 활동과 소프트웨어의 획독, 공급 , 개발 , 운영, 유지보수 단계의 수명주기 활동을 통합하고 조정한다. 
- 무엇을 테스트 하고, 누가 해당 테스트 활동을 수행하고, 어떻게 수행하고, 테스트 결과는 어떻게 평가할지를 결정한다. 
- 테스트 분석과 설계 일정을 계획한다. 
- 테스트 구현, 실행 및 평가의 일정을 계획한다. 
- 정의된 다양한 테스트 호라동에 자원을 할당한다. 
- 테스트 문서의 분량, 상세함의 정도 , 구조와 템플릿을 정의한다. 
- 테스트 준비와 실행 , 결함과 리스크 이슈를 모니터링하고 제어하기 위한 측정기준을 선정한다. 
- 충분한 정보를 제공하여 테스트 준비와 실행을 재현 가능하도록 테스트 프로시저의 상세 수준을 결정한다. 

5.2.3 완료조건 

- 코드 커버리지 , 기능 커버리지 , 리스크 커버리지와 같은 보장성 또는 충분함에 대한 측정치 
- 추정된 결함 밀도 또는 신뢰성 측정치 
- 잔존 리스크 
- 테스트 비용과 예산 
- 시장 출시 시기에 따른 스케줄 
- 수정되지 않은 결함 수 
- 시간당 결함 수 
- 재테스트 횟수 
- 모든 테스트 케이스를 1번 이상 수행하고 심각한 결함이 없거나 특정 수 이하일 때  
- 예방된 피해가 테스트 비용보다 적을 때 
- 위 테스트 완료 조건의 몇 가지 조합 

5.2.4 테스트 추정

메트릭 기반 접근법 : 과거 프로젝트나 유사 프로젝트의 메트릭을 근거로 또는 전형적인 가치를 근거로 테스트 노력 또는 업무량 예측
전문가 기반 접근법 : 전문가나 업무 수행 주체에 의한 예측
테스팅 활동의 비용, 노력 , 기간을 추정할 때 고려해야 할 요소
- 테스트를 시작할 수 있는 시점
- 테스트 용이성
- 개발자 및 관련자들의 숙련도
- 잠재 결함이 얼마나 많은가
- 개발자의 문제 해결 시간
- 테스트 환경의 가용성 및 안정성
- 테스트 웨어의 재사용성
- 제품의 특성 : 테스트 베이시스의 품질, 제품 사이즈 , 도메인 복잡성, 신뢰성 및 보안성 요구사항, 문서화 요구 등
- 개발 프로세스의 특성 : 조직의 안정성 , 도구 경험 여부 , 테스트 프로세스 , 투입 인력의 숙련도, 시간적 압박 정도
- 테스트 결과 : 발견된 결함 수와 요구되는 재 작업
- 리스크 수준 및 테스트 깊이 : 선택된 테스트 설계 기법, 테스트 케이스의 수

5.2.5 테스트 접근법, 전략

소프트웨어 테스트 접근법 또는 전략이란 테스트 레벨 , 유형 , 사람 , 도구 , 절차 , 방법 , 자원 등과 같은 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정하는 것을 의미
- 예방적 접근법 : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계한다.
- 사후적 접근법 : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계한다.
- 분석적 접근법 : 제품의 리스크 분석을 통해 집중적으로 테스팅해야 할 곳을 결정
<테스트 접근법>
- 모델 기반 : 테스트 케이스 설계를 소프트웨어 설계 모델을 근거로 작성하고 이를 현행화 하는 과정을 거쳐 실제 테스트 수행을 하도록 하는 접근법 또는 확률론적 테스팅을 통하여 장애율 통계를 바탕으로 설계하는 테스팅
- 방법론적 : 오류 추측 또는 장애 공격과 같은 장애 기반, 경험 기반 , 체크리스트 기반, 소프트웨어 품질특성 기반 테스팅
- 프로세스 및 표준 준수 : 산업 특화 표준 또는 다양한 애자일 개발 방법론에서 제시한 방법에 의한 테스팅
- 동적/발견적 :  실행과 평가가 동시에 이루어지는 테스팅
- 자문 기반 : 외부 전문가의 조언과 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅
- 리그레션 기피형 : 보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 슈트 등의 재상용을 통한 테스팅

 

접근법의 선택 시 고려해야 할 사항

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

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

- 테스팅 목적과 테스팅 팀의 임무

- 규정적 측면

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

 

5.3 모니터링과 제어

5.3.1 테스트 경과 모니터링

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

단계	메트릭(정보)	내용
분석 및 설계	케이스 작성 현황	계획된 테스트 케이스 작성 대비 작성 완료된 테스트 케이스
분석 및 설계	테스트 환경 준비 현황	테스트 환경 구축을 위해 준비해야 할 것들 중 준비 완료된 사항
테스트 실행	테스트 실행 현황	작성된 테스트 케이스 대비 실행 완료된 케이스 실행된 테스트 케이스 성공률 또는 실패율
테스트 실행	결함 현황	결함 밀도제품 사이즈 대비 발견된 결함 발견된 결함 대비 수정 완료된 결함 재 테스트 결과 , 장애 발생률 등
테스트 실행	커버리지 달성 현황	요구사항 커버리지, 기능 커버리지 리스크 커버리지 코드 커버리지
테스트 완료 조건 평가	확신	제품에 대한 테스터의 주관적 자신감 또는 확신
테스트 완료조건 평가	일정	테스트 마일스톤 일정
테스트 완료조건 평가	테스트의 가치	테스트를 계속하는 것에 대한 이득과 비용을 고려
테스트 완료	효율성	테스트 노력 대비 발견된 결함 수 테스트 노력 대비 테스트 커버리지 테스트 소요 시간
테스트 완료	효과성	테스팅 기간에 발견된 결함 대비 출시 후 발견된 결함

5.3.2 테스트 리포팅

보고서에 포함해야 할 요소
- 테스트 기간 동한 처리했던 주요 임무
 : ex> 테스트 완료 조건이 충족된 시점
- 향후 업무에 대한 의사결정을 지원할 만한 의미 있게 분석된 정보와 메트릭
 : 잔존 결함의 평가
  테스팅 수행의 경제적 이득
  부각된 리스크
  테스트된 소프트웨어에 대한 자신감의 정도

테스트 보고서를 계획하고 설계할 때 고려해야 할 요소
- 소프트웨어 제품 품질
- 테스트 생산성
- 소프트웨어 제품의 리스크
- 테스트 프로세스 품질

종료 보고서에서 다루는 내용
- 프로젝트 테스트 계획, 시스템 테스트 계획 , 성능 테스트 계획과 같은 테스트 계획 대비 차이
- 오픈되어 있는 제품 리스크와 예상되는 영향
- 해결되지 않은 결함과 그로 인해 예상되는 영향
- 시스템 파트의 현 상태와 커버된 리스크
- 테스트 프로세스 품질
- 테스트 프로젝트 수행 경험
- 다음번 테스트에 대한 조언

테스트 보고서 활용 
- 애플리케이션 출시 여부 결정
- 결함의 심각도 및 유형 파악
- 테스트 커버리지 확인
- 어플리케이션 품질 결정
- 다음 단계의 테스트를 위한 테스트 주요 요소 파악

5.3.3 테스트 제어

테스트 제어 활동
- 테스트 모니터링으로부터 얻은 정보를 기반으로 의사 결정을 한다.
- 프로젝트 리스크가 실제 발생하였을 때 테스트의 우선순위를 조정한다.
- 테스트 환경의 가용성 이슈가 있을 경우 테스트 일정을 변경한다.
- 수정사항을 빌드에 반영하기 전에 해당 수정 사항을 개발자가 재테스트하도록 요구하는 것과 같은 테스트 시작 조건을 정한다.

5.3.4 테스트 완료

테스트 완료 활동
- 테스트 계획서 , 자동화 테스트 절차 및 매뉴얼, 테스트 환경 구성도 등과 같은 테스트 자산을 식별하고, 형상관리 등을 통해 보존한다.
- 테스트 환경을 다음 단계의 사용자를 위해서 정제한다.
- 테스팅 활동 전반의 문제점 및 개선점을 찾아 교훈으로 기록한다.
- 테스트 완료 보고서에 계획 대비 실적, 결함 상태 , 리스크 등과 함께 테스트 자산의 보존 상황 및 교훈을 기록하고 이를 이해관계자에게 보고한다.

 

5.4 형상 관리 

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

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

5.5 리스크와 테스팅 

 리스크는 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성과 발생했을 경우의 바람직하지 못한 결과 즉, 잠재적인 문제로 정의될 수 있다. 리스크 수준은 의도하지 않은 이벤트가 발생될 가능성과 그 영향에 의해 결정된다. 

5.5.1 프로젝트 리스크 

조직적인 요소 
- 테스트 전문 스킬과 인력의 부족 
- 개인적 이슈와 교육훈련 관련 이슈 
- 다음과 같은 정치적인 이슈 

 1. 테스터가 자신의 요구와 테스트 결과를 커뮤니케이션하는 데 있어서의 문제 
 2 테스팅과 리뷰에서 발견된 정보를 개발 프로젝트에 반영하는 것에 실패 
- 테스팅에 대한 비현실적 태도와 기대치 

 

기술적 이슈 
- 완성도 높은 요구사항을 정의하는 데 있어서의 문제 
- 기 제약조건 하에서 요구사항이 수용되는 정도 
- 설계 , 코드 , 테스트의 품질 

 

공급자 이슈 
- 공급자인 제삼자 협력업체가 역할 수행에 실패 
- 계약상의 이슈 

5.5.2 제품 리스크

소프트웨어나 시스템에서 의도하지 않은 향후 이벤트나 위험 요소가 존재하는 잠재적인 장애영역을 제품 리스크라 한다.

잠재적 장애 영역
- 개발팀에서 전달받은 장애 가능성이 높은 소프트웨어
- 소프트웨어 및 하드웨어가 개인이나 회사에 손실을 끼칠 가능성
- 취약한 소프트웨어 특성 : 기능성, 신뢰성, 사용성, 성능
- 의도된 기능을 수행하지 못하는 소프트웨어

리스크 기반 접근법에서 식별된 리스크는 다음과 같이 사용될 수 있다.
- 사용할 테스트 기법 결정
- 테스트 수행 범위 결정
- 심각한 결함을 조기에 발견하기 위해 테스트의 우선순위 결정
- 테스트와 관련되지는 않았지만 리스크를 줄이기 위해 필요한 활동(경험이 적은 개발 설계자에게 교육훈련 제공 등)을 수행해야 할지 결정
- 리스크가 높은 부분에 개발 또는 품질 관련 교육을 적절하게 제공하여 미래의 리스크를 줄일 수 있음
리스크 관리 활동은 다음과 같이 체계적으로 접근하여 프로젝트 실패의 가능성을 최소화
- 잘못될 수 있는 것을 평가하고 정기적으로 재평가한다.
- 어떤 리스크가 중요시되어야 하는지 결정한다.
- 리스크 수준에 맞게 적절하게 대응한다.
리스크 기반 테스팅 접근법을 실무에서 사용하는 방법은 매우 다양한데, 대부분 다음과 같은 공통점이 있다.
- 테스트 레벨 별로 파악한 여러 가지 리스크 영역 또는 요소에 리스크(장애 가능성 x영향)를 부여
- 주어진 시간과 자원을 고려하여 리스크 높은 부분을 우선적으로 공식적인 기법을 적용하고 경험적인 테스트 케이스도 충분히 확보하여 강력하게 테스팅
- 리스크가 낮은 부분은 시간이 허용하는 범위에서 자유롭게 테스팅을 진행하는 것이 일반적임

리스크 기반 테스트 전략 수립
1. 리스크 식별 : 테스트 대상을 리스크 분석 단위인 아이템으로 분류하고 식별
2. 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석
3. 결국, 장애 발생 빈도와 장애로 인한 영향을 식별
4. 리스크의 우선순위를 결정
  a. 장애 발생 빈도 ↑ , 장애로 인한 영향 ↑ : 반드시 테스트해야 함
  b. 장애 발생 빈도 ↑ , 장애로 인한 영향 ↓ : 테스트함
  c. 장애 발생 빈도 ↓ , 장애로 인한 영향 ↑ : 테스트해야 함
  d. 장애 발생 빈도 ↓ , 장애로 인한 영향 ↓ : 테스트하지 않을 수 있음
5. 리스크 계획 활동 : 리스크 정보를 근거로 대처 방안 수립
  a. 공식적 테스트 설계 , 경곗값 분석 , 구문 커버리지 90% , 완전한 코드 인스펙션
  b. 구문 커버리지 70% , 페어 인스펙션
  c. 구문 커버리지 70%
  d. 기회 되면 자유롭게 테스팅 
6. 리스크 추적 : 리스크 완화 활동에 대한 모니터링 및 제어

5.6 인시던트 관리 

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

인시던트 리포트의 목적 
- 개발자와 프로젝트 관련자에게 문제점을 식별하고, 격리하고, 필요하면 정정하도록 피드백을 제공 
- 테스트 리더에게 시스템의 품질 또는 테스트 진척을 추적할 수 있는 정보를 제공 
- 테스트 프로세스 개선에 대한 아이디어 제공 

인시던트 리포트의 내용 
- 이슈 발생 날짜 , 이슈를 제기한 조직 , 작성자 
- 기대 결과와 실제 결과 
- 테스트 항목과 환경의 식별 
- 소프트웨어나 시스템의 수명주기에서 인시던트가 발견된 시점 
- 로그, 데이터베이스 덤프 , 화면 덤프 등을 포함한 인시던트 재현이 가능한 상세 설명 
- 이해관계자의 이익에 영향을 주는 범위 또는 정도 
- 결함이 시스템에 미치는 심각도  
- 수정 우선순위
- 인시던트의 상태 : 오픈, 보류, 중복, 수정 대기, 수정 완료 , 종료 
- 결론, 의견 , 승인 여부 
- 관련 이슈 : 인시던트로 인한 변경이 영향을 줄 수 있는 다른 영역 
- 변경 이력 : 인시던트를 격리하고, 수정하고, 수정 여부를 확인하는 등의 활동을 순서대로 기록 
- 참조 사항 : 관련된 테스트 케이스 식별 정보 

 

5.7 테스트 프로세스 평가 

테스트 프로세스 평가의 필요성
- 정렬되고 조직화되며 반복적이 된다.
- 전문적이고 공학적인 활동으로 인식된다.
- 개발 활동과는 독립적으로 수행한다.
- 결함 발견 활동에서 결함 예방 활동으로 변화된다.
- 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악하게 된다.
- 지속적으로 개선되고 향상된다.
- 테스트 비용을 절감시키고 조직 구성원의 만족감을 고취시킨다

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

 

Related References

-  도서 : 개발자도 알아야 할 소프트웨어 테스팅 실무

 

ISTQB

요약 : iso 표준, 국제 표준 iso, 국내 표준, 표준, istqb, kstqb, 웹 qa, 모바일 qa, 앱 qa, test web