[5장] 테스트 관리 Test Management

용어(Keyword)

형상 관리(configuration management), 결함 관리(defect management), 결함 리포트(defect report), 시작 조건(entry criteria), 종료 조건(exit criteria), 제품 리스크(product risk), 프로젝트 리스크(project risk), 리스크(risk), 리스크 수준(risk level), 리스크 기반 테스팅(risk-based testing), 테스트 접근법(test approach), 테스트 제어(test control), 테스트 추정(test estimation), 테스트 관리자(test manager), 테스트 모니터링(test monitoring), 테스트 계획서(test plan), 테스트 계획(test planning), 테스트 진행 보고서(test progress report), 테스트 전략(test strategy), 테스트 요약 보고서(test summary report), 테스터(tester)

 

5.1 테스트 조직 Test Organization

5.1.1 독립적인 테스팅 (Independent Testing)

테스팅 작업은 특정 테스팅 역할을 부여 받은 사람이나 다른 역할을 하는 사람도 수행할 수 있다 (예: 고객). 저자와 테스터가 가지는 인지편향(1.5 절 참조)의 차이 때문에 일정 수준의 독립성은 테스터가 결함을 더 효과적으로 찾게 해 준다

 

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

• 독립적인 테스터는 그들이 가지고 있는 다양한 배경, 기술적인 관점, 성향이 달라 개발자와는 다른 유형의 장애를 찾아낼 수 있다.
• 독립적인 테스터는 이해관계자가 시스템 명세를 정의하고 구현하면서 만든 가정(assumptions)에 대해 확인하고 이의를 제기하고 틀렸음을 입증할 수 있다.
• 벤더(vendor)의 독립 테스터는 테스트할 시스템을 고용한 회사의 (정치적) 압박 없이 똑바로 그리고 객관적으로 보고할 수 있다.

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

• 개발팀과의 고립으로 협업이 어려울 수 있고, 개발팀에게 피드백 전달이 늦어지고, 개발팀과 적대적인 관계가 형성될 수 있다.
• 개발자가 품질에 대한 책임감을 잃을 수 있다.
• 독립적인 테스터가 병목 현상의 장본인으로 비쳐질 수 있다.
• 독립적인 테스터는 중요한 정보(예: 테스트 대상에 대한 정보)를 전달받지 못할 수 있다.

5.1.2 테스트 관리자 및 테스터의 역할 (Tasks of a Test Manager and Tester)

테스트 관리자의 업무는 테스트 프로세스에 대한 전반적인 책임과 테스트 활동을 성공적으로 이끄는 것이다. 테스트 관리자는 전문 테스트 관리자, 프로젝트 관리자, 개발 관리자, 품질 보증 관리자 역할을 맡을 수 있다.

 

일반적으로 테스트 관리자의 역할과 업무는 다음과 같다:

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

일반적으로 테스터의 역할과 업무는 다음과 같다:

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

테스트 분석, 테스트 설계, 특정 테스트 유형, 테스트 자동화에 관련해 일하는 사람은 각자의 역할에 전문가일 수 있다. 제품과 프로젝트의 리스크나 선택한 소프트웨어 개발 수명주기 모델에 따라 테스트 레벨 별로 테스터의 역할이 다를 수 있다.

5.2 테스트 계획과 추정 Test Planning and Estimation

5.2.1 테스트 계획의 목적과 내용 (Purpose and Content of a Test Plan)

테스트 계획은 개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용을 담고 있다. 테스트 계획 활동은 제품의 수명주기 전반에 걸쳐 이루어지는 지속적인 활동이다.

 

테스트 계획에는 다음과 같은 활동이 있다

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

5.2.2 테스트 전략과 테스트 접근법 (Test Strategy and Test Approach)

테스트 전략은 테스트 프로세스의 일반적인 모습을 반영한다.

• 분석적 (Analytiacl):
  • 특정 요소(예: 요구사항이나 리스크)에 대한 분석을 기반으로 한 테스트 전략.
  • 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법의 예이다.
