학습목표
5.2 테스트 계획과 추정 (Test Planning and Estimation)
FL-5.2.1 테스트 계획의 목적 과 내용을 요약할 수 있다.
FL-5.2.2 여러 테스트 전략을 구별할 수 있다.
FL-5.2.3 시작 조건과 종료 조건에 대한 예제를 들 수 있다.
FL-5.2.4 우선순위, 기술적 및 논리적 의존성 정보를 이용해 테스트 케이스 실행 일정을 수립할 수 있다.
FL-5.2.5 테스팅과 연관된 노력에 영향을 주는 요소를 식별할 수 있다.
FL-5.2.6 메트릭 기반 추정 기법과 전문가 기반 추정 기법의 차이를 설명할 수 있다.
5.2 테스트 계획과 추정 (Test Planning and Estimation)
5.2.1 테스트 계획의 목적과 내용
📆테스트 계획
- 계획 : 테스트 계획서의 수립 또는 수정 활동으로 테스트 목적, 테스트 범위, 필요한 자원 그리고 일정을 결정
- 계획서 : 테스팅 활동 조정에 사용되며, 주어진 시간안에 끝내야할 "무엇"을 달성할 테스트 목표와 그것을 달성하기 위한 방법과 일정을 설명하는 문서
🎯테스트 목적
🌐개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용
🎨계획에 영향을 주는 요소
조사 범목리 제심 용가
- 조직 차원에서 테스트 정책과 테스트 전략
- 사용하는 개발 수명주기 및 방법
- 테스팅 범위
- 목적
- 리스크
- 제약
- 심각도
- 테스트 용이성
- 자원의 가용성
🚬제품의 수명주기 전반에 걸쳐 이루어지는 지속적인 활동
✅테스팅의 범위 정의, 목적, 리스크 결정
마스터 테스트 계획의 일부로 작성하거나 시스템 테스팅, 인수 테스팅과 같은 테스트 레벨별테스트 또는 유형별 사용성 테스팅, 성능 테스팅과 같은테스트 계획으로 나눠서 작성
테스트 활동의 피드백으로 리스크의 변화를 인지하고 테스트 계획을 수정되고 정보가 상세화 될 수록 테스트 계획 역시 상세화
🙋🏽♂️활동 내용
- 테스트 활동을 소프트웨어 📈수명주기 활동에 통합하고 조정
- 테스트 대상 다양한 테스트 활동에 필요한 🧑🏽💻인력과 기타 자원, 테스트 활동 ➡️수행 방법 결정
- 테스트 분석, 설계, 구현, 실행, 평가 활동의 📅일정 조정. 일정은 특정 날짜(예: 순차적 개발에서)나 반복주기 단위(예: 반복적 개발)로 편성할 수 있다.
- 테스트 📺모니터링과 제어에 사용할 메트릭 선정
- 테스트 활동 💸예산 결정
- 테스트 📜문서의 구조와 상세화 정도 정의 (예를 들어, 템플릿이나 예제 문서를 제공함으로써)
5.2.2 테스트 전략과 테스트 접근법 (Test Strategy and Test Approach)
테스트 전략
프로젝트의 복잡도와 목표, 개발하는 제품 유형, 제품 리스크 평가에 관한 결정을 기반으로 테스트 전략을 조정한다.
테스트 프로세스를 종합해 개괄적으로 설명하는 반면, 테스트 접근법은 특정 프로젝트나 릴리스용으로 테스트 전략을 조정(tailoring)한 것이다.
테스트 전략은 테스트 프로세스의 일반적인 모습을 반영한다. 주로 제품이나 조직 수준에서 작성된다.
테스트 접근법
테스트 기법, 테스트 레벨, 테스트 유형을 선택하는 출발점이고, 시작 조건과 종료 조건(시작 조건과 종료 조건은 준비의 정의와 완료의 정의라고 부르기도 함)을 정의하는 출발점이다.
정황(context)을 기반으로 선택하고 리스크, 안전 사항, 사용 가능한 자원과 역량, 기술, 시스템 특성(예: 맞춤형 개발 vs 상용 소프트웨어), 테스트 목적과 규정 같은 요소를 고려한다.
🦿테스트 접근법
🔍분석적 (Analytiacl)
테스트 전략 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅
특정 요소(예: 요구사항이나 리스크)에 대한 분석을 기반으로 한 테스트 전략. 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법의 예이다.
📱모델 기반 (Model-Based)
테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반
테스트케이스 설계를 소프트웨어 설계 모델을 근거로 작성하고 이를 현행화 하는 과정을 거쳐 실제 테스트 수행을 하도록 하는 접근법 또는 확률론적 테스팅(Stochasic testing, random testing)을 통하여 장애율 통계를 바탕으로 설계하는 테스팅
✅방법론적 (Methodical)
오류 추측(Error guessing) 또는 장애 공격(Fault attack) 과 같은 장애 기반, 경험 기반, 체크리스트 기반, 소프트웨어 품질특성 기반 테스팅
➡️프로세스 및 표준 준수 (Process or standard - compliant)
산업 특화 표준 또는 다양한 애자일 개발 방법론에서 제시한 방법에 의한 테스팅
외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현한다. 예를 들어, 특정 산업 표준에서 제시하는 규정이나 표준, 프로세스의 문서화, 테스트 베이시스의 엄격한 식별과 사용, 조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반으로 한다.
🔨전문가 조언 ((Directive), 또는 자문(consultative))
외부 전문가의 조언과 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅
조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕 외부 테스트 팀이나 외부 조직 소속
동적/발견적 (Dynamic and heuristic)
탐색적 태스팅(Exploratory testing)처럼 미리 계획되고 설계된 테스팅 이라기 보다 사후적 접근법의 하나로, 실행과 평가가 동시에 이루어지는 테스팅
🔁리그레션 기피형 (Regression-averse)
보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 슈트 등의 재사용을 통한 테스팅
기존 기능에 대한 리그레션 테스트 기피를 목표로 한다. 이 테스트 전략에는 기존 테스트웨어(특히 테스트 케이스와 테스트 데이터)의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
🌟반응적 (Reactive)
지금까지 소개한 사전 계획에 따라 실행하는 테스트 전략과는 달리 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법이다.
이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 탐색적 테스팅이 반응적 전략에서 일반적으로 사용하는 기법이다.
앞서 나열한 테스트 전략의 일부를 조합해 적절한 테스트 전략을 만든다. 서로 다른 접근법을 조합해 적용했을 때 각 접근법은 서로를 보완하며 더 효과적으로 테스팅을 수행할 수 있게 한다.
5.2.3 시작 조건과 종료 조건
🔫시작 조건
- 테스트 가능한 요구사항, 사용자 스토리나 모델의 가용 여부
- 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
- 테스트 환경 및 필요한 테스트 도구 가용 여부
- 테스트 데이터와 기타 필요한 자원의 가용 여부
🚩종료 조건
- 계획한 테스트 실행 완료
- 정의한 커버리지 수준 도달(예: 요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)
- 해결하지 못한 결함의 수가 합의된 수보다 적음
- 추정된 결함 밀도 또는 신뢰성 측정치
- 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달
🗂️ etc.
종료 조건을 충족하지 못한 상황에서도 예산 소진, 예정된 시간 경과, 시장 출시 압박 등의 이유로 테스트 활동을 조기에 마감하는 경우도 많다. 추가 테스팅 없이 출시하는 상황이라도 프로젝트 이해관계자와 비즈니스 오너가 리스크를 검토하고 수용하면 테스트를 종료할 수 있다.
5.2.4 테스트 실행 일정 (Test Execution Schedule)
🧳테스트 스위트(test suite)
테스트 케이스와 테스트 프로시저를 작성하고(일부 프로시저는 가능하다면 자동화) 테스트 프로시저와 테스트 케이스를 조합해 테스트 스위트를 생성한 후 테스트 스위트의 순서를 정해 실행 일정을 만들 수 있다. 테스트 실행 일정에서 테스트 스위트를 어떤 순서로 실행할지 정의한다. 테스트 실행 일정을 만들 때는 우선순위, 종속 관계, 확인 테스트, 리그레션 테스트, 가장 효율적인 테스트 실행 순서 등을 고려해야 한
1️⃣우선순위
이상적인 테스트 케이스 실행 순서는 가장 우선순위가 높은 테스트 케이스를 먼저 실행하는 것이다. 그러나 실제로 테스트 케이스 간에 종속 관계가 있거나 테스팅 대상의 기능 자체가 종속 관계라면 우선순위에 따라 실행하지 못할 수도 있다. 우선순위가 높은 테스트 케이스가 우선순위가 낮은 테스트 케이스에 종속되어 있다면 낮은 우선순위를 가진 테스트 케이스를 먼저 실행해야 한다.
🧲종속관계
마찬가지로 테스트 케이스가 서로 종속 관계를 가지고 있다면 각자의 우선순위와 상관없이 필요에 따라 배치해야 한다. 확인 및 리그레션 테스트 역시 수정에 대한 피드백의 중요도에 따라 우선순위를 정해야 하고 이 경우에도 종속 관계를 적용할 수 있다.
상황에 따라 테스트를 다양한 순서로 배치할 수 있으며 각 순서 배치에 따라 효율성 수준이 다를 수 있다. 이런 경우, 테스트 실행 효율성과 우선순위 준수 간의 절충을 고려한 결정이 필요하다.
5.2.5 테스트 노력에 영향을 미치는 요소 (Factors Influencing the Test Effort)
테스트 노력 추정은 테스트 관련 작업에 필요한 노력의 양을 예측하는 활동으로 이는 특정 프로젝트, 릴리스, 반복주기에서 테스팅의 목적을 충족하는 데 필요하다
📜제품의 특성 (Product characteristics)
테스트 모델(테스트 베이시스)을 위한 명세서와 다른 정보의 품질, 제품의 규모, 문제 도메인의 복잡성, 신뢰성과 안정성에 대한 요구사항, 문서화 요구사항
🧑🏽💻개발 프로세스의 특징 (Development process characteristics)
조직의 안정성, 사용되는 도구, 테스트 프로세스, 개발자의 스킬 향상(투입인력의 숙련도), 시간적 압박
👫인력특성 (People characteristics)
관련된 인원의 역량과 경험, 특히 유사한 프로젝트나 제품 관련(예: 도메인 지식), 팀 응집력과 리더쉽
🗂️테스팅의 결과물
결함의 갯수 및 필요한 재작업의 양
5.2.6 테스트 추정 기법 (Test Estimation Techniques)
테스트 노력을 산정하는 추정은 테스트 매니지먼트의 일환으로, 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정하는 것이다.
🔄 메트릭 기반 기법
기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측
ex) 애자일-번다운 차트(Burndown charts) : 남아있는 노력을 파악하고 보고함으로써 팀의 다음 반복주기에서 할 수 있는 작업의 양을 산정하는 데 사용할 팀의 업무진행 속도를 계산
ex) 순차적 개발- 결함 제거 모델(Defect Removal Models) : 결함의 양과 결함을 제거하는 데 드는 시간을 파악하고 보고해서 차후 비슷한 성격의 프로젝트를 추정하는 기준으로 사용
🧑💻전문가 기반 기법
테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측
ex) 애자일-플래닝 포커(Planning poker) : 팀원이 자신의 경험을 기반으로 특정 기능을 인도하는데 드는 노력을 추정
ex) 순차적 개발 - 와이드밴드 델파이(Wideband Delphi) 추정 기법 : 전문가 집단의 경험을 기반으로 추정치를 제공한다
어떤 접근 법을 선택하든 리스크 분석과 테스트 전략을 근거로 산정해야하며 수행할 예정인 테스트 업무를 세분화하여 각 업무에 적절한 자원을 배분하고, 이를 수렴하는 식의 워크 브레이크다운 스트럭쳐(WBS, work Breakdown Structure) 방식 선택 할 수 있다.