STQB_CTFL 5. 테스트 관리

서론

    이번 5장의 학습 목표는 "테스트 관리 파트에서는, 항상 리소스와 시간의 제약이 다르는 상황에서 효과적으로 효율적인 테스트 수행을 위한 테스트 리딩을 목적으로 테스트 계획 및 전략 수립, 테스트에 필요한 공수 추정, 테스트 활동에 대한 모니터링 및 관리 방안에 대하여 알아야 한다. 또한 테스트 팀을 효율적으로 운영하기 위한 제 3자 테스트 팀의 필요성에 대해서 살펴보고, 테스트 프로세스의 지속적인 개선이 필요한 이유 및 개선 방법에 대해 알아야 한다."이다. 이를 기억하고 내용을 이해해 보자.

---

배우기에 앞서 용어 정리

    용어를 확실하게 아는 것이 이해에 도움이 된다. ISTQB가 개발자뿐만 아니라 다른 직군도 시험을 충분히 볼 수 있기에 이해하기 쉽게 용어의 정의를 살펴보자.

• 형상 관리: 변경 프로세스에 기술 및 관리 차원의 지시와 감독을 적용하는 원칙.
• 결함 관리: 결함을 인지하고, 조사하고, 행동을 취해 처리하는 절차.
• 테스트 추정: 소프트웨어 테스트 프로세스에서 특정 작업에 소요될 시간과 자원을 예측하는 과정
• 독립성: 객관적인 테스팅을 완수하기 위한 책임의 분리.
• 벤더(Vendor): 일반적으로 제품이나 서비스를 제공하는 공급업체를 의미.
• 메트릭 기반 접근법: 과거 프로젝트나 유사 프로젝트의 메트릭을 근거로 또는 전형적인 가치를 근거로 테스트 노력 또는 업무랭 예측
• 전문가 기반 접근법: 전문가나 업무 수행 주체에 의한 예측
• 워크 브레이크다운 스트럭쳐(WBS: Work Breakdown Structure): 어떤 접근법을 선택하든 추정은 리스크 분석과 테스트 전략을 근거로 산정해야 하며, 수행 할 예정인 테스트 업무를 세분화하여 각 업무에 적절한 자원을 배분하고, 이를 수렴한다.
• 레이놀즈: 리스크를 "장애로 인해 주어진 기간에 발생 가능한 비용".
• 인시던트: 테스팅 중 발생하여 조사가 요구되는 모든 이벤트.

---

테스트 조직

독립적인 테스팅

   테스팅 작업은 특정 테스팅 역할을 부여 받은 사람이나 다른 역할을 하는 사람도 수행할 수 있다. 저자와 테스터가 가지는 인지편향의 차이 때문에 일정 수준의 독립성은 테스터가 결함을 더 효과적으로 찾게 해 준다. 그러나 독립성이 친숙함을 대체할 수 없으며 개발자도 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

  테스팅의 독립성 수준은 다음과 같다. (낮은 수준에서 높은 수준까지)

• 독립적인 테스터 없음: 유일하게 개발자가 자신의 코드를 직접 테스트하는 형태
• 개발팀이나 프로젝트팀에 속한 독립적인 개발자나 테스터: 개발자가 동료의 제품을 테스트하는 형태도 포함
• 조직 내 독립적 테스트팀이나 그룹이 프로젝트 관리자나 상위 관리자에게 직접 보고
• 비즈니스 조직 또는 사용자 커뮤니티 소속이거나 사용성, 보안성, 성능, 준수성(regulatory/compliance), 이식성 등 특정 테스트 분야를 전문으로 하는 독립적인 테스터
• 현장(in-house) 또는 현장 외(outsourcing)에서 일하는 조직 외부의 독립적인 테스터

   대부분의 프로젝트에서 보통 여러 테스트 레벨을 두고 그 중 일부는 독립적인 테스터가 담당하도록 하는 것이 최적이다. 개발자는 자신의 작업 산출물의 품질을 일정 수준으로 유지하기 위해 테스팅(특히 하위 레벨 테스팅)에 참여해야 한다.

   테스팅의 독립성을 어떻게 구현할지는 사용 중인 소프트웨어 개발 수명주기 모델에 따라 다르다. 예를 들어 애자일 개발에서는 테스터가 개발팀의 일부로 속할 수 있다. 애자일 방법론을 사용하는 일부 조직에서는 이런 테스터가 보다 큰 독립 테스트팀의 일부로 간주되기도 한다. 또 이런 조직에서는 제품 책임자가 각 반복주기(iteration) 말미에 인수 테스팅을 수행함으로써 사용자 스토리를 검증할 수 있다.

  테스트 독립성의 이점은 다음과 같다.

• 독립적인 테스터는 그들이 가지고 있는 다양한 배경, 기술적인 관점, 성향이 달라 개발자와는 다른 유형의 장애를 찾아낼 수 있다. 즉, 상대적으로 객관적이다.
• 독립적인 테스터는 이해관계자가 시스템 명세를 정의하고 구현하면서 만든 가정(assumptions)에 대해 확인하고 이의를 제기하고 틀렸음을 입증할 수 있다.
• 벤더(vendor)의 독립 테스터는 테스트할 시스템을 고용한 회사의 (정치적) 압박 없이 똑바로 그리고 객관적으로 보고할 수 있다.
• 개발단계에서 작성된 명세와 구현 산출물을 객관적으로 검증할 수 있다.
• 테스트 전문가로서 결함을 효과적으고 효율적으로 찾아내는 전략적 접근이 가능하다.
• 테스팅 프로세스 평가를 통해 테스팅을 개선할 수 있다.

    테스트 독립성의 단점은 다음과 같다.

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

   테스트 조직을 생성하거나 운영하기 위해 고려해야 할 사항들은 다양하며 아래와 같다.