• 모델 기반 (Model-Based):
  • 테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어진다.
  • 특정 측면에는 기능, 비즈니스 프로세스, 내부 구조, 비기능 특성(예: 신뢰성) 등이 있다.
  • 모델에는 비즈니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델 등이 있다.
• 방법론적 (Methodical):
  • 이 테스트 전략은 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존한다
• 프로세스 준수 ((Process-compliant), 또는 표준 준수(standard-compliant)):
  • 테스트 전략은 외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현한다.
• 전문가 조언 ((Directive), 또는 자문(consultative)):
  • 이 테스트 전략은 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어진다.
• 리그레션-기피 (Regression-averse):
  • 기존 기능에 대한 리그레션 테스트 기피를 목표로 한다.
  • 기존 테스트웨어(특히 테스트 케이스와 테스트 데이터)의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
• 반응적 (Reactive):
  • 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법이다.
  • 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 탐색적 테스팅이 반응적 전략에서 일반적으로 사용하는 기법이다.

테스트 전략은 테스트 프로세스를 종합해 개괄적으로 설명하는 반면,

테스트 접근법은 특정 프로젝트나 릴리스용으로 테스트 전략을 조정(tailoring)한 것이다.

 

테스트 접근법은 테스트 기법, 테스트 레벨, 테스트 유형을 선택하는 출발점이고, 시작 조건과 종료 조건(시작 조건과 종료 조건은 준비의 정의와 완료의 정의라고 부르기도 함)을 정의하는 출발점이다.

테스트 접근법은 정황(context)을 기반으로 선택하고 리스크, 안전 사항, 사용 가능한 자원과 역량, 기술, 시스템 특성(예: 맞춤형 개발 vs 상용 소프트웨어), 테스트 목적과 규정 같은 요소를 고려한다.

5.2.3 시작 조건과 종료 조건 (준비의 정의와 완료의 정의)
Entry Criteria and Exit Criteria (Definition of Ready and Definition of Done)

소프트웨어 품질과 테스팅을 효과적으로 통제하려면 특정 테스트 활동의 시작 시점과 완료 시점에 대한 조건을 정의해 놓는 것이 좋다.

 

일반적인 시작 조건은 다음과 같다:

• 테스트 가능한 요구사항, 사용자 스토리나 모델(예: 모델 기반 테스트 전략을 따르는 경우)의 가용 여부
• 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
• 테스트 환경 가용 여부
• 필요한 테스트 도구 가용 여부
• 테스트 데이터와 기타 필요한 자원의 가용 여부

일반적인 종료 조건은 다음과 같다:

• 계획한 테스트 실행 완료
• 정의한 커버리지 수준 (예: 요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)의 도달
• 해결하지 못한 결함 수가 합의된 수보다 적음
• 추정 잔존 결함의 수가 충분히 적음
• 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달

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

테스트 케이스와 테스트 프로시저를 작성하고(일부 프로시저는 가능하다면 자동화) 테스트 프로시저와 테스트 케이스를 조합해 테스트 스위트를 생성한 후 테스트 스위트의 순서를 정해 실행 일정을 만들 수 있다.

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

테스트 케이스가 서로 종속 관계를 가지고 있다면 각자의 우선순위와 상관없이 필요에 따라 배치해야 한다. 확인 및 리그레션 테스트 역시 수정에 대한 피드백의 중요도에 따라 우선순위를 정해야 하고 이 경우에도 종속 관계를 적용할 수 있다.

5.2.5 테스트 노력에 영향을 미치는 요소 (Factors Influencing the Test Effort)

테스트 노력 추정은 테스트 관련 작업에 필요한 노력의 양을 예측하는 활동으로 이는 특정 프로젝트, 릴리스, 반복주기에서 테스팅의 목적을 충족하는 데 필요하다.

 

테스트 노력에 영향을 주는 요소는 아래와 같다

• 제품 특성 (Product characteristics)
• 개발 프로세스 특성 (Development process characteristics)
• 인력 특성 (People characteristics)
• 테스트 결과 (Test results)

5.2.6 테스트 추정 기법 (Test Estimation Techniques)

충분한 테스팅을 하는 데 필요한 노력을 추정하는 예측 기법 몇 가지가 있다.

