2015, 봄

게임콘텐츠스쿨이종원 교수

ISTQB 강의노트 7

테스트 관리

학습내용v 테스트 조직: 독립성, 임무v 테스트 계획과 추정v 모니터링과 제어v 형상관리v 리스크와 테스팅v 인시던트 관리v 테스트 프로세스 평가

테스트 조직의 유형과 독립성 수준

① 독립적 테스터 없음: 개발자가 자신의 코드를 직접 테스트② 개발 팀 내부에 독립적인 테스터 운영③ 조직내에 독립적 테스트 팀을 운영하고 개발팀의 상위 관

리자에게 직접 보고④ 비즈니스 조직 또는 사용자 커뮤니티 멤버들로 구성된 독

립적인 테스트 조직⑤ 사용성, 보안성 등과 같은 특정 영역의 전문 테스트들로 구

성된 독립적인 테스트 조직⑥ 아웃소싱 또는 조직 외부의 독립적 테스트 그룹

독립성 수준 결정v 테스트 조직 독립성 수준 결정시 고려사항

– 해당 조직의 테스트 요구사항– 테스트 대상 제품의 특성– 요구되는 품질 수준– 프로젝트 조직 구조

v 다양한 테스트 레벨에 걸쳐 독립적으로 테스트를 진행하는것이 중요함– 특히, 안전최우선/대규모 시스템의 테스트

v 하위 레벨에서는 개발자가 테스팅에 참여할 수 있으나 객관성 부족으로 효과는 제한적임

테스트 조직 독립성의 장점v 결함을 보는 시각, 결함을 발견하는 방법이 개발자와 달라

상대적으로 객관적임– 개발단계에서 작성된 명세와 구현 산출물을 객관적으로

검증할 수 있음v 테스트 전문가로서 결함을 효과적이고 효율적으로 찾아내는

전략적 접근이 가능v 테스팅 프로세스 평가를 통해 테스팅을 개선할 수 있음

테스트 조직 독립성의 단점v 독립성 수준이 강하면 강할수록 조직이 분리되어 개발 및

제품 관련 정보에서 멀어질 수 있음– 의사소통 어려움 우려, 조직간 적대관계 형성 등

v 독립적 테스트를 마지막 체크포인트로 활용한다면, 프로젝트의 병목으로 작용할 수 있고, 출시 지연에 대한 비난을 받을 수 있음

v 개발자가 품질에 대해 책임을 지지 않으려고 할 수 있음

테스트 조직 운영시 고려할 점v 개발 프로젝트와 조직의 목적에 부합하는 독립성 수준 결정v 개발팀과 테스트팀 간의 의사소통 계획 수립v 독립성 수준을 정할 때 개발 산출물의 오픈 가능성 고려v 조직의 규모에 따라 여러 형태의 독립성 수준의 테스트 조

직 운영v 개발 팀과 테스트 팀 간의 갈등을 초래할 수 있는 부분을 고

려하여 테스트 정책 수립 및 배포

v 개발팀과 테스트 조직이 합의할 수 있는 객관적인 절차 마련이 필수적.

테스트 조직 구성원v 테스트 리더

– 테스팅 활동과 업무를 계획하고 모니터링/제어– 프로젝트 관리자, 개발관리자, 품질보증 관리자, 테스트

그룹 관리자가 테스트 리더 역할 수행v 테스터

– 수립된 테스트 전략과 방향, 계획 및 테스트 리더의 지침에 따라 테스트 설계를 구현하고 실행

– 테스트 수행 전문 외주 인력 관리

테스트 리더의 역할과 임무v 프로젝트 관리자 및 다른 이들과 함께 테스트 전략과 계획을 조정v 프로젝트에 대한 테스트 전략, 조직의 테스트 정책을 작성 또는 리뷰v 통합 계획과 같은 다른 프로젝트 활동에 대한 테스팅의 관점을 제시v 테스트의 목적와 리스크를 고려하여 테스트 기법 선택 선택, 테스팅 소요시간/