• 개발 프로젝트와 조직의 목적에 부합하는 독립성 수준을 결정해야 한다.
• 개발팀과 테스트 팀 간의 의사소통 계획이 적절하게 수립 되어야 한다.
• 독립성 수준을 정할 때 개발 산출물의 오픈 가능성을 고려해야 한다.
• 조직의 규모에 따라 여러 형태의 독립성 수준의 테스트 조직을 운영할 수 있다.
• 개발 팀과 테스트 팀 간의 갈등을 초례 할 수 있는 부분을 고려하여 테스트 정책을 수립하고 배포해야 한다.

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

   테스트 역할 두 가지 즉, 테스트 관리자와 테스터를 다룬다. 두 역할담당자의 활동과 업무는 프로젝트와 제품의 정황, 담당자의 역량, 조직 상황에 따라 달라진다.

   테스트 관리자의 업무는 테스트 프로세스에 대한 전반적인 책임과 테스트 활동을 성공적으로 이끄는 것이다. 테스트 관리자는 전문 테스트 관리자, 프로젝트 관리자, 개발 관리자, 품질 보증 관리자 역할을 맡을 수 있다. 규모가 큰 프로젝트나 조직인 경우 몇 개 테스트팀이 테스트 관리자, 테스트 코치, 테스트 코디네이터에게 보고하고, 각 팀은 테스트 리더나 리드 테스터(lead tester)가 책임진다.

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

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

   테스트 관리자의 역할은 소프트웨어 개발 수명주기의 영향을 받는다. 예를 들어, 애자일 개발에서 애자일팀은 위에서 언급한 일부 역할을 수행한다. 특히, 팀 내에서 매일 이루어지는 테스팅 관련 작업이 그러하며 팀에 속한 테스터가 수행하는 경우가 많다. 여러 팀에 걸쳐 있거나 전체 조직 또는 인력 관리와 관련한 일부 직무는 개발팀에 속하지 않은 테스트 관리자가 수행하기도 한다. 이런 테스트 관리자를 테스트 코치라고도 한다.

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

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

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

---

테스트 계획과 추정

테스트 계획의 목적과 내용

    테스트 계획은 개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용을 담고 있다. 계획에 영향을 주는 요소로는 조직의 테스트 정책과 테스트 전략, 사용하는 개발 수명주기 및 방법, 테스팅의 범위, 목적, 리스크, 제약, 심각도, 테스트 용이성, 자원의 가용성 등이 있다.

    프로젝트와 테스트 계획 작업을 진행함에 따라 더 많은 정보를 알게 되고 테스트 계획에 더 많은 세부 정보를 추가할 수 있다. 테스트 계획 활동은 제품의 수명주기 전반에 걸쳐 이루어지는 지속적인 활동이다. 테스트 활동의 피드백으로 리스크의 변화를 인지하고 테스트 계획을 수정해야 한다. 계획은 마스터 테스트 계획의 일부로 작성하거나 시스템 테스팅, 인수 테스팅과 같은 테스트 레벨별 또는 사용성 테스팅, 성능 테스팅과 같은 테스트 유형별 테스트 계획으로 나눠서 작성할 수도 있다. 테스트 계획에는 다음과 같은 활동이 있고 이 중 일부는 테스트 계획서에 기록할 수 있다.

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

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

   소프트웨어 테스트 접근법 또는 전략이란 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등과 같은 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정하는 것을 의미한다. 이러한 테스트 접근법은 개발 과정 중에 결함을 발견하는 예방적 접근법과 개발 이후에 테스트 실행을 통해 결함을 발견하는 사후적 접근법으로 분류할 수 있다.

• 예방적 접근법(Preventative approaches): 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계한다.
• 사후(행동)적 접근법(Reactive approaches): 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계한다.

  테스트 전략은 테스트 프로세스의 일반적인 모습을 반영한다. 주로 제품이나 조직 수준에서 작성된다. 대표적인 테스트 전략 유형에는 다음과 같은 것들이 있다.

• 분석적 (Analytiacl): 특정 요소에 대한 분석을 기반으로 한 테스트 전략. 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법의 예이다.
• 모델 기반 (Model-Based): 테스트 케이스 설계를 소프트웨어 설계 모델을 근거로 작성하고 이를 현행화 하는 과정을 거쳐 실제 테스트 수행을 하도록 하는 접근법 또는 확률론적 테스팅을 통하여 장애율 통계를 바탕으로 설계하는 테스팅이다. 이러한 유형의 테스트 전략에서 테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어진다. 특정 측면에는 기능, 비즈니스 프로세스, 내부 구조, 비기능 특성 등이 있다. 모델에는 비즈니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델 등이 있다.
• 방법론적 (Methodical): 오류 추정 또는 장애 공격과 같은 장애기반, 경험 기반, 체크리스트 기반, 소프트웨어 품질 특성 기반 테스팅이다. 이 테스트 전략은 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존한다. 예를 들어, 보편적이고 발생 가능성이 높은 장애 분류, 주요 품질 특성 목록, 모바일 애플리케이션이나 웹페이지에 대한 전사 룩앤필(look-and-feel) 표준 등이 있다.
• 프로세스 준수 ((Process-compliant), 또는 표준 준수(standard-compliant)): 산업 특화 표준 또는 다양한 애자일 개발 방법론에서 제시한 방법에 의한 테스팅이다. 이 테스트 전략은 외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현한다. 예를 들어, 특정 산업 표준에서 제시하는 규정이나 표준, 프로세스의 문서화, 테스트 베이시스의 엄격한 식별과 사용, 조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반으로 한다.
• 전문가 조언 ((Directive), 또는 자문(consultative)): 외부 전문가의 조언과 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅이다. 이 테스트 전략은 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어진다. 이 사람들은 외부 테스트팀이나 외부 조직 소속일 수 있다.
• 리그레션-기피 (Regression-averse): 보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 수트 등의 재사용을 통한 테스팅이다. 기존 기능에 대한 리그레션 테스트 기피를 목표로 한다. 이 테스트 전략에는 기존 테스트웨어(특히 테스트 케이스와 테스트 데이터)의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
• 반응적 ((Reactive) 또는 동적/발견적(Dynamic and heuristic)): 지금까지 소개한 사전 계획에 따라 실행하는 테스트 전략과는 달리 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법이다. 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 탐색적 테스팅이 반응적 전략에서 일반적으로 사용하는 기법이다.

    앞서 나열한 테스트 전략의 일부를 조합해 적절한 테스트 전략을 만든다. 접근법의 선택은 다음과 같은 정황을 충분히 고려하여 선택해야 한다.

