ISTQB - CTFL [테스트 활동 관리] 테스트 계획 정리

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

테스트 계획서는 테스트 프로세스의 목적, 자원, 프로세스를 설명한다.

• 테스트 목적 달성을 위한 방법과 일정을 문서화한다.
• 수행한 테스트 활동이 정해진 기준을 충족하는 데 도움을 준다.
• 팀원과 기타 이해관계자의 의사소통을 수단으로 사용된다.
• 테스팅이 수립한 테스트 정책 및 전략을 준수함을 보여준다(또는 테스팅이 그것을 준수하지 않는 이유를 설명한다.)

테스트 계획 활동

• 테스터가 리스크, 일정, 인력, 도구, 비용, 노력 등 향후 문제를 고민하도록 한다.
• 테스트 계획서를 준비하는 과정은 테스트 목적을 달성하는 데 필요한 노력을 추론하는 유용한 방법이다.

테스트 계획서는 다음과 같은 내용을 포함해야 한다.

• 테스트 정황(테스트 범위, 테스트 목적, 테스트 베이시스)
• 테스트 프로젝트의 가정 및 제약 사항
• 이해관계자(역할, 책임, 테스팅 관련성, 채용 및 훈련 요구사항)
• 의사소통(의사소통 방법 및 빈도, 문서 양식)
• 리스크 목록(제품 리스크, 프로젝트 리스크)
• 테스트 접근법(테스트 레벨, 테스트 유형, 테스트 기법, 테스트 산출물, 시작 조건 및 완료 조건, 테스팅의 독립성, 수집할 메트릭, 테스트 데이터 요구사항, 테스트 환경 요구사항, 테스트 정책과 테스트 전략과의 편차)
• 예산 및 일정

반복 주기와 릴리스 계획에 대한 테스터의 기여

일반적으로 반복적 소프트웨어 개발수명주기(SDLC)에서 두 가지의 계획, 즉 릴리스 계획과 반복 주기 계획이 이루어진다.

릴리스 계획

• 제품 릴리스를 계획하는 단계로 제품 백로그를 (재)정의하며, 큰 사용자 스토리를 작은 사용자 스토리들로 세분화하는 작업을 포함할 수 있다. 또한, 개별 반복 주기의 테스트 접근법과 테스트 계획을 위한 기반이 된다.
• 릴리스 계획에 참여하는 테스터는 테스트 가능한 사용자 스토리와 인수 조건이 작성되도록 하고, 프로젝트 및 품질 리스크 분석에 참여하고, 사용자 스토리와 관련된 테스트 노력을 추정하고, 테스트 접근법을 결정하고, 릴리스를 위한 테스팅을 계획한다.

반복 주기 계획

• 개별 반복 주기를 계획하는 것으로 반복 주기 백로그와 관련이 있다.
• 반복 주기 계획에 참여하는 테스터는 사용자 스토리의 구체적인 리스크 분석에 참여하고, 사용자 스토리의 테스트 용이성을 판단하고, 사용자 스토리 업무(특히 테스팅 업무) 단위로 분류하고, 각 테스팅 업무에 필요한 테스트 노력을 추정하고, 테스트 대상의 기능 및 비기능적 측면을 식별하고 구체화한다.

시작 조건과 완료 조건

시작 조건

• 어떤 활동을 수행하기 위한 전제 조건을 정의한다.
• 시작 조건을 충족하지 못하면 해당 활동을 수행하는 것이 어려워져 들어가는 시간과 비용이 증가하고, 원활하게 진행되지 않을 위험도 높아진다.

많이 사용하는 시작 조건

• 자원의 가용성(인력, 도구, 환경, 테스트 데이터, 예산, 시간), 테스트웨어 가용성(테스트 베이시스, 테스트 가능한 요구사항, 사용자 스토리, 테스트 케이스), 테스트 대상의 초기 품질 수준(모든 스모크 테스트가 합격함)등이 있다.

완료 조건

• 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항들을 정리한다.
• 시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 한며 테스트 목적에 따라 달라진다.

일반적인 테스트 완료 조건