노력/비용 추정, 자원 획득, 테스트 레벨/사이클의 정의 그리고 인시던트 관리계획을 포함한 테스트 계획을 수립

v 테스트 명세, 준비, 구현 그리고 실행을 시작하고, 테스트 결과를 모니터하며 종료 조건을 확인

v 테스트 결과와 진행(상태 보고서에 기록된)상황을 기반으로 계획을 수정하고 문제요소를 보완하기 위해 필요한 모든 조치를 실시

v 추적성을 위해 테스트웨어에 대한 적절한 형상관리를 설정v 테스트 진행상황을 측정하고 테스팅 및 제품의 품질을 평가하기 위한 적절한 측

정방법을 제시v 자동화되어야할 대상, 수준, 방법을 결정v 테스팅 지원을 위한 도구를 선정하고 테스터를 대상으로 도구 사용 훈련을 계획v 테스트 환경의 구현에 대한 것을 결정v 테스팅 중 수집한 정보를 기반으로 테스트 요약 보고서를 작성

테스터의 역할과 임무v 테스트 계획을 리뷰하고 의견을 제시v 테스트 용이성을 판단하기 위해 사용자 요구사항, 명세, 모델을 분석, 리

뷰, 평가v 테스트 명세를 작성v 테스트 환경을 구축(시스템 관리자 및 네트워크 관리자와 조정 필요).v 테스트 데이터 준비 및 획득v 모든 테스트 레벨의 테스트를 구현하고 테스트를 실행 및 로그를 작성

하고 결과를 평가하고 기대 결과와의 편차를 문서화v 필요에 따라 테스트 관리 도구와 테스트 모니터링 도구를 사용v 테스트를 자동화(개발자 또는 테스트 자동화 전문가가 지원가능)v (해당하는 경우)컴포넌트와 시스템의 성능을 측정v 다른 이들에 의해 개발된 테스트를 리뷰

테스터 업무 대체 인력v 테스트 레벨과 제품 및 프로젝트와 관련된 리스크에 따라,

다른 사람들이 독립성의 일정한 범위를 지키면서 테스터의역할을 대신 수행 가능– 대표적으로 컴포넌트와 통합 레벨에서 테스터는 개발자

가 할 수 있음– 인수 테스트 레벨의 테스터는 비즈니즈 전문가나 사용자

가 할 수 있음– 운영 승인 테스팅을 위한 테스터는 운영자가 할 수 있음

테스트 계획과 추정v 테스트 계획 활동v 테스트 시작조건v 테스트 완료조건v 테스트 추정v 테스트 접근법

테스트 계획v 테스팅 목적, 테스트 범위, 필요한 자원, 일정을 결정하는 업

무v 관련 문서들

– 프로젝트 마스터 테스트 계획서– 각 테스트 레벨, 유형 별 테스트 계획서– 관련 표준 : IEEE 829 (소프트웨어 테스트 문서 표준)

v 테스트 계획은 테스트 수명주기 동안 지속적으로 조정하고제어해야 함– 프로젝트 환경의 변화, 추가 요구사항에 따른 리스크검토– 테스트 대상의 품질 상황과 정보를 바탕으로.

테스트 계획 활동v 범위와 리스크를 결정하고 테스팅의 목적을 식별한다.v 테스트 레벨과 시작과 종료 조건을 정의하는 것을 포함한 테스팅에 대

한 전체적인 접근법을 정의한다.v 테스팅 활동을 소프트웨어 수명주기 활동(획득, 공급, 개발, 운영과 유지

보수)에 통합하고 조정한다.v 무엇을 테스트 하고, 테스트 활동에서 수행할 역할은 무엇인지, 어떻게

테스트 활동을 수행하고 테스트 결과는 어떻게 평가할지를 결정한다.v 테스트 분석과 설계 활동의 일정을 계획한다.v 테스트 구현, 실행과 평가의 일정을 계획한다.v 정의된 다른 활동을 위한 자원을 할당한다.v 테스트 문서의 분량, 상세함의 정도, 구조와 템플릿을 정의한다.v 테스트 준비와 실행, 결함 해결책과 리스크 이슈를 모니터링하고 제어하