• 프로젝트의 실패 리스크, 제품에 대한 위험 요소, 제품 장애가 인간, 환경, 회사에 미치는 리스크
• 제안된 기법, 툴, 방법론에 대한 담당 인력들의 스킬과 경험
• 테스팅 목적과 테스팅 팀의 업무
• 개발 프로세스를 위한 내 외부 규정과 같은 규정적 측면
• 제품과 비즈니스의 본질적 특성

시작 조건과 종료 조건

    소프트웨어 품질과 테스팅을 효과적으로 통제하려면 특정 테스트 활동의 시작 시점과 완료 시점에 대한 조건을 정의해 놓는 것이 좋다. 시작 조건(준비의 정의)은 특정 테스트 활동을 시작하기 위해 정의한 사전 조건이다. 시작 조건을 충족하지 못하면 해당 활동을 수행하기 더 어렵고 더 많은 시간을 필요로 하며 더 많은 비용이 들고 리스크에 노출될 가능성이 더 높아진다. 종료 조건(완료의 정의)은 특정 테스트 레벨이나 테스트 세트가 끝났음을 선언하기 위해 만족해야 할 조건을 정의한다. 각 테스트 레벨과 테스트 유형의 시작과 종료 조건을 정의해야 하고 이는 테스트 목적에 따라 달라진다.

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

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

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

• 계획한 테스트 실행 완료
• 정의한 커버리지 수준의 도달
• 해결하지 못한 결함 수가 합의된 수보다 적음
• 추정 잔존 결함의 수가 충분히 적음
• 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달

   종료 조건을 충족하지 못한 상황에서도 예산 소진, 예정된 시간 경과, 시장 출시 압박 등의 이유로 테스트 활동을 조기에 마감하는 경우도 많다. 추가 테스팅 없이 출시하는 상황이라도 프로젝트 이해관계자와 비즈니스 책임자가 리스크를 검토하고 수용하면 테스트를 종료할 수 있다.

테스트 실행 일정

    테스트 케이스와 테스트 프로시저를 작성하고(일부 프로시저는 가능하다면 자동화) 테스트 프로시저와 테스트 케이스를 조합해 테스트 스위트를 생성한 후 테스트 스위트의 순서를 정해 실행 일정을 만들 수 있다. 테스트 실행 일정에서 테스트 스위트를 어떤 순서로 실행할지 정의한다. 테스트 실행 일정을 만들 때는 우선순위, 종속 관계, 확인 테스트, 리그레션 테스트, 가장 효율적인 테스트 실행 순서 등을 고려해야 한다.

    이상적인 테스트 케이스 실행 순서는 가장 우선순위가 높은 테스트 케이스를 먼저 실행하는 것이다. 그러나 실제로 테스트 케이스 간에 종속 관계가 있거나 테스팅 대상의 기능 자체가 종속 관계라면 우선순위에 따라 실행하지 못할 수도 있다. 우선순위가 높은 테스트 케이스가 우선순위가 낮은 테스트 케이스에 종속되어 있다면 낮은 우선순위를 가진 테스트 케이스를 먼저 실행해야 한다.

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

   상황에 따라 테스트를 다양한 순서로 배치할 수 있으며 각 순서 배치에 따라 효율성 수준이 다를 수 있다. 이런 경우, 테스트 실행 효율성과 우선순위 준수 간의 절충을 고려한 결정이 필요하다.

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

   테스트 노력 추정은 테스트 관련 작업에 필요한 노력의 양을 예측하는 활동으로 이는 특정 프로젝트, 릴리스, 반복주기에서 테스팅의 목적을 충족하는 데 필요하다. 테스트 노력에 영향을 주는 요소는 아래와 같이 제품 특성, 개발 프로세스 특성, 관련 인물의 특성, 테스트 결과 등이 있다.

제품 특성 (Product characteristics)

• 제품과 관련된 리스크
• 테스트 베이시스의 품질
• 제품의 크기
• 제품 도메인의 복잡도
• 품질 특성 요구사항
• 요구되는 테스트 문서의 상세화 정도
• 법적, 규제 준수 요구사항

개발 프로세스 특성 (Development process characteristics)

• 조직의 안정성과 성숙도
• 사용하는 개발 모델
• 테스트 접근법
• 사용하는 도구
• 테스트 프로세스
• 시간적 압박

인력 특성 (People characteristics)

