실라버스 제 5 장. 테스트 관리

5.1 테스트 조직

 

- 테스팅 작업은 특정 테스팅 역할을 부여 받은 사람 or 다른 역할을 하는 살마도 수행할 수 있음 (예 : 고객)

- 저자와 테스터가 가지는 인지편향(1.5절)의 차이 -> 일정 수준의 독립성은 테스터가 결함을 더 효과적으로 찾게 해 줌

- 독립성이 친숙함을 대체할 수 없음 -> 개발자도 자신이 작성한 코드에서 많으 결함을 효율적으로 찾아낼 수 있음

 

5.1.1 독립적인 테스팅 (K2)

 

* 테스팅의 독립성 수준 (낮은 수준 ~ 높은 수준)

　① 독립적인 테스터 없음 : 유일하게 개발자가 자신의 코드를 직접 테스트하는 형태  
　② 개발팀 or 프로젝트팀에 속한 독립적인 개발자나 테스터 : 개발자가 동료의 제품을 테스트하는 형태도 포함

　③ 조직 내 독립적 테스트팀 or 그룹이 프로젝트 관리자 or 상위 관리자에게 직접 보고
　④ 비즈니스 조직 or 사용자 커뮤니티 소속 /
　　특정 테스트 분야(사용성, 보안성, 성능, 준수성, 이식성 등)를 전문으로 하는 독립적인 테스터
　⑤ 현장(in-house) or 현장 외(outsourcing)에서 일하는 조직 외부의 독립적인 테스터

* 테스트 독립성의 잠재적 이점

　① 그들이 가지고 있는 다양한 배경, 기술적인 관점, 성향이 달라 개발자와는 다른 유형의 장애를 찾아낼 수 있음
　② 이해관계자가 시스템 명세를 정의하고, 구현하면서 만든 가정(assumptions)에 대해 확인하고
　　이의를 제기하고 틀렸음을 입증할 수 있음

　③ 벤더(vendor)의 독립 테스터는 테스트할 시스템을 고용한 회사의 (정치적) 압박 없이 객관적으로 보고할 수 있음

* 테스트 독립성의 잠재적 단점

　① 개발팀과의 고립으로 협업이 어려울 수 있고, 개발팀에게 피드백 전달이 늦어지고, 개발팀과 적대적인 관계가 형성될수 있음
　② 개발자가 품질에 대한 책임감을 잃을 수 있음

　③ 독립적인 테스터가 병목 현상의 장본인으로 비쳐질 수 있음
　④ 독립적인 테스터는 중요한 정보(예 : 테스트 대상에 대한 정보)를 전달받지 못할 수 있음

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

 

* 테스트 관리자
　- 테스트 프로세스에 대한 전반적인 책임, 테스트 활동을 성공적으로 이끄는 것
　- SW 개발 수명주기의 영향을 받음

　- 역할과 업무
　　① 조직의 테스트 정책과 테스트 전략을 개발하고 리뷰
　　② 정황을 고려한 테스트 활동, 테스트 목적과 리스크 이해를 바탕으로 테스트 활동을 계획
　　　(예 : 테스트 접근법 선택, 테스트 추정(테스트 시간, 노력, 비용), 리소스 획득,
　　　테스트 레벨과 테스트 주기의 정의, 결함 관리 등)
　　③ 테스트 계획서 작성과 업데이트 
　　④  프로젝트 관리자, 제품 책임자, 기타 관계자와 테스트 계획 관련 협의
　　⑤ 통합 계획 등과 같은 다른 프로젝트 활동과 테스팅 관점 공유
　　⑥ 테스트 분석, 설계, 구현, 실행 활동을 개시하고, 테스트 진행과 결과를 모니터링하며
　　　종료 조건(or 종료 조건 정의)의 상태를 점검하고 테스트 완료 활동을 촉진
　　⑦ 수집한 정보를 바탕으로 테스트 진행 상황 보고서와 테스트 요약 보고서 작성과 배포
　　⑧ 테스트 결과와 진행 상황(테스트 진행 상황 보고서 or 이미 완료된 다른 테스트 프로젝트의 테스트 요약 보고서에서 문서화된)에 따라 계획을 조정하고 테스트 제어에 필요한 모든 조치를 취함
　　⑨ 결함 관리 시스템과 테스트웨어에 적합한 형상 관리 체제 구축 지원
　　⑩ 테스트 진척 상황 측정과 테스팅 및 제품 품질 평가를 위한 적절한 메트릭 도입
　　⑪ 테스트 프로세스 지원용 도구 선택과 구현 지원
　　　(예 : 도구 선택 예산(경우에 따라 구입 or 지원 비용까지)에 대한 권고, 파일럿 프로젝트에 시간과 노력 할당,
　　　도구 사용에 대한 지속적인 지원 제공 등)
　　⑫ 테스트 환경 구축에 관한 결정
　　⑬ 조직에 테스터, 테스트팀, 테스트 활동을 홍보하고 지지를 요청
　　⑭  테스터의 역량과 경력 개발 (예 : 교육 계획, 성과 평가, 코칭 등)

