1.2.2 품질 보증과 테스팅

품질이란 컴포넌트, 시스템, 또는 프로세스가 명시된 요구사항이나 사용자/고객의 필요와 기대를 만족하는 정도이다.

품질 관리는 품질 보증과 품질제어를 포함한 여러가지 활동을 포함하는 용어이다.

품질 보증은 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점을 두고있다. 품질 제어는 테스팅 활동이 포함.

 

 

1.2.3 오류, 결함,장애

사람 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시키는 오류(실수)를 범할 수 있다.

특정 작업 산출물 내 결함의 원인이 되는 오류는 연관된 다른 작업 산출물의 결함의 원인이 되는 또 다른 오류의 계기가 될 수 있다.

 

결함의 근본 원인이란 해당 결함을 생성하는데 기여한 최초의 해동이나 조건을 지칭한다. 결함을 분석함으로써 근본 원인을 찾을 수 있으며, 차후 유사한 결함의 발생 가능성을 낮출수 있다.

 

예를 들어, 단 한줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만을 초래한다. 제품 소유자가 이자 계산법을 잘못 이해해서 작성한 애매모호한 사용자 스토리를 기반으로 코드가 잘못 작성 되었다.

 

이 예제에서 결과는 소비자 불만이며 장애는 잘못된 이자 지급이다. 결함은 코드에 포함된 잘못된 계산식이며, 그것의 원인이 되는 최초의 결함은 사용자 스토리의 모호성이다. 최초 결함의 근본 원인은 제품 소유자의 지식 부족이였으며, 그 결과로 제품 소유자가 사용자 스토리를 작성할 때 오류를 범했다고 볼 수 있다. 

 

Ex) C-Q3

A. 시스템 개발자가 잘라 붙이기 후 변경된 부분에 대한 이름 수정을 잊어 버렸다. (오류,실수)

B. 후진 시 경고음을 울리는 불필요한 코드가 시스템에 들어갔다. (결함)

C. 라디오 볼륨을 키우거나 줄일 때 시스템이 설정 속도를 유지하지 못한다. (장애)

D. 시스템의 설계 명세에 Km/h 속도 단위가 잘못 표기되었다. (결함) 

 

1.4 테스트 프로세스

모두가 사용하는 일반적인 테스트 프로시저는 없지만, 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트는 존재한다. 이런 테스트 활동 세트를 테스트 프로세스라 한다.  

 

테스트 프로세스에 속하는 테스트 활동과 이런 활동을 어떻게 구현할지, 또 이런 활동을 언제 수행할지에 대한 내용은 조직의 테스트 전략에서 다룰수 있다.

 

1.4.2 테스트 활동과 작업 

  • 테스트 계획 - 계획 ( 일정, 테스팅 접근법,..)
  • 테스트 모니터링과 제어 ( 상황진행보고서, 요약보고서등)
  • 테스트 분석 - 베이시스 평가, 테스트 컨디션 우선순위
  • 테스트 설계 - 테스트 데이터 식별, 인프라와 도구 식별 , 테스트 환경 설계 , 테스트 케이스와 테스트 세트
  • 테스트 구현 - 테스트 데이터 생성 , 테스트 프로시저
  • 테스트 실행 - 결함 보고서
  • 테스트 완료 - 보고서, 

 - 테스트 계획 : 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동을 포함한다. 예를 들어, 적합한 테스트 기법과 작업 명시, 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립 등이 여기에 포함된다.

 

5.2 테스트 계획과 추정

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

 - 계획에 영향을 주는 요소

  • 조직의 테스트 정책
  • 테스트 전략
  • 사용하는 개발 수명주기 및 방법
  • 테스팅의 범위
  • 목적
  • 리스크
  • 제약
  • 심각도
  • 테스트 용이성
  • 자원의 가용성

 - 테스트 계획서 기록 내용

  • 테스팅의 범위 정의, 목적, 리스크 결정
  • 전반적인 테스팅 접근법 정의
  • 테스트 활동을 소프트웨어 수명주기 활동에 통합하고 조정
  • 테스트 대상 다양한 테스트 활동에 필요한 인력과 기타 자원, 테스트 활동 수행 방법 결정
  • 테스트 분석, 설계, 구현, 실행, 평가 활동의 일정 조정. 일정은 특정 날짜나 반복주기 단위로 편성할 수 있다.
  • 테스트 모니터링과 제어에 사용할 메트릭 선정
  • 테스트 활동 예산 결정
  • 테스트 문서의 구조와 상세화 정도 정의

 

------------------------------------------------------------

  • 작업 산출물 : 테스트 계획(베이시스에 대한 정보)

 