• 관련된 인원의 역량과 경험, 특히 유사한 프로젝트나 제품 관련
• 팀 응집력과 리더십

테스트 결과 (Test results)

• 발견한 결함 수와 심각도
• 필요한 재작업 규모

테스트 추정 기법

    테스트 노력을 산정하는 추정(Estimation)은 테스트 매니지먼트의 일환으로, 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정하는 것이다. 충분한 테스팅을 하는 데 필요한 노력을 추정하는 예측 기법 몇 가지가 있다. 가장 많이 사용하는 두 가지 기법은 다음과 같다.

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

   어떤 접근법을 선택하든 추정은 리스크 분석과 테스트 전략을 근거로 산정해야 하며, 수행할 예정인 테스트 업무를 세분화하여 각 업무에 적절한 자원을 배분하고, 이를 수렴하는 식의 워크 브레이크다운 스트럭쳐(WSB) 방식을 택할 수 있다.

    다음은 테스팅 활동의 비용, 노력, 기간을 추정할 때 고려 해야 하는 요소들이다.

• 테스트 시작할 수 있는 시점
• 테스트 용이성
• 개발자 및 관련자들의 숙련도
• 잠재결함이 얼마나 많은가
• 개발자의 문제해결 시간
• 테스트 환경의 가용성 및 안정성
• 테스트웨어의 재사용성
• 제품의 특성
• 개발 프로세스 특성
• 테스트 결과
• 리스크 수준 및 테스트 깊이

---

테스트 모니터링과 제어

   테스트 모니터링의 목적은 정보 수집 및 테스트 활동에 대한 피드백과 가시성 제공이다. 모니터링 대상 정보는 수동 혹은 자동으로 수집할 수 있고, 테스트 진행 상황을 평가하는 데 활용한다. 테스트 제어는 수집하고 보고된 정보와 메트릭의 결과로 취해진 수정 조치나 가이드를 의미한다. 수정 조치(활동)는 어떤 테스트 활동을 커버하거나 소프트웨어 수명주기 활동에 영향을 미칠 수 있다.

  테스트 제어 활동의 예는 다음과 같다.

• 식별한 리스크 발생 시 테스트 우선순위의 변경
• 테스트 환경이나 기타 자원의 가용 여부에 따라 테스트 일정 변경
• 재작업으로 인해 테스트 항목이 시작 조건이나 종료 조건 만족하는지 재평가

테스팅에 사용하는 메트릭

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

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

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

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

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

   테스트 보고의 목적은 테스트 활동 중이나 마무리 시점의 테스트 활동 정보 요약과 공유이다. 테스트 활동 중 작성하는 테스트 보고서는 테스트 진행 상황 보고서, 테스트 활동 종료 시점에 작성하는 테스트 보고서는 테스트 요약 보고서라고 부르기도 한다.

   테스트 관리자는 테스트 모니터링과 제어 과정 중에 이해관계자에게 정기적으로 테스트 진행 상황을 보고한다. 테스트 진행 상황 보고서와 테스트 요약 보고서에 공통으로 들어가는 보고 내용은 다음과 같다.

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

    이러한 메트릭 도는 관련 정보는 리포팅 시점에 적합한 형태로 요약하고, 보고하여 다음의 내용을 평가할 수 있도록 해야 한다.

• 해당 테스트 레벨 또는 테스트 유형에 대한 테스트 목적의 적합성
• 적용된 테스트 접근법의 적합성
• 테스트 목적에 부합하는 테스트 효과성

    일반적인 테스트 진행 상황 보고서에 들어가는 정보는 아래와 같다.

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

    종료 조건을 만족하면 테스트 관리자는 테스트 요약 보고서를 작성한다. 이 보고서에는 최근 테스트 진행 상황과 기타 관련 정보에 근거해 테스팅 수행 요약 정보를 기록한다. 일반적인 테스트 요약(종료) 보고서는 다음과 같은 내용을 포함한다.

• 테스팅 수행 내용 요약
• 테스트 기간 도중에 발생한 상황 정보
• 계획 대비 편차
• 종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질(오픈 되어 있는 제품 리스크와 예상되는 영향)
• 진행을 방해했거나 계속해서 방해하고 있는 요소(해결되지 않은 결함과 그로 인해 예상되는 영향)
• 메트릭
• 잔존 리스크
• 재사용 가능한(만들어 낸) 테스트 작업 산출물
• 테스트 프로젝트 품질
• 테스트 프로젝트 수행 경험
• 다음 번 테스트에 대한 조언

    테스트 보고서는 다음과 같이 활용될 수 있다.

• 어플리케이션 출시 여부 결정
• 결함의 심각도 및 유형 파악
• (요구사항에 대한) 테스트 커버리지 확인
• 어플리케이션 품질 결정
• 다음 단계의 테스트를 위한 테스트 주요 요소 파악

    테스트 보고서의 내용은 프로젝트, 조직 요구사항, 소프트웨어 개발 수명주기에 따라 달라진다. 예를 들어 이해관계자나 규제가 많은 복잡한 프로젝트는 간단한 소프트웨어 업데이트 프로젝트보다 훨씬 상세하고 철저한 보고가 필요하다.

    테스트 보고서는 프로젝트의 정황뿐 아니라 보고의 대상자에 따라서도 조정해야 한다. 기술적인 배경이 있거나 테스트팀을 대상으로 하는 보고서의 형식이나 내용은 경영층을 대상으로 하는 요약 보고서와 달라야 한다. 전자에서는 결함 유형과 추세에 대한 상세한 정보가 중요하고, 후자에서는 상위 수준으로 작성된 보고서가 더 적절할 수 있다.

   좋은 리포팅 요건은 다음과 같다.