* 테스터
　- 역할과 업무
　　① 테스트 계획을 리뷰, 계획 작성에 참여
　　② 테스트 베이시스(요구사항, 사용자 스토리와 인수 조건, 명세, 모델)의 테스트 용이성을 분석, 리뷰, 평가
　　③ 테스트 컨디션을 식별 및 기록, TC, 테스트 컨디션, 테스트 베이시스 간의 추적성 설정
　　④ 테스트 환경을 설계, 구축, 검증하고 필요한 경우 시스템 관리자, 네트워크 관리자와 협업
　　⑤ TC와 테스트 프로시저를 설계 및 구현
　　⑥ 테스트 데이터를 준비하고 획득
　　⑦ 상세 테스트 실행 일정 수립
　　⑧ 테스트를 실행하고 결과를 평가해, 기대 결과와 차이 기록
　　⑨ 테스트 프로세스에 적합한 도구 사용
　　⑩ 필요한 경우 테스트 자동화 (개발자 or 테스트 자동화 전문가의 도움을 받을 수 있음)
　　⑪ 非기능 품질 특성(수행 효율성, 신뢰성, 사용성, 보안성, 호환성, 이식성) 평가
　　⑫ 테스트 산출물 리뷰

 

5.2 테스트 계획과 추정

 

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

 

* 테스트 계획
　- 개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용을 담고 있음
　- 계획에 영향을 주는 요소 : 조직의 테스트 정책과 테스트 전략, 사용하는 개발 수명주기 및 방법(2.1절), 테스팅의 범위, 목적, 리스크, 제약, 심각도, 테스트 용이성, 자원의 가용성 등
　- 테스트 계획 활동 = 제품의 수명주기 전반에 걸쳐 이루어지는 지속적인 활동
　(제품의 수명주기는 프로젝트 범위를 넘어서 유지보수 단계까지 포함할 수 있음)
　- 테스트 활동의 피드백으로 리스크의 변화를 인지하고 테스트 계획을 수정해야 함
　- 활동
　　① 테스팅의 범위 정의, 목적, 리스크 결정
　　② 전반적인 테스팅 접근법 정의
　　③ 테스트 활동을 SW 수명주기 활동에 통합하고 조정
　　④ 테스트 대상 다양한 테스트 활동에 필요한 인력과 기타 자원, 테스트 활동 수행 방법 결정
　　⑤ 테스트 분석, 설계, 구현, 실행, 평가 활동의 일정 조정.
　　　일정은 특정 날짜(예 : 순차적 개발에서) or 반복주기 단위(예 : 반복적 개발)로 편성할 수 있음
　　⑥ 테스트 모니터링과 제어에 사용할 메트릭 선정
　　⑦ 테스트 활동 예산 결정
　　⑧ 테스트 문서의 구조와 상세화 정도 정의 (예 : 템플릿 or 예제 문서를 제공함으로써....)

 

5.2.2 테스트 전략과 테스트 접근법 (K2)

 

* 테스트 전략 유형
　- 서로 다른 접근법을 조합해 적용했을 때 각 접근법은 서로를 보완하며 더 효과적으로 테스팅을 수행할 수 있게 함

　① 분석적 (Analytical)
　　- 특정 요소(예 : 요구사항 or 리스크)에 대한 분석을 기반으로 한 테스트 전략