• 테스트의 철저함(thoroughness)을 측정하는 지표(달성한 커버리지 수준, 미해결 결함 수, 결함 밀도, 실패한 테스트 케이스 수)와 "에/아니오"로 판단되는 기준(계획한 모든 테스트가 실행되었는가, 정적 테스팅이 수행되었는가, 발견한 모든 결함이 보고되었는가, 모든 리그레션 테스트가 자동화 되었는가)
• 시간 및 예산의 소진도 유효한 완료조건으로 볼 수 있다.
  - 이때 이해관계자들이 추가 테스트 없이 배포하는 리스크를 검토하고 수용했다면, 다른 완료 조건이 충족되지 않더라도 테스트를 종료할 수 있다.
• 애자일 소프트웨어 개발에서 완료 조건을 완료의 정의(Definition of Done)라고 하는 경우가 많으며, 릴리스 가능 항목에 대한 팀의 목표 메트릭을 정의하게 된다.
• 개발 및 테스트 활동을 시작하기 위해 사용자 스토리가 충족해야 하는 시작 조건을 준비의 정의(Definition of Ready)라고 한다.

추정 기법

테스트 노력 추정

테스트 프로젝트의 테스트 목적을 달성하는 데 필요한 테스트 관련 작업량을 에측하는 것이다.

추정치

여러 가정을 기반으로 하며, 추정에는 항상 오류가 있을 수 있다는 점을 이해관계자가 명확히 이해하도록 하는 것이 중요하다.

보통은 규모가 큰 작업보다 작은 작업에 대한 추정치가 정확하다.

따라서 큰 작업에 대해 추정할 때는 우선 여러 개의 작은 작업으로 나눈 다음 추정하게 된다.

네 가지 추정 기법

비율 기반 추정(Estimation based on ratios)

• 매트릭 기반 기법으로 조직에서 수행한 이전 프로젝트 수치를 수집해 유사 프로젝트를 위한 "표준" 비율을 도출한다.
• 보통 조직에서 직접 수행한 프로젝트에서 수집한 비율(과거 데이터에서 가져온)이 과정에 사용하기 가장 좋은 자료이다.
• 이런 표준 비율을 가지고 새로운 프로젝트에 필요한 테스트 노력을 추정할 수 있다.

ex) 이전 프로젝트에서 개발 노력 대 테스트 노력의 비율이 3:2였고, 현재 프로젝트에서 개발 노력을 600MD로 예상한다면, 테스트 노력은 400MD로 추정할 수 있다.

외삽법(Extrapolation)

• 메트릭 기반 기법으로 현재 프로젝트에서 데이터 수집을 위해 가능한 빨리 수행한다.
• 관찰 결과가 충분히 쌓이면 이 데이터를 가지고 외삽법(보통 수학적 모델 사용)을 적용해 남은 작업에 필요한 노력의 근사치를 추정할 수 있다.
• 이 방법은 반복적 소프트웨어 개발수명주기(SDLC)에 매우 적합하다.

ex) 팀이 지난 세 번의 반복 주기에 들인 평균 노력을 다음 반복 주기의 테스트 노력을 추정할 수 있다.

와이드밴드 델파이

• 반복적, 전문가 기반 기법으로 전문가의 경험을 기반으로 추정을한다.
• 각 전문가는 독립적으로 노력을 추정한다.
• 결과가 수집되거, 전문가의 추정 값 중 합의된 범위를 벗어난 편차가 있으면 전문가들이 각자의 현재 추정치에 대해 논의한다. 그런 다음 각 전문가에게 논의 결과를 바탕으로 다시 한번 새로운 추정치를 제시하도록 한다.
• 합의에 도달할 때까지 이 과정을 반복한다.

플래닝 포커(Planning Poker)

• 애자일 소프트웨어 개발에서 많이 사용하는 와이드밴드 델파이의 변형이다.
• 플래닝 포커는 보통 노력의 규모를 나타내는 숫자가 적힌 카드를 사용해 추정한다.

3점 추정(Three-point estimation)