• 테스트 목적 및 요구사항과 일치: 개발 프로젝트를 지원한다.
• 테스트 전체와의 연계성: 테스팅 계획 및 수행과의 연계성을 확보한다.
• 단순한 결함 이상의 것들을 측정: 리스크, 커버리지, 환경 등도 함께 측정한다.
• 경향을 리포팅: 순간 포착식의 측정치는 지양한다.
• 리포트 분량의 제한: 리포트의 영향력을 높이기 위해 분량을 적절하게 제한한다.
• 리포팅의 일관성 유지: 리포팅 내용, 스타일, 표현 방식 등에 일관성을 갖는다.
• "측정"의 의미를 설명: 당연한 것으로 가정하지 말고 독자를 위해 설명한다.

테스트 제어

  테스트 제어는 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행되도록 가이드 하거나 정정하는 활동이다. 이는 테스팅 전 영역을 범위로 하며 소프트웨어 수명주기 활동이나 업무에도 영향을 줄 수 있다.

  다음은 테스트 제어활동의 예이다.

•  테스트 모니터링으로부터 얻은 정보 기반으로 의사결정을 한다.
• 프로젝트 리스크가 실제 발생 하였을 때 테스트의 우선순위를 조정한다.
• 테스트 환경의 가용성 이슈가 있을 경우 테스트 일정을 변경한다.
• 수정사항을 빌드에 반영하기 전에, 해당 수정사항을 개발자가 재테스트 하도록 요구하는 것과 같은 테스트 시작 조건을 정한다.

테스트 완료

   테스트 완료는 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에서 계획했던 모든 항목들이 완료 되면 시작하는 활동이다. 이 활동의 주요 목적은 테스트 자산 및 테스트 환경을 보존하고, 테스팅 활동에서의 교훈을 찾아내어 이해관계자와 공유하기 위함이다.

   테스트 완료 단계의 주요 활동 및 내용을 살펴보면 다음과 같다.

• 테스트 계획서, 자동화 테스트 절차 및 메뉴얼, 테스트 환경 구성도 등과 같은 테스트 자산을 식별하고, 형상관리 등을 통해 보존한다.
• 다른 프로젝트 또는 다음 단계의 테스팅 활동에서 재사용 가능한 테스트 자산을 식별한다.
• 재사용 가능한 테스트 자산 또는 환경을 문서화 하고 이를 이해관계자와 공유한다.
• 테스트 환경을 다음 단계의 문제점 및 개선점을 찾아 교훈으로 기록한다.
• 교훈을 공유한다.
• 테스트 완료 보고서에 테스트 계획대비 실적, 결함 상태, 리스크 등과 함께 테스트 자산의 보존 상황 및 교훈을 기록하고 이를 이해관계자에게 보고한다.

---

형상 관리(Configuration Managemen)

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

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

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

---

리스크와 테스팅

리스크의 정의

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

   레이놀즈는 리스크를 "장애로 인해 주어진 기간에 발생 가능한 비용"으로 정의하고 리스크를 다음과 같이 산출하고자 하였다.

리스크(Risk) = 장애(Failure) 가능성 X 손실(Damage)

   여기서 장애가능성은 사용 빈도와 결함 가능성을 곱한 값으로 볼 수 있으므로 리스크를 아래와 같이 산출할 수 있다.

리스크(Risk) = 사용 빈도(Frequency of use) X 결함 가능성(Chance of defect) X 손실(Damage)

프로젝트 리스크

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

• 프로젝트 이슈
  • 배포, 작업 완료, 종료 조건이나 완료의 정의를 만족하지 못하고 지연된다.
  • 부정확한 추정, 우선순위가 높은 프로젝트에 예산 재배정, 또는 조직 전반에 걸친 예산 삭감으로 예산이 부족할 수 있다.
  • 프로젝트 후반에 발생하는 변경은 상당한 재작업을 불러올 수 있다.
• 조직 이슈
  • 역량, 교육, 인력이 부족할 수 있다.
  • 개인적인 문제로 갈등이나 문제가 생길 수 있다.
  • 사용자, 비즈니스 인력, 해당 분야 전문가들이 비즈니스 우선순위 마찰로 참여하지 못할 수 있다.
• 정치적 이슈
  • 테스터가 필요한 사항이나 테스트 결과를 제대로 전달하지 못할 수 있다.
  • 개발자나 테스터가 테스팅과 리뷰 도중 발견한 사항에 대한 후속 조치를 못할 수 있다.
  • 테스팅에 대한 잘못된 태도나 기대가 있을 수 있다.
• 기술적 이슈
  • 요구사항이 충분히 잘 정의되지 않을 수 있다.
  • 기존 제약 사항으로 요구사항 및 수용되는 정도(범위)을 만족하지 못할 수 있다.
  • 테스트 환경이 필요한 시점에 준비되지 않을 수 있다.
  • 데이터 변환, 마이그레이션 계획 및 도구 지원이 필요한 시점에 제공되지 않을 수 있다.
  • 개발 프로세스의 약점은 프로젝트 작업 산출물의 품질이나 일관성에 영향을 줄 수 있다.
  • 결함 관리가 부실하고 기타 유사한 문제 때문에 축적된 결함이나 기타 기술적 부채를 가져올 수 있다.