기 위한 측정기준을 선정한다.v 테스트 준비와 실행의 재현을 지원하도록 충분한 정보를 제공하기 위해

테스트 프로시저의 상세 수준은 결정한다.

테스트 시작 조건v 특정 테스트 레벨의 시작지점이나 일련의 테스트가 실행 준

비가 되었는지 같은 테스팅의 시작을 정의– 테스트 환경 유용성과 준비 여부– 테스트 환경 내에서의 테스트 도구 준비 여부– 테스트 할 수 있는 코드의 이용가능성– 테스트 데이터의 이용가능성

테스트 완료 조건v 테스트 완료 조건은 하나의 테스트 레벨 또는 특정 목적의

테스팅이 언제 종료될 것인지를 정의– 코드 커버리지, 기능 커버리지, 리스크 커버리지와 같은 충분한 테스

트 실행에 대한 측정치– 추정된 결함의 밀도나 신뢰성– 테스트 비용과 예산– 남아있는 리스크(수정되지 않은 결함, 특정 영역에 대한 커버리지 부

족 등)– 시장 출시에 따른 일정– 수정되지 않은 결함 수(심각도 고려)– 시간당 결함 수– 재 테스트 횟수– 예방된 피해와 소요되는 테스트 비용 비교

테스트 추정(Test Estimation)v 테스트 추정은 테스트 프로세스와 관련된 작업들에 대한 비

용, 노력, 기간을 결정v 테스트 추정 방법

– 메트릭 기반 접근법 : 과거 프로젝트나 유사 프로젝트의메트릭을 근거로 예측

– 전문가 기반 접근법 : 전문가에 의한 예측

테스트 추정시 고려사항v 제품의 특성: 테스트 베이시스의 품질, 제품 사이즈, 도메인 복잡성, 신뢰

성 및 보안성 요구사항, 문서화 요구 등v 개발 프로세스의 특성: 조직의 안정성, 도구 경험 여부, 테스트 프로세스,

투입인력의 숙련도, 시간적 압박 정도v 테스트 결과: 발견된 결함 수와 요구되는 재 작업 양v 이외 고려사항

– 테스트를 시작할 수 있는 시점– 테스트 용이성– 개발자 및 관련자들의 숙련도– 잠재결함이 얼마나 많은가– 개발자의 문제해결 시간– 테스트 환경의 가용성과 안정성– 테스트웨어의 재사용성– 리스크 수준 및 테스트 깊이: 테스트 설계기법, 케이스 수

테스트 접근법v 예방적 접근법 : 초반에 테스트 설계v 사후적 접근법 : 개발된 이후에 테스트 설계v 일반적인 접근법 종류:

접근법 내용

분석적 가장 위험한 리스크 영역에 테스팅을 집중하는 리스크 기반 테스팅

모델기반 장애발생율 또는 사용도에 대한 통계적 정보를 기반으로 하는 확률론적 테스팅

방법론적 오류추청 또는 장애기반,경험기반,체크리스트 기반, 소프트웨어 품질특성 기반 테스팅

프로세스 및표준 준수

산업특화 표준 또는 다양한 애자일 개발 방법론에 의한 테스팅

동적/발견적 미리 계획된 테스팅 보다 탐색적 테스팅처럼 실행과 평가가 동시에 이루어지는 테스팅

자문기반 외부전문가 조언과 가이드를 바탕으로 테스팅

리그레션기피형

기존 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 수트 등의 재사용을 통한 테스팅

테스트 접근법 선택시 고려사항v 프로젝트의 실패 리스크, 제품에 대한 위험요소, 제품 장애

가 인간/환경/회사에 미치는 리스크v 제안된 기법, 툴, 방법론에 대한 담당 인력들의 스킬과 경험v 테스팅 목적과 테스팅 팀의 임무v (내외부) 규정v 제품과 비즈니스의 본질적 특성

테스트 경과 모니터링v 테스트 모니터링의 목적