- 테스트 모니터링과 제어 : 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척상황과 지속적으로 비교하는 활동을 말한다.

테스트 제어는 테스트 계획에 따른 목적 달성을 위해 필요한 행동을 취하는 활동을 포함한다. 

테스트 모니터링의 목적은 정보 수집 및 테스트 활동에 대한 피드백과 가시성 제공이다. 모니터링 대상 정보는 수동 혹은 자동으로 수집할 수 있고, 테스트 진행상황을 평가하는 데 활용한다. 그리고 테스트 종료 조건(예: 제품 리스크 커버리지, 요구사항 커버리지, 인수 기준)을 만족하는지 또는 애자일 프로젝트에서 완료의 정의와 관련된 테스팅 작업을 만족하는지 측정하는 데 이용한다.

 

테스트 제어 활동의 예는 

  • 식별한 리스크(예: 소프트웨어 인도 지연) 발생 시 테스트 우선순위의 변경
  • 테스트 환경이나 기타 자원의 가용 여부에 따라 테스트 일정 변경
  • 재작업으로 인해 테스트 항목이 시작 조건이나 종료 조건 만족하는지 재 평가 
  • 작업 산출물 : 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서

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

테스팅 활동 중이나 종료 시점에 아래와 같은 사항을 평가하기 위해 메트릭을 수집할 수 있다. 

  • 계획한 일정과 예산 대비 진행 상황
  • 테스트 대상의 현재 품질
  • 테스트 접근법의 타당성
  • 목적 대비 테스트 활동의 효과 

 

일반적인 테스트 메트릭은 다음과 같다.

  • 계획 대비 테스트 케이스 준비 작업 완료율(또는 계획 대비 테스트 케이스 작성률)
  • 계획 대비 테스트 환경 준비 작업 완료율
  • 테스트 케이스 실행률(예: 수행한/수행하지 않은 테스트 케이스 수 , 테스트 케이스 합격/불합격 수, 테스트 컨디션 합격/불합격 수)
  • 결함 정보( 예: 결함 밀도, 발견한 결함, 수정한 결함, 실패율, 확인 테스트 결과)
  • 요구사항 커버리지, 사용자 스토리 커버리지, 인수 기준 커버리지, 리스크 커버리지, 코드 커버리지
  • 작업 완료, 자원 할당과 사용, 노력
  • 다음 결함을 발견하면 얻는 이익 대비 비용이나 테스트를 계속 실행해 얻게 되는 이익 대비 비용 등을 포함하는 테스팅 비용

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

테스트 보고의 목적은 테스트활동(예: 테스트 레벨) 중이나 마무리 시점의 테스트 활동 정보 요약과 공유이다.