• 공급자 이슈
  • 외부 공급자가 필요한 제품이나 서비스를 공급하지 못하거나 파산할 수 있다.
  • 계약 관련 이슈로 프로젝트에 문제가 생길 수 있다.

   프로젝트 리스크는 개발 활동과 테스트 활동 양쪽 모두에 영향을 미칠 수 있다. 프로젝트 관리자가 모든 프로젝트 리스크에 대한 책임을 지는 것이 일반적이지만, 테스트와 관련된 프로젝트 리스크는 테스트 관리자가 책임을 지는 경우도 있다.

제품 리스크

    제품 리스크는 작업 산출물이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성이다. 제품 리스크가 제품의 특정 품질 특성과 연관되는 경우 품질 리스크라고 한다. 제품 리스크의 예는 다음과 같다.

• 소프트웨어가 명세에서 의도한 기능을 수행하지 못함
• 소프트웨어가 사용자, 고객이나 이해관계자가 요구하는 기능을 수행하지 못함
• 시스템 아키텍처가 일부 비기능 요구사항을 충분히 지원하지 못함
• 특정 계산식이 특정 상황에서 올바르게 수행되지 못함
• 루프(loop) 제어 구조 코딩이 잘못됨
• 고성능 거래 처리 시스템의 응답 시간이 적절하지 않음
• 사용자 경험(UX, User eXperience) 피드백이 제품 기대치에 미치지 못함
• 취약한 소프트웨어 특성
• 소프트웨어 및 하드웨어가 개인이나 회사에 손실을 끼칠 가능성
• 개발팀에서 전달 받은 장애 가능성이 높은 소프트웨어

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

   리스크는 테스팅 노력을 집중하는 데 사용된다. 리스크는 테스팅을 언제, 어디서 시작할지 결정하고 좀 더 관심을 가져야 할 영역을 식별하는 데 사용된다. 테스팅은 부정적인 이벤트의 발생 가능성을 줄이거나 부정적인 이벤트의 영향을 줄이기 위해 사용한다. 리스크 완화 활동으로써 테스팅은 식별한 리스크뿐 아니라 잔존(해결하지 못한) 리스크에 대한 정보도 제공한다.

    리스크 기반 접근법은 제품 리스크 수준을 조기에 낮추는 데 기여한다. 리스크 기반 테스팅은 제품 리스크 식별과 리스크 발생 가능성과 영향을 평가하는 제품 리스크 분석을 포함한다. 제품 리스크 정보로 얻은 결과는 테스트 계획, 명세, 테스트 케이스 준비와 실행, 테스트 모니터링에 사용한다. 초기에 제품 리스크를 평가하면 프로젝트 성공에 기여한다.

   리스크 기반 접근법에서 제품 리스크 분석 결과는 다음에 사용된다.

• 사용할 테스트 기법 결정
• 수행할 테스트 레벨과 유형 확정
• 테스트 수행 범위 결정
• 가능한 조기에 심각한 결함을 발견하기 위해 테스트 우선순위 결정
• 기존 테스팅 활동 외 리스크 완화를 위한 다른 활동의 식별

   리스크 기반 테스팅은 프로젝트 이해관계자의 집단 지식과 통찰력을 기반으로 제품 리스크를 분석한다. 제품 장애 발생 가능성을 최소화하기 위해 리스크 관리 활동은 다음과 같은 절차를 따르게 된다.

• 리스크 식별 단계: 잘못될 수 있는 것(리스크)을 분석 (그리고 정기적으로 재분석)
• 리스크 분석: 처리해야 할 중요한 리스크가 무엇인지 판단
  • 장애 발생 빈도와 장애로 인한 영향을 식별
  • 리스크의 우선순위 결정
• 리스크 계획 활동: 해당 리스크를 완화하기 위한 행동 구현
• 리스크 추적: 리스크의 실제 발생을 대비한 대책 수립

   또 테스팅은 새로운 리스크를 식별하고 어떤 리스크를 완화해야 하는지 판단하는 데 도움을 주며 리스크에 대한 불확실성을 낮춰준다.

리스크 식별(Risk Identification) 단계

    리스크는 다양한 방법으로 식별이 가능한데, 일반적으로 테스트 대상을 기능적 또는 기술적 아이템으로 분리하여 각각의 아이템에 리스크가 존재하는 것으로보는 것이다. 이 밖에도 요구사항 분석서에서 상위레벨 테스트를 필요하는 항목과 아키텍처에서 하위 레벨 테스트가 필요한 항목들을 도출하면 이것들도 리스크 아이템이 된다. 리스크 아이템은 브레인 스토밍 세션을 이용하여 효율적으로 식별할 수도 있다. 그리고 도출한 리스크 아이템을 의미 있는 그룹으로 묶어 리스크 분석 단위를 만든다. 가급적이면, 하나의 리스크 분석단위에 너무 많은 리스크 아이템이 들어가는 것이 좋지 않다.

리스크 분석(Risk analysis) 단계

   리스크 분석은 중요하고, 복잡하고, 잠재적으로 결함이 많은 소프트웨어나 시스템의 부분을 분석하여 장애 발생 가능성과 장애로 인한 영향 도는 손실을 예측하여 리스크 우선순위를 결정하는 것이다. 이 단계에서는 결함 패턴 등 기존 프로젝트에 기반하여 장애 발생 가능성을 높여주는 리스크 요소와 장애로 인한 영향 또는 손실을 높이는 리스크 요소를 결정한 후 이해관계자를 참여시켜 이들의 타당성을 검토한다.

   리스크 요소는 아래와 같이 도출할 수 있다.

• 장애 발생 가능성(Likehood)
  • 복잡성
  • 새로운 개발의 강도
  • 상호관계
  • 프로그램 소스 코드의 크기
  • 사용된 기술의 난이도/최신성
  • 개발팀의 경험 미흡