　　- 예 : 리스크 기반 테스팅 (리스크 수준에 따라 테스트를 설계, 우선순위를 결정)
　② 모델 기반 (Model-Based)
　　- 요구되는 제품의 특정 측면에 대한 모델을 기반드로 만들어짐
　　- 특정 측면에는 기능, 비즈니스 프로세스, 내부 구조, 非기능 특성(예 : 신뢰성) 등
　　- 모델 : 비즈니스 프로세스, 상태, 신뢰성 성장 모델 등
　③ 방법론적 (Methodical)
　　- 사전에 정의한 테스트 셋 or 테스트 컨디션을 체계적으로 사용하는 데 의존함
　　- 예 : 보편적이고 발생 가능성이 높은 장애 분류, 주요 품질 특성 목록,
　　모바일 애플리케이션이나 웹페이지에 대한 전사 룩앤필(look-and-feel) 표준 등
　④ 프로세스 준수 (Process-compliant) or 표준 준수 (Standard-compliant)
　　- 외부 규정 or 표준을 기반으로 테스트를 분석, 설계, 구현
　　- 예 : 특정 산업 표준에서 제시하는 규정 or 표준, 프로세스의 문서화, 테스트 베이시스의 엄격한 식별과 사용,
　　조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반으로 함
　⑤ 전문가 조언 (Directive) or 자문 (consultative)
　　- 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어짐
　　- 외부 테스트팀 or 외부 조직 소속일 수 있음
　⑥ 리그레션-기피 (Regressive-averse)
　　- 목표 : 기존 기능에 대한 리그레션 테스트 기피
　　- 기존 테스트웨어(특히 TC, 테스트 데이터)의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화 포함
　⑦ 반응적 (Reactive)
　　- 테스트 대상 컴포넌트 or 시스템에 따라 대응하고, 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행
　　- 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계, 구현, 즉각 테스트를 실행할 수 있음
　　- 탐색적 테스팅이 반응적 전략에서 일반적으로 사용하는 기법

 

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

 

- SW 품질과 테스팅을 효과적으로 통제하려면?
특정 테스트 활동의 시작 시점과 완료 시점에 대한 조건을 정의해 놓는 것이 좋음

- 각 테스트 레벨과 테스트 유형의 시작과 종료 조건을 정의해야 함 -> 테스트 목적에 따라 달라짐

* 시작 조건 (애자일 -> 준비의 정의)
　- 특정 테스트 활동을 시작하기 위해 정의한 사전 조건
　- 충족하지 못하면 해당 활동을 수행하기 더 여럽고 더 많은 시간을 필요로 하며 더 많은 비용이 들고
　리스크에 노출될 가능성이 더 높아짐
　- 일반적인 시작 조건
　　① 테스트 가능한 요구사항, 사용자 스토리나 모델(예 : 모델 기반 테스트 전략을 따르는 경우)의 가용 여부
　　② 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
　　③ 테스트 환경 가용 여부
　　④ 필요한 테스트 도구 가용 여부
　　⑤ 테스트 데이터와 기타 필요한 자원의 가용 여부

 

* 종료 조건 (애자일 -> 완료의 정의)
　- 특정 레벨이나 테스트 세트가 끝났음을 선언하기 위해 만족해야 할 조건을 정의
　- 종료 조건을 충족하지 못한 상황에서도 여러 가지 이유로 테스트 활동을 조기에 마감하는 경우 많음
　- 추가 테스팅 없이 출시하는 상황이라도 프로젝트 이해관계자와 비즈니스 책임자가 리스크를 검토하고 수용하면
　테스트를 종료할 수 있음
　- 일반적인 종료 조건
　　① 계획한 테스트 실행 완료
　　② 정의한 커버리지 수준 (예 : 요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)의 도달
　　③ 해결하지 못한 결함 수가 합의된 수보다 적음
　　④ 추정 잔존 결함의 수가 충분히 적음
　　⑤ 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달

 

5.2.4 테스트 실행 일정 (K3)

 

* 이상적인 TC 실행 순서?
　- 가장 우선순위가 높은 TC를 먼저 실행
　- but 실제로 TC 간에 종속 관계가 있거나 테스트 대상의 기능 자체가 종속 관계라면 
　우선순위에 따라 실행하지 못할 수도 있음
　- 우선순위가 높은 TC가 우선순위가 낮은 TC에 종속되어 있다면? 낮은 우선순위를 가진 TC를 먼저 실행해야 함

 

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

 