테스트 보고서(테스트 진행 상황 보고서, 요약보고서(테스트 활동 종료시점에 작성) ( 테스터 관리자 작성)

- 테스트 진행 보고서에 들어가는 정보

  • 테스트 계획 대비 테스트 활동과 진행 상황
  • 진행을 방해하는 요소
  • 다음 보고 기간에 진행하기로 계획한 테스팅
  • 테스트 대상의 품질

- 테스트 요약 보고서에 들어가는 정보(종료 조건 만족시)

  • 테스트 수행 내용 요약
  • 테스트 기간 도중에 발생한 상황 정보
  • 계획 대비 편차(예: 일정, 기간, 테스팅 활동 노력)
  • 종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질
  • 진행을 방해했거나 계속해서 방해하고 있는 요소
  • 메트릭(5.3.1에 설명한 결함, 테스트 케이스, 테스트 커버리지, 활동 진행 상황, 소비한 자원)
  • 잔존 리스크
  • 재사용 가능한 테스트 작업 산출물'

5.4 형상 관리

형상 관리의 목적은 프로젝트와 제품 수명주기 동안 컴포넌트나 시스템, 테스트웨어와 이들 서로간의 관계 통합을 수립하고 유지하는 데 있다. 형상 관리는 테스팅을 적절히 지원하고자 아래 내용을 확인한다.

  • 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
  • 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할수 있게 한다.
  • 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

테스트 계획을 수립하면서 형상관리 절차와 인프라(도구)를 식별하고 구현해야 한다.

----------------------------------------------------------------------------------------------------------------

- 테스트 분석 : 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석하고 평가한다.

테스트 분석의 주요 활동

  • 고려중인 테스트 레벨에 적합한 테스트 베이시스 평가
  • 컴포넌트나 시스템의 기능, 비기능, 구조 측면을 고려한 리스크 분석 보고서
  • 테스트 베이시와 테스트 항목을 평가해서 다양한 형태의 결함 식별
  • 테스트할 기능과 기능세트 식별
  • 테스트 베이시스를 평가하고 기능, 비기능, 구조 특성 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션 정의 및 우선순위 선정
  • 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착

*작업 산출물

  • 우선수위가 선정된 테스트 컨디션

------------------------------------------------------------------------------------------------------------------

테스트 설계 - 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어를  생성한다. 

테스트 설계의 주요 활동

  • 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정
  • 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별 ***************
  • 테스트 환경 설계와 필요한 인프라 도구 식별  ****************
  • 테스트 베이시스 , 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정

*작업 산출물 

  • 테스트 케이스와 테스트 케이스 세트
  • 필요한 테스트 데이터의 설계나 식별
  • 테스트 환경 설계
  • 인프라와 도구의 식별

-------------------------------------------------------------------------------------------------------------------

테스트 구현 : 테스트 구현 중 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트 프로시저를 만드는 것도 여기에 포함된다.

테스트 구현에 주요 활동

  • 테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성
  • 테스트 프로시저와(있다면) 자동 테스트 스크립트로부터 테스트 스위트 생성
  • 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치
  • 테스트 환경 구축, 가능하다면 테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인
  • 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인
  • 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로 간의 양바향 추적성 검증과 업데이트

*작업 산출물

  • 테스트 프로시저와 이 프로시저의 배열
  • 테스트 스위트
  • 테스트 실행 일정

--------------------------------------------------------------------------------------------------------------------

- 테스트 실행 : 테스트 스위트를 테스트 실행 일정에 따라 실행한다.

테스트 실행의 주요 활동

  • 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
  • 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
  • 기대 결과와 실제 결과 비교
  • 이상 현상을 분석해 원인 파악
  • 관찰한 장애를 기반으로 결함 보고
  • 테스트 실행 결과 기록
  • 이상 현상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복
  • 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성과 검증 업데이트

*작업 산출물

  • 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서
  • 결함 보고서
  • 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한 문서 

---------------------------------------------------------------------------------------------------------------------

- 테스트 완료 : 완료한 테스트 활동에 서 데이터를 수집해서 경험, 테스트웨어 기타 관련 정보를 축적하는 활동이다. 테스트 완료 활동은 소프트웨어 시스템을 릴리스 했을 때 테스트 프로젝트를 완료 했을때 등 일어난다.

테스트 완료의 주요 활동

  • 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인
  • 이해관계자에게 전달할 테스트 요약 보고서 생성 
  • 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관
  • 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계
  • 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 분석주기, 릴리스, 또는 프로젝트를 위해 수정해야 하는 사항 판단
  • 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용

 

1.4.4 테스트 베이스와 테스트 작업 산출물 간의 추적성

- 좋은 추적성은 테스트 커버리지에 대한 평가를 가능하게 한다.

- 수정으로 인한 영향 평가를 가능하게 한다. ( 리그레션 테스팅)

- 테스팅에 대한 감사(audit)를 가능하게 한다. (테스트 실행의 완전성 평가)

- IT 통제 조건을 충족할 수 있게 한다.

- 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행 상황 보고서와 테스트 요약 보고서를 좀     더 쉽게 이해할 수 있게 한다. 

- 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달한다.

- 비지니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.

 

 

2.3 테스트 유형

테스트 유형이란 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합을 얘기한다. 대표적인 목적

  • 완전성, 정확성, 적합성 등과 같은 기능 품질 특성 평가 -> 기능 테스트
  • 신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등과 같은 비기능 품질 특성 평가 -> 비기능 테스트
  • 컴포넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
  • 수정의 효과 평가. 예를 들어, 결함이 수정됐는지 확인(확인 테스팅)하고, 소프트웨어나 환경의 변화로 인해 동작에 의도하지 않은 변화가 없는지 평가(리그레션 테스팅)

테스트 유형에는 기능 테스트 , 비기능 테스트 , 화이트박스 테스팅 , 변경 관련 테스팅 , 유지보수 테스팅

 

- 변경 관련 테스팅 - 리그레션 테스팅 , 확인 테스팅

 - 확인 테스팅 - 결함으로 인한 수정후 확인하는 테스트

 - 리그레션 테스팅 - 의도하지 않은 부작용을 발견하기 위해 하는 테스트 

 

- 영향도 분석 - 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과뿐만 아니라 변경으로 인해 발생할 수 있는 예    견된 부작용을 식별하고, 변경의 영향을 받는 시스템 영역을 식별하기 위해 식별한다. 

  영향도 분석은 변경이 기존 테스트에 미치는 영향을 식별하기 위해 사용할 수 있다.( 리그레션 테스팅에 유리하다)

 

4. 테스트 기법

 테스트 기법의 목적은 테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을 지원하는 것이다. 

 

테스트 기법의 선택

  • 컴포넌트나 시스템의 복잡도
  • 규제 기준
  • 고객 또는 계약 요구사항
  • 리스크 수준과 유형
  • 사용 가능한 문서
  • 테스터의 지식과 역량
  • 사용 가능한 도구
  • 시간과 예산
  • 소프트웨어 개발 수명주기 모델
  • 컴포넌트나 시스템에서 예상되는 결함 유형 

4.1.1 테스트 기법의 종류와 특성

블랙박스, 화이트박스, 경험기반으로 분류

 

- 블랙박스 테스트 기법 : 적절한 테스트 베이시스(예 : 공식 요구사항 문서, 명세서, 유스 케이스, 사용자 스토리 또는 비    지니스 프로새스)에 대한 분석을 기반으로 한다. 테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중한다.

* 특징 

  • 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로 부터 도출한다.
  • 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용환다.
  • 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정한다.

- 화이트박스 테스트 기법 : 아키텍처, 세부 설계, 내부 구조, 구조, 테스트 대상의 코드에 대한 분석을 기반으로 한다. 테스트 대상의 내부 구조와 처리에 집중한다.

* 특징

  • 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍쳐, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다.
  • 커버리지는 선택한 구조내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준응로 측정한다.

- 경험 기반 테스트 기법 : 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행한다.

* 특징

  • 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과 경험과 같은 테스트 베이이스로 부터 도출한다.
  • 지식과 경험은 소프트웨어의 예상 동작과 사용 환경, 발생 가능성이 있는 결함과 분포 등을 포함한다. 

4.4 경험 기반 테스트 기법( 헷깔림..)

경험 기반 테스트 기법을 적용할 경우 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한 애플리케이션과 기술에 대한 경험을 기반으로 도출한다.

 

 - 오류 추정

 테스터의 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는 기술이며 다음을 포함한다.

  • 애플리케이션의 과거 동작
  • 발생하기 쉬 오류의 유형
  • 다른 애플리케이션에서 발생한 장애 

- 탐색적 테스팅 **************************************

탐색적 테스팅에서는 비공식 테스트를 테스트 실행중에 동적으로 설계, 실행, 기록하고 평가한다.

테스터가 테스트를 수행할 때 테스트 설계를 적극적으로 제어하고 새롭고 더 나은 테스트 설계를 위해 테스트 하는 동안 얻은 정보를 사용하는 비공식적인 테스트 기법.!

 

- 체크리스트 기반 테스팅 ****************************************

체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다.

 

구체적인 테스트 케이스가 없는경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다.

 

 

 

3.1 정적 테스팅 기초

정적 테스팅은 작업 산출물을 수동으로 검사( 예 : 리뷰) 하거나 코드나 다른 작업 산출물을 도구를 기반으로 평가( 예 : 정적 분석)하는 방법에 의존한다.

 

3.1.1 정적테스팅으로 검토할 수 있는 작업 산출물

 

  • 비즈니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
  • 에픽(epic), 사용자 스토리, 인수 기준
  • 아키텍처 및 설계 명세
  • 코드
  • 테스트 계획, 테스트 케이스(테스트 설계 산출물), 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어 ( 테스트 구현 산출물)
  • 사용자 가이드
  • 웹 페이지
  • 계약, 프로젝트 계획, 일정, 예산 기획 
  • 형상(configuration) 및 인프라(infrastructure) 셋업
  • 액티비티 다이어그램과 같은 모델 기반 테스팅에 사용되는 모델 

- 정적 테스팅 효과

 

  • 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정 ( 결함 수정은 디버깅)
  • 동적 테스팅으로 발견이 쉽지 않은 결함 식별
  • 요구사항 불일치, 애매 모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계나 코딩의 결함 예방
  • 개발 생산성 향상 (예: 설계 개선, 향상된 코드 유지보수성)
  • 개발 비용 및 기간 단축 
  • 테스팅 비용 및 기간 단축
  • 수명주기 후반 또는 출시 후 운영 과정에서 발견되는 장애 감소로 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
  • 리뷰에 참여하는 팀원 간의 의사소통 개선

- 결함 유형

  • 요구사항 결함 (예: 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
  • 설계 결함 (예: 비효율적인 알고리즘(algorithm)이나 데이터베이스 구조, 높은 결합도(coupling), 낮은 응집도(cohesion)) 등
  • 코딩 결함 (예: 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
    표준과의 차이 (예: 코딩 표준 미준수 등)
  • 잘못된 인터페이스 명세 (예를 들어, 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
  • 보안 취약점 (예를 들어, 버퍼 오버플로우에 대한 취약성) 
  • 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성 (예를 들어, 특정 인수 조건에 대한 테스트 누락)

3.2 리뷰 프로세스

 

계획

  • 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
  • 노력과 기간 추정
  • 리뷰 유형에 따라 결정되는 역할 , 활동, 체크리스트와 같은 리뷰 특성의 식별
  • 리뷰에 참석할 인원을 선정하고 역할 할당
  • 인스펙션과 같은 보다 공식적인 리뷰에 경우에는 시작 및 종료 조건정의
  • 시작 조건이 충족되는지 확인

리뷰착수

  • 작업 산출물과 이슈기록 양식, 체크리스트, 관련된 작업 산출물 등 배포
  • 참가자에게 범위, 목적 ,프로세스,역할 작업산출물을 설명
  • 참가자가 리뷰에 대해 가질수 있는 여러 질문에 답변

개별 리뷰

  • 작업 산출물 전체 혹은 부분 리뷰
  • 잠재 결함, 권고사항, 질문기록

이슈 논의 및 분석

  • 식별한 잠재 결함 전달
  • 잠재 결함 분석 및 담당자 및 상태 할당
  • 품질 특성 평가 및 문서화
  • 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정

 

수정 및 보고

  • 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
  • 리뷰할 작업 산출물에서 발견한 결함 수정(저자가 수정)
  • 결함 정보를 적절한 사람이나 팀과 공유
  • 메트릭 수집
  • 종료 조건의 충족여부 확인
  • 종료 조건이 충족되면 해당 작업 산출물 인수

3.2.2 공식 리뷰에서의 역할과 책임

 

저자 ( 워크쓰루에서 회의를 주도한다) 

 - 리뷰 대상 작업 산출물 작성

 - 리뷰 대상 작업 산출물 결함 수정

 

관리자

 - 리뷰 계획 담당

 - 리뷰 실행 결정

 - 인력, 예산, 시간 할당

 - 진행 비용 대비 효과 모니터링

 - 결과가 만족스럽지 않은 경우 제어 결정 실행

 

촉진자 ( 기술리뷰, 인스펙션에서 회의를 주도한다.)

 - 리뷰 회의 진행 시 효과적 진행 보장

 - 필요한 경우 다양한 관점들에 대해 중재

 - 많은 경우 리뷰 성공의 여부에 결정적인 역할을 하는 사람

 

리뷰 리더

 - 전반적으로 리뷰에 대한 책임을 지는 사람

 - 참여자를 결정하고 언제 어디서 진행할지 결정

 

검토자 (테스터 포함)

 - 해당 주제에 대한 전문가, 프로젝트 참여인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술 혹은 비지니스 배     경을 가진 사람등

 - 리뷰 대상 작업 산출물의 잠재적 결함 식별

 - 다양한 관점을 대표할 수 있음

 

서기 (대부분의 리뷰에 필수 비공식빼고)

 - 개별 리뷰 활동에서 발견한 잠재 결함 수집

 - 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록

 

6.1 테스트 도구 고려 사항

 

테스팅 및 테스트웨어 관리 지원 도구

 - 테스트 관리 도구와 애플리케이션 수명주기 관리 도구

 - 요구사항 관리 도구

 - 결함 관리 도구

 - 형상 관리 도구

 - 지속적인 통합 도구

 

정적 테스팅 지원 도구

 - 정적 분석 도구( 개발자 지원 , 리뷰) 

 

테스트 설계 및 구현 지원 도구

 - 모델 기반 테스팅 도구

 - 테스트 데이터 준비 도구 

 

테스트 실행 및 로깅 지원 도구 

 - 테스트 실행 도구 ( 예 : 리그레션 테스트 수행)

 - 커버리지 도구 ( 예 : 요구사항 커버리지 , 코드 커버리지)

 - 테스트 하네스 

 

성능 측정과 동적 분석 지원 도구

 - 성능 테스팅 도구

 - 동적 분석 도구

 

'자격증 > ISTQB' 카테고리의 다른 글

[ISTQB] CTFL 합격 후기!  (2) 2020.06.30
[Part 6] 테스트 지원 도구  (0) 2020.06.14
[Part 5] 테스트 관리  (0) 2020.06.14
[part 3] 정적 테스팅  (0) 2020.06.11
[Part 2] 소프트웨어 수명주기와 테스팅  (0) 2020.06.08

+ Recent posts