• 전문가 기반 기법으로 전문가가 세 개의 추정치를 도출한다.
• 추정치는 가장 낙관적인 추정치(a), 확률적으로 가장 높은 추정치(m), 가장 비관적인 추정치(b)이다.
• 최종 추정치(E)는 이들의 가중 산술 평균이 된다. 
• 가정 널리 사용하는 계산식: E=(a+4*m+b)/6이다.
• 이 기법의 장점은 전문가가 측정 오류를 계산할 수 있다는 것이다.
• SD(표준 편차, Standard deviation) = (b-a)/6이므로 최종 추정치는 10±2(즉, 8과 12 사이의 맨아워)가 된다.

테스트 케이스 우선순위지정

테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다.

테스트 일정은 테스트 실행 순서를 정의한다.

테스트 케이스의 우선순위를 정할 때 다양한 요소를 고려할 수 있다.

많이 사용하는 테스트 케이스 우선순위지정법

• 리스크 기반 우선순위지정
  - 리스크 분석 결과에 따라 테스트 실행 순서를 결정한다.
  - 가장 중요한 리스크를 다루는 테스트 케이스를 먼저 실행한다.
• 커버리지 기반 우선순위지정
  - 테스트 실행 순서를 커버리지(구문 커버리지)에 따라 결정한다.
  - 가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행한다.
  - "추가 커버리지 우선순위지정"이라는 다른 변형에서는, 가장 높은 커버리지를 달성하는 테스트 케이스가 먼저 실행된다.
  - 이후에 실행되는 각각의 테스트 케이스는 가장 높은 추가 커버리지를 달성하는 것이다.
• 요구사항 기반 우선순위지정
  - 테스트 실행 순서를 해당 테스트 케이스의 기반이 되는 요구사항의 우선순위에 따라 결정한다.
  - 요구사항의 우선순위는 이해관계자가 정의한다.
  - 가장 중요한 요구사항 관련 테스트 케이스를 먼저 실행한다.

3 가지 중 하나, 또는 여러 전략을 사용해 우선순위를 지정해서 테스트 케이스 실행 순서를 도출하는 것이 이상적이다.

그러나 테스트 케이스 또는 테스트 대상 기능이 종속성을 가진 경우 그렇게 하기 힘들 수 있다.

우선순위가 높은 테스트 케이스가 우선순위 낮은 테스트 케이스에 종속되는 경우, 우선순위가 낮은 테스트 케이스를 먼저 실행해야 할 수도 있다.

테스트 실행 순서에서는 자원의 가용성도 고려해야 한다.

ex) 필요한 테스트 도구, 테스트 환경, 인력이 가용한 시기가 따로 있을 수 있다.

테스트 피라미드

• 테스트에 따라 세분화 수준(granularity)이 다를 수 있다는 것을 보여주는 모델이다.
• 다양한 테스트 목표가 서로 다른 테스트 자동화 수준에 따라 지원된다는 것을 보여줌으로써 팀의 테스트 자동화와 테스트 노력 할당을 지원한다.
• 피라미드의 각 층은 하나의 테스트 그룹을 나타낸다.
• 층이 높아질수록 테스트 세분화 정도는 낮아지고, 테스트 격리는 낮아지며(즉, 시스템의 다른 요소에 대한 의존도), 테스트 실행 시간은 길어진다.
• 아래층에 있는 테스트는 규모가 작고, 돌깁적이며, 빠르고, 대상이 되는 기능은 작기 때문에 적절한 커버리지를 달성하기 위해 많은 테스트가 필요한 경우가 많다.
• 높은 층은 복잡하고 상위 수준의 엔드-투-엔드 테스트를 대변한다.
• 이런 상위 수준 테스트는 일반적으로 하위층의 테스트보다 실행 속도가 느리며, 보통 큰 규모의 기능을 확인하기 때문에 적은 수로 적절한 커버리지를 달성할 수 있다.
• 층의 수와 각 층의 명칭은 다를 수 있다.

ex) 최초의 테스트 피라미드 모델은 "단위 테스트", "서비스 테스트", "UI 테스트"라는 세 개의 층을 정의했다. 단위(컴포넌트) 테스트, 통합(컴포넌트 통합) 테스트, 엔드-투-엔드 테스트로 정의하는 모델도 많이 알려져 있다. 또한 다른 테스트 레벨 분류를 사용하기도 한다.