그냥 읽어보기....^^

 

5.2.6 테스트 추정 기법 (K2)

 

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

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

 

5.3 테스트 모니터링과 제어

 

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

* 테스트 제어
　- 수집하고 보고된 정보와 메트릭의 결과로 취해진 수정 조치 or 가이드를 의미
　- 수정 조치(활동)는 어떤 테스트 활동을 커버 or SW 수명주기 활동에 영향을 미칠 수 있음
　- 예
　　① 식별한 리스크(예 :  SW 인도 지연) 발생 시 테스트 우선순위의 변경 
　　② 테스트 환경 or 기타 자원의 가용 여부에 따라 테스트 일정 변경
　　③ 재작업으로 인해 테스트 항목이 시작 조건 or 종료 조건 만족하는지 재평가

 

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

 

* 메트릭 수집을 위한 평가 (테스팅 활동 중 or 종료 시점)

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

 

* 일반적인 테스트 메트릭

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

 

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

 

* 테스트 보고
　- 목적 : 테스트 활동(예 : 테스트 레벨) 중 or 마무리 시점의 테스트 활동 정보 요약과 공유
　- 테스트 활동 중 작성하는 테스트 보고서 : 테스트 진행 상황 보고서
　- 테스트 활동 종료 시점에 작성하는 테스트 보고서 : 테스트 요약 보고서

* 일반적인 테스트 진행 보고서 (테스트 모니터링과 제어 과정 중....) 에 들어가는 정보
　① 테스트 계획 대비 테스트 활동과 진행 상황
　② 진행을 방해하는 요소
　③ 다음 보고 기간에 진행하기로 계획한 테스팅
　④ 테스트 대상의 품질

* 일반적인 테스트 요약 보고서 (종료 조건을 만족하면....) 에 들어가는 정보

　① 테스트 수행 내용 요약
　② 테스트 기간 도중에 발생한 상황 정보
　③ 계획 대비 편차 (예 : 일정, 기간, 테스팅 활동 노력)
　④ 종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질
　⑤ 진행을 방해했거나 계속해서 방해하고 있는 요소
　⑥ 메트릭 (5.3. > TC, 테스트 커버리지, 활동 진행 상황, 소비한 자원)
　⑦ 잔존 리스크 (5.5절)
　⑧ 재사용 가능한(만들어 낸) 테스트 작업 산출물

 

5.4 형상 관리 (K2)

 

* 형상 관리
　- 목적 : 프로젝트와 젶무 수명주기 동안 컴포넌트 or 시스템, 테스트웨어와 이들 서로간의 관계 통합을 수립하고 유지하는 데 있음
　- 형상 관리가 테스팅을 적절히 지원하기 위해 확인할 내용
　　① 모든 테스트 항목에 고유 식별번호 부여, 버전 관리, 변경 이력 기록
　　　(형상 관리에서 테스트 항목은 서로 연관돼 있음)
　　② 모든 테스트웨어 항목에 고유 식별번호 부여, 버전 관리, 변경사항 추적, 서로 연결
　　　-> 테스트 항목 버전과도 연결 -> 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 함
　　③ 식별한 모든 문서와 SW 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 함
　- 테스트 계획을 수립하면서 형상관리 절차와 인프라(도구)를 식별하고 구현해야 함

 

5.5 리스크와 테스팅

 

5.5.1 리스크의 정의 (K1)

 

* 리스크
　- 정의 : 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성
　- 수준 : 이벤트 발생 가능성, 이벤트로 인한 영향도(피해)로 결정함

 

5.5.2 제품 및 프로젝트 리스크 (K2)

 