• 장애로 인항 영향(Impact)
  • 사용자에 의한 취급 중요도
  • 경제적, 안전적, 회사 이미지 피해
  • 사용 빈도
  • 외부적 가시성

  리스크 요소가 결정되었다면 리스크 아이템 별로 해당 리스크 요소가 어느 정도의 수준인지를 결정한다. 이때, 이해관계작의 참여가 필수적이다. 이후 리스크를 기술적 요소와 사업적 요소로 분리하여 분석하는 데 각각 다음과 같은 특징이 있다.

• 기술적 리스크는 단위/통합 테스팅과 직접적으로 관련됨
  • 장애 발생 가능성 관리
• 사업적 리스크는 인수 테스팅과 직접적으로 관련됨
  • 발생한 장애로 인한 영향 관리

리스크 계획(Risk planning) 단계

   리스크 계획 활동은 리스크 분석 결과를 근거로 대처 방안 수입, 즉 리스크를 줄이는 "테스트"를 생성하는 것이다. 위와 같이 발생가능성과 영향도를 기준으로 테스트를 실행하는 전략도 다음과 같이 상이하다.

• 리스크가 가장 높은 영역(STA)에 있는 리스크 아이템은 공식적으로 테스트를 설계하고, 경계값 분석 기법을 적용하고, 구문 커버리지를 90% 확보할 수 있도록 하며, 완전한 코드 인스펙션을 수행한다.
• 장애 발생 가능성은 높고 영향이 낮은 영역(ITA)에 있는 리스크 아이템은 구문 커버리지 70%를 확보하고 페어 인스펙션을 수행한다.
• 장애 발생 가능성은 낮고 영향이 높은 영역(STTA)에 있는 리스크 아이템은 구문 커버리지 70%를 확보해야한다.
• 장애 발생 가능성과 영향이 모두 낮은 영역(FTA)에 있는 리스크 아이템은 기회가 되면 자유롭게 테스팅한다.

리스크 추적(Risk trace) 단계

    리스크 추적 단계를 거쳐 수립한 테스트 전략을 테스팅 프로젝트 동안 준수하고, 이슈가 없는지에 대해 모니터링하고 제어하는 활동을 말한다.

---

결함 관리(Defect Management,인시던트 관리(Incident management))

    테스팅의 목적 중 하나가 결함을 찾는 것이기 때문에 테스팅 중 발견한 결함은 반드시 기록해야 한다. 결함을 기록하는 방법은 테스트 대상 컴포넌트나 시스템의 정황, 테스트 레벨, 소프트웨어 개발 수명주기 모델에 따라 달라진다. 찾아낸 모든 결함은 조사하고, 발견에서 결함 분류까지 추적해야 한다. 모든 결함을 해결까지 관리하기 위해 조직은 결함 관리 프로세스(워크플로우와 결함 분류 규칙)를 수립해야 한다. 아키텍처, 설계자, 개발자, 테스터, 제품 책임자 등 결함 관리에 참여하는 모든 사람이 프로세스에 동의해야 한다. 일부 조직에서는 결함 로깅(logging)과 추적이 매우 비공식적일 수 있다.

   결함 관리 프로세스를 수행하다 보면 일부 보고는 결함에 의한 실제 장애가 아닌 거짓양성으로 보고되기도 한다. 예를 들어 네트워크 연결이 끊기거나 시간 초과(time out)로 테스트 결과는 불합격이 될 수 있다. 이런 결과는 테스트 대상의 결함 때문이 아니라 이상 현상(anomaly) 때문일 수 있어 조사가 필요하다. 테스터는 결함으로 보고하는 거짓양성의 수를 최소화해야 한다.

   결함은 코드 작성 중, 정적 분석, 리뷰, 동적 테스팅 또는 소프트웨어 제품을 사용하는 중에 보고할 수 있다. 결함은 코드나 운영 중인 시스템이나 요구사항, 사용자 스토리와 인수 조건, 개발 문서, 테스트 문서, 사용자 매뉴얼, 설치 가이드 같은 문서에서 이슈로 보고할 수 있다. 효율적이고 효과적인 결함 관리 프로세스를 위해 조직은 결함의 속성, 분류, 워크플로우에 대한 표준을 정의해 놓을 수 있다.

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

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

   동적 테스팅에서 작성하는 결함 보고서의 내용은 일반적으로 다음과 같다.

• 식별 번호
• 제목, 보고하는 결함에 대한 짧은 요약
• 결함 보고 날짜, 보고 주체 조직 및 작성자
• 테스트 항목 식별자(테스트 대상 형상 항목)와 환경
• 결함을 발견한 개발 수명주기 단계
• 로그, 데이터베이스 덤프, 스크린샷, 녹화 기록(테스트 실행 중 녹화했다면) 등의 결함 재현과 해결을 위한 설명
• 기대 및 실제 결과
• 이해관계자의 관점에서의 결함 영향도(심각도)의 범위와 정도
• 수정 우선순위 (긴급하게 처리해야 하는 순서)
• 결함 보고서의 상태
• 결론, 의견, 승인 여부
• 글로벌 이슈
• 변경 이력
• 참조 (문제를 발견하게 해 준 테스트 케이스 포함)

   결함 관리 도구를 사용하면 위 정보 중 일부는 자동으로 작성될 수 있다. 정적 테스팅, 특히 리뷰에서 발견하는 결함은 다양한 방법으로 문서화한다.

---