테스트 사분면

브라이언 마릭이 정의한 테스팅 사분면은 애자일 소프트웨어 개발에서 테스트 레벨을 적합한 테스트 유형, 활동, 테스트 기법, 작업 산출물과 묶고 있다.

애자일 테스팅 사분면

이 모델은 이런 사항들을 시각화해서 테스트 관리자가 필요한 모든 테스트 유형과 테스트 레벨을 소프트웨어 개발수명주기(SDLC)에 포함하고, 테스트 레벨에 따라 테스트 유형 별 연관성이 다르다는 점을 이해하는 데 도움을 준다.

이 모델은 개발자, 테스터, 비즈니스 담당자 등 모든 이해관계자에게 테스트 유형을 구분하고 설명하는 방법을 제공한다.

 

이 모델에서의 테스트는 비즈니스 또는 기술에 대한 테스트일 수 있다.

테스트는 팀을 지원하거나(즉, 개발을 위한 지침으로) 제품을 평가할 수도 있다.(즉, 기대치 대비 동작 측정)

이 두 가지의 조합에 따라 네 개의 사분면이 결정된다.

• 1 사분면(기술 측면, 팀 지원)
  - 테스트 및 컴포넌트 통합 테스트를 포함한다.
  - 이런 테스트는 자동화해야 하며, 지속적인 통합(CI) 프로세스에 포함돼야 한다.
• 2 사분면(비즈니스 측면, 팀 지원)
  - 기능 테스트, 예제, 사용자 스토리 테스트, 사용자 경험 프로토타입, API 테스팅, 시뮬레이션 등을 포함한다.
  - 이런 테스트는 인수 조건을 확인하며, 수동으로 실행하거나 자동화할 수 있다.
• 3 사분면(비즈니스 측면, 제품 평가)
  - 탐색적 테스팅, 사용성 테스팅, 사용자 인수 테스팅을 포함한다.
  - 이런 테스트는 사용자를 중심으로 이루어지며, 수동으로 실행하는 경우가 많다.
• 4 사분면(기술 측면, 제품 평가)
  - 스모크 테스트와 비기능 테스트(사용성 테스트 제외)를 포함한다.
  - 이런 테스트는 자동화되는 경우가 많다.

정리

5장은 QA의 역할이

테스트 실행자에서 관리자로 확장되는 지점이다.( “QA는 왜 일정 이야기를 하고, 우선순위를 말하는가” )

테스트 관리란?

테스트 관리는 테스트 활동을 계획하고, 모니터링하고, 통제하는 모든 활동을 의미한다.

• 무엇을 테스트할지
• 언제까지 할지
• 어떤 기준으로 끝낼지

위 내용을 정하는 과정이다.

QA 실무에서는 테스트 관리가 잘 될수록 팀 전체의 테스트 효율이 높아진다.

테스트 계획(Test Plan)의 핵심 요소

테스트 계획은 테스트 관리의 시작점이다.

테스트 계획 구성 요소

항목	설명
테스트 범위	무엇을 테스트할지
테스트 제외 범위	무엇을 하지 않을지
테스트 일정	테스트 수행 기간
테스트 자원	인력, 환경
리스크	주요 위험 요소
종료 기준	테스트 완료 조건

모든걸 완벽히 문서화하기보다 핵심만 명확히 정리하는 것이 더 중요하다.

테스트 종료 기준(Exit Criteria)

테스트 종료 기준은 언제 테스트를 끝낼 것인지 결정하는 기준이다.

• 주요 결함 해결 완료
• 핵심 시나리오 테스트 완료
• 일정 도래

실무에서는 완벽해서 끝나는 경우보다 합의된 기준에 따라 종료하는 경우가 많다.

---

Reference

https://www.kstqb.org/sw/sw3.asp

KSTQB

https://qa-note.tistory.com/25

📗 ISTQB 실러버스 정리 5장 — 테스트 관리와 리스크 기반 테스트

https://oasis5pm.wordpress.com/2015/04/22/%EC%95%A0%EC%9E%90%EC%9D%BC-%ED%85%8C%EC%8A%A4%ED%8C%85-part3/

애자일 테스팅 Part3