* 제품 리스크
　- 작업 산출물(예 : 명세, 컴포넌트, 시스템, 테스트 등)이 사용자 or 이해관계자의 합당한 니즈를 충족하지 못할 가능성
　- 품질 리스크 : 제품 리스크가 제품의 특정 품질 특성과 연관되는 경우
　(예 : 기능 안전성, 신뢰성, 성능 효율성, 사용성, 보안성, 호환성, 유지 보수성, 이식성)
　- 예
　　① SW가 명세에서 의도한 기능을 수행하지 못함
　　② SW가 사용자, 고 객 or 이해관계자가 요구하는 기능을 수행하지 못함
　　③ 시스템 아키텍처가 일부 비기능 요구사항을 충분히 지원하지 못함
　　④ 특정 계산식이 특정 상황에서 올바르게 수행되지 못함
　　⑤ 루프(loop) 제어 구조 코딩이 잘못됨
　　⑥ 고성능 거래 처리 시스템의 응답 시간이 적절하지 않음
　　⑦ 사용자 경험(UX, User eXperience) 피드백이 제품 기대치에 미치지 못함

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

 

5.5.3 리스크 기반 테스팅과 제품 품질 (K3)

* 리스크

　- 테스팅 노력을 집중하는 데 사용됨
　- 테스팅을 언제, 어디서 시작할지 결정하고 좀 더 관심을 가져야 할 영역을 식별하는 데 사용됨

* 리스크 기반 접근법
　- 제품 리스크 수준을 조기에 낮추는 데 기여함
　- 리스크 기반 테스팅?
　　· 제품 리스크 식별과 리스크 발생 가능성과 영향을 평가하는 제품 리스크 분석을 포함함
　　· 제품 리스크 정보로 얻은 결과는 테스트 계획, 명세, TC 준비와 실행, 테스트 모니터링에 사용함.
　　· 초기에 제품 리스크를 평가하면 프로젝트 성공에 기여함
　　· 프로젝트 이해관계자의 집단 지식과 통찰력을 기반으로 제품 리스크를 분석함
　　 · 새로운 리스크를 식별하고 어떤 리스크를 완화해야 하는지 판단하는 데 도움을 주며
　　리스크에 대한 불확실성을 낮춰줌
　- 제품 리스크 분석 결과가 사용하는 곳
　　① 사용할 테스트 기법 결정
　　② 수행할 테스트 레벨과 유형 확정 (예 : 보안성 테스팅, 가용성 테스팅)
　　③ 테스트 수행 범위 결정
　　④ 가능한 조기에 심각한 결함을 발견하기 위해 테스트 우선순위 결정
　　⑤ 기존 테스팅 활동 外 리스크 완화를 위한 다른 활동의 식별 (예 : 경험이 부족한 설계자에게 교육 제공)
　 - 제품 장애 발생 가능성을 최소화하기 위한 리스크 관리 활동의 절차
　　① 잘못될 수 있는 것(리스크)을 분석 (그리고 정기적으로 재분석)
　　② 처리해야 할 중요한 리스크가 무엇인지 판단
　　③ 해당 리스크를 완화하기 위한 행동 구현
　　④ 리스크의 실제 발생을 대비한 대책 수립

 

5.6 결함 관리 (K3)

 

- 테스팅 중 발견한 결함은 반드시 기록해야 함
- 찾아낸 모든 결함은 조사하고, 발견에서 결함 분류까지 추적해야 함
- 모든 결함을 해결까지 관리하기 위해 조직은 결함 관리 프로세스를 수립해야 함
- 결함 관리에 참여하는 모든 사람이 프로세스에 동의해야 함
- 테스터는 결함으로 보고하는 거짓양성의 수를 최소화해야 함

* 일반적인 결함 보고서의 목적
　① 발생한 모든 부정적인 이벤트 정보를 개발자와 기타 관계자에게 제공해 구체적인 영향을 식별하고,
　재현 테스트로 문제를 격리하고, 잠재 결함을 수정하고, 필요에 따라서는 문제를 해결할 다른 방법을 찾을 수 있도록 함
　② 테스트 관리자에게 작업 산출물의 품질과 테스팅 여향을 추적할 방법을 제공함
　(예 : 많은 결함을 보고하면 테스터는 테스트를 수행하는 데 시간을 쓰는 대신에
　결함 보고에 많은 시간을 할애하게 되고 필요한 확인 테스팅의 양도 많아짐)
　③ 개발과 테스트 프로세스 개선에 대한 아이디어를 제공함

 

* 동적 테스팅에서 작성하는 결함 보고서의 내용

 

 