– 테스트 활동에 대한 피드백과 가시성을 제공– 테스팅계획/전략/정책을 준수하면서 테스팅이 수행되는

지 관찰하는 것v 모니터링 방법

– 테스트 진행보고서 검토– 수집된 테스트 메트릭 분석– 이해관계자와의 미팅 수행

v 모니터링 효과– 제품의 품질평가– 테스트 진척도 파악– 테스트 완료 조건이나 커버리지를 측정

모니터링에 사용되는 메트릭/정보v 테스트 케이스 준비에서 작성 완료된 퍼센트(또는 계획된

테스트 케이스가 준비된 퍼센트)v 테스트 환경 준비에서 작업이 완료된 퍼센트v 테스트 케이스 실행 (예: 테스트 케이스의 수행/비수행 개수,

그리고 테스트 케이스의 통과/실패 개수)v 결함 정보 (예: 결함 밀도, 결함 발견 및 수정, 장애율 그리고

재테스트 결과)v 요구사항, 리스크 또는 코드에 대한 테스트 커버리지v 제품에 대한 테스터의 주관적 자신감v 테스트 마일스톤 일정v 추가적인 결함 찾기의 이득 또는 추가적인 테스트 수행 비

용과의 비교를 포함한 테스팅 비용

테스트 리포팅[1]v 테스트 리포팅

– 테스팅 동안의 노력 및 활동에 대한 정보, 제품의 결함정보를 요약하여 이해관계자의 의사결정 지원할 목적으로보고서를 작성하고 보고하는 활동

v 테스트 보고서의 종류– 테스트 진행 보고서– 테스트 종료 보고서

테스트 리포팅[2]v 테스트 보고서에 포함해야 할 요소

– 테스팅 기간 동안 처리했던 주요 업무• 테스트 완료조건이 충족된 시점 등

– 향후 업무에 대한 의사결정을 지원할만한 의미 있게 분석된 정보• 잔존 결함의 평가• 테스팅 수행의 경제적 이득• 부각된 리스크• 테스트된 소프트웨어에 대한 자신감의 정도

테스트 리포팅[3]v 리포팅을 통해 평가할 내용

– 테스트 레벨에 대한 테스트 목적의 적합성– 적용된 테스트 접근법의 적합성– 테스트 목적에 부합하는 테스트 효과성

v 테스트 보고서 작성시 고려할 요소– 소프트웨어 제품 품질– 테스트 생산성(마일스톤 대비 진척도)– 소프트웨어 제품 리스크– 테스트 프로세스 품질(결함발견 효과성/효율성)

테스트 리포팅[4]v 테스트 보고서 계획/설계시 추가 고려사항

– 타입별/심각도별/우선순위별 결함 수– 결함 상태 별 결함 수– 소프트웨어 사이즈 대비 결함 수(코드 라인 당 결함 수)– 요구사항 별 테스트 일 수– 해결되지 않은 결함과 그 영향– 오랫동안 수정되지 않은 결함 분석– 결함 원인 분석– 테스트 상태

• 시작되지 않음/설계단계/테스트 중/x회 재테스트중/완료

테스트 리포팅[5]v 테스트 종료 보고서

– 특정 테스트 유형/레벨 종료 보고서– 전체 프로젝트 종료시 최종 보고서

v 종료보고서 내용– 테스트 계획 대비 차이– 오픈되어 있는 제품 리스크와 예상되는 영향

• 테스트 미진행 부분, 부족한 부분– 해결되지 않은 결함과 그로 인해 예상되는 영향– 시스템 파트의 현 상태와 커버된 리스크– 테스트 프로세스의 품질– 테스트 프로젝트 수행 경험 및 조언

테스트 보고서 활용v 소프트웨어 출시 여부 결정v 결함의 심각도 및 유형 파악v 요구사항에 대한 테스트 커버리지 확인v 소프트웨어 품질 결정v 다음 단계의 테스트를 위한 테스트 주요 요소 파악

테스트 제어v 테스트 진행보고서나 수집된 메트릭을 근거로 테스트가 계

