[ISTQB] 제 5장 테스트 관리

5.1 테스트 조직

5.1.1 독립적인 테스팅

(1) 독립적인 테스터 없음 -> 개발자 본인이 직접 테스트

(2) 개발팀이나 프로젝트팀에 속한 독립적인 개발자/테스터

(3) 조직 내 독립적 테스트팀이나 그룹이 프로젝트 관리자/상위 관리자에게 직접 보고

(4) 비즈니스 조직/사용자 커뮤니티 소속/특정 테스트 분야를 전문으로 하는 독립적인 테스터

(5) 현장 또는 현장 외에서 일하는 조직 외부의 독립적인 테스터

>어떻게 구현할지는 소프트웨어 개발 생명주기 모델(https://deepdeep-blue.tistory.com/4)에 따라 다르다. 

>>잠재적 이점<<

(1) 개발자와는 다른 유형의 장애를 찾아낼 수 있다.

(2) 이해관계자가 만든 가정에 대해 확인, 이의 제기, 틀렸음을 입증할 수 있다.

(3) 벤더(vendor)의 독립 테스터는 회사의 압박없이 객관적으로 보고할 수 있다.

>>단점<<

(1) 개발팀과의 협업이 어려울 수 있다.

(2) 개발자가 품질에 대한 책임감을 잃을 수 있다.

(3) 독립적인 테스터가 병목 현상의 장본인으로 비쳐질 수 있다.

(4) 독립적인 테스터는 중요한 정보를 전달받지 못할 수 있다.

 

5.1.2 테스트 관리자 및 테스터의 역할

(1) 테스트 관리자 : 소프트웨어 개발 수명주기의 영향을 받는다. 경우에 따라 테스트 코치라고도 한다.

(2) 테스터 : 제품과 프로젝ㅌ트의 리스크/선택한 소프트웨어 수명주기 모델에 따라 테스트 레벨별 역할 다를 수 있다.

 

5.2 테스트 계획과 추정

5.2.1 테스트 계획과 목적과 내용

 : 개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용을 담고 있음. 

 

5.2.2 테스트 전략과 테스트 접근법

(1) 분석적(Analytical) : 특정 요소에 대한 분석을 기반으로 한 전략 ex.리스크 기반 테스팅

(2) 모델 기반(Model-Based) : 요구되는 제품의 특정 측면에 대한 모델을 기반으로 한 전략

(3) 방법론적(Methodical) : 사전에 정의한 테스트셋/테스트 컨디션을 체계적으로 사용하는 데 의존 ex.전사 룩앤필 표준

(4) 프로세스 준수(Process-compliant, standard-compliant) : 외부 규정/표준을 기반으로 테스트를 분석, 설계, 구현

(5) 전문가 조언(Directive, Consultative) : 이해관계자, 비즈니스 도메인 전문가 등의 조언, 지도, 지시를 바탕.

(6) 리그레션-기피(Regression-averse) : 기존 기능에 대한 리그레션 테스트 기피를 목표. 기존 테스트웨어의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함

(7) 반응적(Reactive) : 테스트 대상 컴포넌트나 시스템, 테스트 실행 중 발생하는 이벤트에 따라 대응

 

>위 전략의 일부를 조합해 적절한 테스트 전략을 구성. ex)리스크 기반 테스팅 + 탐색적 테스팅

>>테스트 전략 : 테스트 프로세스를 종합해 개괄적으로 설명

>>테스트 접근법 : 테스트 기법, 테스트 레벨, 테스트 유형을 선택하는 출발점

 

5.2.3 시작 조건과 종료 조건(준비의 정의와 완료의 정의)

(1) 시작 조건 : (애자일개발에서는 '준비의 정의')특정 테스트 활동을 시작하기 위해 정의한 사전 조건

 -테스트 가능한 요구사항, 사용자 스토리나 모델의 가용여부

 -이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부

 -테스트 환경 가용 여부

 -필요한 테스트 도구 가용 여부

 -테스트 데이터와 기타 필요한 자원의 가용 여부

(2) 종료 조건 : (애자일개발에서는 '완료의 정의')특정 테스트 레벨이나 테스트셋이 끝났음을 선언하기 위해 만족해야 할 조건

 -계획한 테스트 실행 완료

 -정의한 커버리지 수준의 도달

 -해결하지 못한 결함 수가 합의된 수보다 적음

 -추정 잔존 결함의 수가 충분히 적음

 -신뢰성, 수행 효율성, 사용성, 보안성, 기타 품질 특성의 수준이 원하는 수준에 도달

>종료 조건을 충족하지 못해도 기타 상황에 따라 조기 종료하는 경우 있음

 

5.2.4 테스트 실행 일정(Test Execution Schedule)

 : TC, 테스트 프로시저 작성하고 이를 조합해 테스트 스위트를 생성한 후 그 순서를 정해 일정을 구성한다.

 : 우선순위, 종속 관계, 확인 테스트, 리그레션 테슽트, 가장 효율적인 테스트 실행 순서 등을 고려해야 한다.

 

5.2.5 테스트 노력에 영향을 미치는 요소

(1) 제품 특성

(2) 개발 프로세스 특성

(3) 인력 특성

(4) 테스트 결과

 

5.2.6 테스트 추정 기법

(1) 메트릭 기반 기법 : 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측

  >애자일 개발의 번다운 차트(Burndown charts)

  >순차적 개발의 결함 제거 모델(Defect Removal Models)

(2) 전문가 기반 기법 : 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측

  >플래닝 포커(Planning poker)

  >와이드밴드 델파이(Wideband Delphi) 추정 기법

 

5.3 테스트 모니터링과 제어

 : [목적] 정보 수집 및 테스트 활동에 대한 피드백 및 가시성 제공

 : 테스트 종료 조건(제품 리스크 커버리지, 요구사항 커버리지, 인수 기준)/완료의 정의와 관련된 테스팅 작업 만족 측정

 >테스트 제어 활동<

(1) 식별한 리스크 발생 시 테스트 우선순위의 변경

(2) 테스트 환경이나 기타 자원의 가용 여부에 따른 테스트 일정 변경

(3) 재작업으로 인해 테스트 항목이 시작/종료 조건 만족하는지 재평가

 

5.3.1 테스팅에 사용하는 메트릭

5.3.2 테스트 보고의 목적, 내용, 독자

 : [목적] 테스트 활동 중이나 마무리 시점의 테스트 활동 정보 요약과 공유

 : [내용(일반)] 테스트 계획 대비 테스트 활동과 진행 상황, 진행을 방해하는 요소, 다음 보고 기간에 진행하기로 계획한 테슽팅, 테스트 대상의 품질 

 

5.4 형상 관리(Configuration Management)

: 프로젝트와 제품 수명주기 동안 컴포넌트나 시스템, 테스트웨어와 이들 서로간의 관계 통합을 수립 및 유지

 - 모든 테스트 항목에 고유 식별번호 부여, 버전 관리, 변경 이력 기록

 - 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

 

5.5 리스크와 테스팅

5.5.1 리스크의 정의

 : 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성 -> 이벤트 발생 가능성과 그로 인한 영향도

 

5.5.2 제품 및 프로젝트 리스크

 : [품질 리스크]제품 리스크가 제품의 특정 품질 특성과 연관되는 경우

 : [프로젝트 리스크]발생하면 프로젝트 목적 달성 능력에 부정적인 영향을 줄 수 있는 상황

 

5.3.3 리스크 기반 테스팅과 제품 품질 

 

5.6 결함 관리