No	용어	설명	유의어	연관 항목
1	형상 관리 (configuration management)	형상 항목의 기능적/물리적 특성을 식별/문서화하고, 해당 특성을 제어하며, 변경 처리 및 구현 상황을 기록/보고하고, 명시된 요구사항을 준수하는지 검증하기 위해 기술적, 행정적 지시와 감독을 적용하는 원칙
2	결함 관리 (defect management)	결함을 인식하고 기록하며, 분류, 조사, 해결하기 위해 조치를 취하고, 해결되었을 때 이를 처 분하는 프로세스		인시던트 관리 (incident management)
3	결함 리포트 (defect report)	결함의 발생, 유형, 상태에 대한 문서	버그 보고서 (bug report)	인시던트 보고서 (incident report)
4	시작 조건 (entry criteria)	정의된 과업을 공식적으로 시작하기 위한 조건의 집합	준비의 정의 (definition of ready)
5	종료 조건 (exit criteria)	정의된 과업을 공식적으로 완료하기 위한 조건들의 집합	· 완결 조건 (completion criteria),  · 테스트 완결 조건 (test completion criteria),  ·  완료의 정의 (definition of done)
6	제품 리스크 (product risk)	제품의 품질에 영향을 미치는 리스크		리스크(risk)
7	프로젝트 리스트 (project risk)	프로젝트 성공에 영향을 미치는 리스크		리스크(risk)
8	리스크 (risk)
9	리스크 수준 (risk level)	영향 및 가능성에 의해 정의된 리스크의 질적, 양적 측정치	리스크 노출도 (risk exposure)
10	리스크 기반 테스팅 (risk-based testing)	연관된 리스크 유형과 리스크 수준을 기반으로 테스트 활동 및 리소스의 이용, 관리, 선택, 우 선순위 등을 다루는 테스팅
11	테스트 접근법 (test approach)	특정 프로젝트에 대한 테스트 전략을 구현한 것
12	테스트 제어 (test control)	모니터링 결과 테스트 프로젝트가 계획에서 벗어나고 있다고 판단될 때, 다시 정상 궤도로 돌려놓으려는 시정조치의 개발 및 적용과 관련된 테스트 관리 업무		테스트 관리 (test management)
13	테스트 추정 (test estimation)	소요된 노력, 완료 날짜, 관련 비용, 테스트 케이스의 수 등 테스팅의 다양한 측면과 관련된 예상치. 입력 데이터가 불완전 또는 불분명하거나 일부가 잘못됐다 하더라도 예상치는 활용 가능함
14	테스트 관리자 (test manager)	테스팅 활동 및 자원의 프로젝트 관리와 테스트 대상에 대한 평가를 책임지고 있는 담당자 테스트 대상에 대한 평가를 감독 및 통제, 관리, 계획, 규제하는 사람
15	테스트 모니터링 (test monitoring)	테스트 활동의 상황을 확인하고, 계획된 또는 예상된 상태와의 편차를 식별하고 상태를 이해 관계자에게 보고하는 테스트 관리 활동		테스트 관리 (test management)
16	테스트 계획서 (test plan)	테스팅 활동 조정에 사용되며, 달성할 테스트 목표와 그것을 달성하기 위한 방법과 일정을 설명하는 문서
17	테스트 계획 (test planning)	테스트 계획서의 수립 또는 수정 활동
18	테스트 진행 보고서 (test progress report)	정기적으로 베이스라인(baseline), 리스크, 대안이 필요한 결정 사항과 관련된 테스트 활동의 진행 상황을 작성하는 테스트 보고서	테스트 상태 보고서 (test status report)
19	테스트 전략 (test strategy)	조직 내에서 수행하는 하나 이상의 프로젝트를 테스트하기 위해 포괄적인 요구사항을 나열한 문서. 테스팅을 어떤 방식으로 수행해야 하고, 또 그것이 어떻게 테스트 정책과 연계되는지에 대한 정보를 제공	조직 테스트 전략 (organizational test strategy)
20	테스트 요약 보고서 (test summary report)	해당하는 테스트 항목 평가를 완료 조건에 대비해 제공하는 테스트 보고서	테스트 보고서 (test report)
21	테스터 (tester)	컴포넌트나 시스템의 테스팅에 참여하는 숙련된 전문가

 

Sample A

---

Sample B

---

Sample C