획대로 수행되도록 가이드 및 정정v 제어활동 예

– 테스트 모니터링으로부터 얻은 정보기반으로 의사결정– 프로젝트 리스크가 발생하였을 때 테스트 우선순위 조정– 테스트 환경의 가용성 이슈 발생시 일정 조정– 테스트 시작 조건 결정

테스트 완료v 테스트 자산 및 테스트 환경 보존v 테스팅 활동에서 교훈을 찾아 이해관계자와 공유v 완료단계의 주요 활동

– 테스트 자산(계획서, 매뉴얼 등) 식별 및 형상관리– 재사용 가능한 테스트 자산 식별 및 문서화, 공유– 테스트 환경 정제– 테스팅 활동의 문제점/개선점/교훈 정리 및 공유– 테스트 완료보고서에 테스트 자산의 보전상황 및 교훈

기록 후 보고

형상관리v Configuration managementv 형상관리의 목적은 프로젝트나 제품의 전체 수명주기에 걸

쳐 시스템이나 소프트웨어(프로그램, 모듈, 문서 등)의 변경을 추적하고 상태를 유지하기 위한 것임

v 테스팅 측면에서 형상관리가 하는 일– 테스트 웨어 식별, 버전관리, 변경 추적, 상호 연관성, 테

스트 대상과의 연계 관리 등을 통한 추적성 확보– 테스트 문서에서 참조하고 있는 모든 관련 문서 또는 소

프트웨어 아이템이 모호하지 않게 관리

리스크v 리스크는 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성

과 발생했을 경우의 바람직하지 못한 결과 즉, 잠재적인 문제로 정의될 수 있음

v 리스크 수준은 의도하지 않은 이벤트가 발생될 가능성과 그영향에 의해 결정됨

v 레이놀즈에 의한 리스크 산출 공식– 리스크 = 장애(failure) 가능성 × 손실(damage)

v 리스크의 종류– 프로젝트 리스크: 프로젝트 리스크는 목적을 달성하기

위한 프로젝트의 역량과 관련된 리스크– 제품 리스크: 소프트웨어나 시스템의 잠재적인 장애 영역

프로젝트 리스크v 조직적인 요소

– 테스팅 전문 스킬과 인력의 부족– 개인적 이슈와 교육훈련 관련 이슈– 정치적인 이슈 : 커뮤니케이션 문제, 테스팅 결과 반영 실

패, 테스팅에 대한 비현실적인 기대 등v 기술적 이슈

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

v 공급자 이슈– 공급자인 제3자 협력업체가 역할 수행 실패– 계약상의 이슈

제품 리스크v 개발팀에서 전달 받은 장애 가능성이 높은 소프트웨어v 소프트웨어 및 하드웨어가 개인이나 회사에 손실을 끼칠 가

능성v 취약한 소프트웨어 특성(기능성, 신뢰성, 사용성, 성능)v 취약한 데이터 무결성과 품질 (예: 데이터 이식 이슈, 데이터

변환 문제, 데이터 전달 문데, 데이터 표준 위반)v 의도된 기능을 수행하지 못하는 소프트웨어

리스크 관리 방법v 리스크 식별

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

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

석– 장애 발생 빈도와 장애로 인한 영향을 식별

v 리스크의 우선순위를 결정v 리스크 계획 활동

– 리스크 정보를 근거로 대처방안 수립(테스트 전략 수립)v 리스크 추적

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

리스크 식별v 테스트 대상을 기능적 또는 기술적 아이템으로 분리하여 각

각의 아이템에서 리스크 식별– 요구사항 분석서에서 상위레벨 테스트를 필요로 하는 항

목– 구조에서 하위레벨 테스트가 필요한 항목 도출

리스크요소

리스크아이템

장애발생 가능성 영향

리스크아이템1

리스크아이템2

리스크아이템3

리스크아이템4

리스크 분석[1]v 장애발생가능성과 장애로 인한 손실 예측하여 리스크 우선

순위 결정v 분석 항목:

장애발생 가능성 장애로 인한 영향