• 메트릭 기반 기법
  • 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측
• 전문가 기반 기법
  • 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측

5.3 테스트 모니터링과 제어 Test Monitoring and Control

테스트 모니터링의 목적은 정보 수집 및 테스트 활동에 대한 피드백과 가시성 제공이다. 모니터링 대상 정보는 수동 혹은 자동으로 수집할 수 있고, 테스트 진행 상황을 평가하는 데 활용한다.

테스트 제어는 수집하고 보고된 정보와 메트릭의 결과로 취해진 수정 조치나 가이드를 의미한다.

5.3.1 테스팅에 사용하는 메트릭 (Metrics Used in Testing)

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

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

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

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

5.3.2 테스트 보고의 목적, 내용, 독자 (Purposes, Contents, and Audiences for Test Reports)

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

테스트 활동 중 작성하는 테스트 보고서는 테스트 진행 상황 보고서,

테스트 활동 종료 시점에 작성하는 테스트 보고서는 테스트 요약 보고서라고 부르기도 한다.

 

테스트 진행 사항 보고서

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

테스트 요약 보고서

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

5.4 형상 관리 Configuration Management

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

형상 관리는 테스팅을 적절히 지원하고자 아래 내용을 확인한다:

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

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

5.5 리스크와 테스팅 Risks and Testing

5.5.1 리스크의 정의 (Definition of Risk)

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

5.5.2 제품 및 프로젝트 리스크 (Product and Project Risks)

제품 리스크는 작업 산출물(예: 명세, 컴포넌트, 시스템, 테스트 등)이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성이다. 제품 리스크가 제품의 특정 품질 특성(예: 기능 안전성, 신뢰성, 성능 효율성, 사용성, 보안성, 호환성, 유지 보수성, 이식성)과 연관되는 경우 품질 리스크라고 한다.

• 소프트웨어가 명세에서 의도한 기능을 수행하지 못함
• 특정 계산식이 특정 상황에서 올바르게 수행되지 못함
• 루프(loop) 제어 구조 코딩이 잘못됨
• 고성능 거래 처리 시스템의 응답 시간이 적절하지 않음
• 사용자 경험(UX, User eXperience) 피드백이 제품 기대치에 미치지

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

• 프로젝트 이슈
  • 배포, 작업 완료, 종료 조건이나 완료의 정의를 만족하지 못하고 지연된다.
  • 부정확한 추정, 우선순위가 높은 프로젝트에 예산 재배정, 또는 조직 전반에 걸친 예산 삭감으로 예산이 부족할 수 있다.
  • 프로젝트 후반에 발생하는 변경은 상당한 재작업을 불러올 수 있다.
• 조직 이슈
• 정치적 이슈
• 기술적 이슈
  • 요구사항이 충분히 잘 정의되지 않을 수 있다.
  • 테스트 환경이 필요한 시점에 준비되지 않을 수 있다.
• 공급자 이슈

5.5.3 리스크 기반 테스팅과 제품 품질 (Risk-based Testing and Product Quality)

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

리스크 기반 테스팅은 제품 리스크 식별과 리스크 발생 가능성과 영향을 평가하는 제품 리스크 분석을 포함한다.

초기에 제품 리스크를 평가하면 프로젝트 성공에 기여한다.

5.6 결함 관리 Defect Management

테스팅의 목적 중 하나가 결함을 찾는 것이기 때문에 테스팅 중 발견한 결함은 반드시 기록해야 한다.

찾아낸 모든 결함은 조사하고, 발견에서 결함 분류까지 추적해야 한다 (예: 결함 수정과 결함 해결에 대한 확인 테스팅 완료 여부, 다음 릴리스로 연기, 영구적인 제품 제약 사항으로 인정 등).

모든 결함을 해결까지 관리하기 위해 조직은 결함 관리 프로세스(워크플로우와 결함 분류 규칙)를 수립해야 한다.

일반적인 결함 보고서의 목적은 다음과 같다:

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

결함 관리 도구를 사용하면 결함 보고서의 내용 중 일부는 자동으로 작성될 수 있다