테스트 프로세스 평가

   테스트 프로세스는 크게 3가지 관점에서 제시한다.

   조직차원의 테스트 프로세스(Organizational Test Process)는 조직이 테스팅을 하는 이유 및 목적을 기술하는 테스트 정책과 테스팅 접근에 대한 조직 차원의 테스트 전략을 수립하고 적용하며 개선하도록 하는 프로세스이다.

   테스트 매니지먼트 프로세스(Test Management Process)는 소프트웨어 개발 프로젝트에서 총괄적으로 수행해야 할 테스팅을 레벨 별로 또는 유형 별로 수행되도록 관리하고 통제 하는 프로세스를 의미한다.

   정적, 도적 테스트 프로세스(Static and Dynamic Test Process)는 소프트웨어 개발 수명주기 전반에 걸친 정적 테스트를 위한 준비 단계, 리뷰/분석 단계, 후속 처리 과정에 대한 프로세스와 각 테스트 레벨 또는 특정 테스트 유형에서 수행해야 할 분석 및 설계, 구현 및 실행, 결함 보고, 환겨 구성 및 유지 보수 활동 등의 동적 테스트 프로세스를 의미한다.

    테스트 프로세스 개선활동을 성공적으로 수행하여, 테스트 프로세스 성숙도가 높아지면, 다음과 같은 효과를 기대할 수 있다.

• 정렬되고 조지고하되며 반복적이 된다.
• 전문적이고 공학적인 활동으로 인식된다.
• 개발 활동과는 독립적으로 수행된다.
• 결함 발견 활동에서 결함 예방 활동으로 변화된다.
• 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악하게 된다.
• 지속적으로 개선되고 향상된다.
• 테스트 비용을 절감시키고 조직 구성원의 만족감을 고취시킨다.

	TMMi	TMP
테스트 레벨	하위 레벨과 상위 레벨 테스팅을 유사한 수준으로 다룸	상위레벨 테스팅에 보다 집중
성숙도 평가 접근법	하향식 개선 프로세스를 지향하는 조직 차원에서의 성숙도 평가	상향식 모델로 특정 프로젝트나 프로그램에 대한 테스트 개선을 적절하게 조언
테스트 핵심영역 간 의존성 여부	핵심 영역간 의존성을 정의하지 않음	핵심 영역간의 의존성 정의
모델의 태생	학계에서 개발하여 업계에서 발전시킴	시스템 테스팅 전문 업체에서 개발하여 확산
공식 레벨 부여 여부	TMMi Foundation 공식인증제도	부여하지 않음
관련 모델	OMMI와 밀접한 관련이 있음	TMap 테스트 방법론과 강한 연결고리가 존재

  TMMi 모델의 각 다섯 레벨의 세부 내용은 다음과 같다.

1. 레벨1은 기본적으로 주어진 레벨로 레벨 2를 달성하고 있지 못하면 레벨1이다.(레벨 1을 달성하는 지를 평가하는 기준은 존재하지 않는다.)
2. 레벨 2에 도달한 조직은 테스트 단계를 정의하고 체계적으로 테스팅을 진행한다. 가장 어렵고 시간이 많이 소요될 수 있다. 이 레벨에서 테스팅은 디버깅 활동과는 명확하게 분리하여 관리한다. 레벨 2에 도달하기 위해서는 조직차원의 테스트 정책 및 테스트 전략을 수립하고 이를 반영한 테스트 계획이 프로젝트 별로 수립되어야 한다. 또한 테스트 목표를 명확히 하고 제품의 리스크 수준을 근거로 한 테스트 전략 또는 접근법이 테스트 계획에 반영 되어야 한다. 뿐만 아니라 테스팅이 테스트 계획을 기반으로 모니터링 및 제어 되어야 한다. 그리고 테스트 케이스 작성을 위해 테스트 설계기법을 테스트 전략에 근거하여 적용하고 있어야 한다. 이 밖에도 문서화된 절차에 따라 테스트 환경을 확보하고 관리하여야한다.
3. 레벨 3에서의 테스팅은 더 이상 개발 이후의 작업이 아니다. 즉, 개발 수명주기와 밀접하게 통합되는 단계로 테스트 계획이 프로젝트 초반, 즉 요구사항 정의 단계에 수립되어야한다. 레벨 2에서도 주장한 테스트 설꼐가 기능 테스트 뿐 아니라, 사용성 또는 신뢰성과 같은 비 기능 테스트 영역에서도 적요오디어야 한다. 레벨 3은 각 프로젝트마다 사오항에 맞게 변형하여 사용할 수 있는 조직차원의 테스트 표준을 갖도록 하여 보다 일관성 있고 견고한 프로세스를 갖추도록 한다.
4. 레벨 4는 테스트를 관리하고 측정하는 단계로 정량적인 측정을 통해 소프트웨어 품질 평가 및 테스팅을 평가하며 이러한 것들을 관리하는 기준으로 삼는다. 공식적인 리뷰활동이 수행되어야 하며, 이는 테스팅의 한 파트이며 동시에 문서의 표준을 평가하기 위해서도 사용할 수 있다. 또한 소프트웨어 품질평가를 위한 특성 별 정량적 기준을 마련하고 이를 측정해야 한다.
5. 레벨 5는 테스트 프로세스를 최적화하고 지속적으로 개선하는 단계로 조직은 테스트 비용과 테스트 효과 통제가 가능하며, 제품에 대한 품질 통제 및 결함을 예방하는 지속적으로 집중한다.

---

주섬주섬

   공부 정리를 위한 블로그이며, "개발자도 알아야 할 소프트웨어 테스팅 실무 제3판"과 실라버스를 참고하였다.

참고

STEN