• 복잡성• 새로운 개발의 정도• 상호관계• 프로그램 소스의 크기• 사용된 기술의 난이도/최신

성• 개발팀의 경험 미흡

• 사용자에 의한 취급 중요도(잘 팔리는 것인지 여부)

• 경제적, 안전적, 회사 이미지피해

• 사용 빈도• 외부적 가시성

리스크요소

리스크아이템

장애발생 가능성 영향

복잡성 신규정도 상호관계 크기 난이도 경험 중요도 피해 사용빈도 가시성

리스크아이템1

9 5 9 9 5 1 3 5 9 3

리스크아이템2

1 5 9 3 1 1 5 9 3 1

리스크아이템3

3 5 3 3 0 3 5 3 9 0

리스크아이템4

5 9 1 9 3 5 9 1 5 5

다양한 파트가모여 신중하게결정

리스크 분석[2]v 기술적 리스크와 사업적 리스크

v 기술적 리스크 : 단위/통합테스팅과 관련– 장애 발생 가능성 관리

v 사업적 리스크 : 인수테스팅과 관련– 장애로 인한 영향 관리

리스크 계획 활동v 리스크 분석 결과를 근거로 대처 방안 수립

– 리스크를 줄이는 테스트 전략 수립

인수테스팅에 집중장애로 인한 영향-사업적리스크

개발테스팅에 집중장애 발생

가능성-기술적리스크

반드시테스트함

테스트함

테스트함테스트하지

않을 수 있음

논의필요

리스크 추적v 테스트 전략을 테스팅 프로젝트 동안 준수하고, 이슈가 없는

지 모니터링하고 제어하는 활동v 리스크의 변화 및 리스크 영역별 의사결정 지원

인시던트 관리v 테스팅의 목적 중 하나는 결함을 찾는 것이기 때문에 실제

와 기대 결과 사이의 불일치는 인시던트로 기록될 필요가있음

v 인시던트는 조사되어야 하며 결함으로 판명날 수도 있음v 인시던트와 결함을 해결하기 위한 적절한 활동이 정의되어

야 함v 인시던트와 결함은 발견과 분류부터 수정과 해결책의 확인

까지 추적되어야 함v 모든 인시던트를 완료시까지 관리하기 위해서 인시던트 관

리 프로세스와 분류를 위한 규칙을 수립해야함

인시던트 리포트의 목적v 개발자와 프로젝트 관련자에게 문제점을 식별하고, 격리하

고, 필요하면 정정하도록 피드백을 제공v 테스트 리더에게 시스템의 품질 또는 테스트 진척을 추적할

수 있는 정보 제공v 테스트 프로세스 개선에 대한 아이디어 제공

인시던트 리포트에 포함될 내용v 이슈발생 날짜, 이슈를 제기한 조직, 작성자v 기대결과와 실제결과v 테스트 항목과 환경의 식별v 소프트웨어나 시스템의 수명주기에서 인시던트가 발견된 시점v 로그, 데이터베이스 덤프, 화면 덤프 등을 포함한 인시던트 재현이 가능

한 상세설명v 이해관계자의 이익에 영향을 주는 범위 또는 정도v 결함이 시스템에 미치는 심각도v 수정 우선순위v 인시던트의 상태 : 오픈, 보류, 중복, 수정대기, 수정완료, 종료v 결론, 의견, 승인여부v 관련 이슈 : 인시던트로 인한 변경이 영향을 줄 수 있는 다른 영역v 변경 이력 : 인시던트를 격리하고, 수정하고, 수정여부를 확인하는 등의

활동을 순서대로 기록v 참조사항 : 관련된 테스트 케이스 식별 정도

테스트 프로세스 평가v 조직 차원의 테스트 프로세스

– 테스팅 정책, 조직 차원의 테스트 전략v 테스트 매니지먼트 프로세스

– 레벨 별, 유형 별 관리 통제 프로세스v 정적, 동적 테스트 프로세스

– 수명주기에 따른 전체적 테스트 프로세스

v TMMi, TPI