1-4. 테스트 프로세스

테스트 프로세스

- 테스트를 계획, 테스트 케이스를 설계, 테스트 수행 준비, 테스트 진행 상태를 확인, 평가하는 활동을 선행해야 함

1. 기본적인 테스트 프로세스 주요 활동

- 테스트 프로세스는 테스팅과 관련된 다양한 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 모든 구성 요소를 엮어주는 역할을 함

테스트 계획과 제어

• 테스트 목적/목표 설정 및 대상 연구
• 테스트 전략 기법
• 리스크 분석
• 전략 수립
• 테스트 완료 조건
• 테스트 추정
• 조직 구성
• 테스트 계획 활동
• 테스트 관리 및 제어
• 리포팅(모니터링)
• 리포팅 계획/설계
• 진행 리포팅

테스트 분석과 설계

• 테스트 베이시스 검토
• 테스트 상황/요구사항/데이터 실행
• 테스트 기법 할당
• 테스트 용이성(testability) 평가
• 테스트 환경 구축

테스트 구현과 실행

• 테스트 케이스 명세화, 우선순위 선정, 데이터 생성, 프로시저 작성
• 선행 테스팅
• (재) 테스팅 실행(결과 기록)
• 기대 결과와 비교

테스트 완료 조건의 평가와 리포팅

• 완료 조건의 달성 여부 확인
• 최종 테스트 보고서 작성

테스트 마감활동

• 산출물 확인, 테스트웨어 보관
• 테스트 프로세스 평가(심사)

- 테스팅은 다양한 구성 요소를 포함하는 테스트 프로세스를 중심으로 조정하고 관리 되어야 함

- 테스팅은 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언을 제공

- 조언은 테스트 전략을 수립하기 위해 분석한 리스크를 반영하여 제공하는 것이 바람직

- 테스트 프로세스 순서: 계획/제어 → 분석/설계 → 구현/실행 → 완료조건 평가/리포팅 → 마감

(논리적으로 순차적이지만 프로세스 내의 활동은 중복되거나 동시에 진행할 수 있음)

2. 테스트 프로세스의 주요활동과 산출물

- 테스트 실행 전(계획, 설계)에 준비: 테스트 베이시스, 테스트 기법, 테스트 기반 설비 및 환경, 테스트 조직

- 테스트 실행시 준비: 테스트 대상

1) 테스트 대상

- 가능한 이른 시기에 준비되어야 함

- 늦어도 실제 테스트를 실행하는 단계에서는 반드시 필요한 요소

2) 테스트 베이시스(Test basis)

- 개발 중간산출물 등 테스트 설계 및 구현의 기반이 됨

- 테스트 계획 단계에서부터 필요, 설계시 반드시 요구

3) 테스트 기법

- 테스트 분석 및 설게 단게에서 필요

4) 테스트 기반 설비(Test infrastructure) 및 환경

- 테스트 실행 단계 전에 구축되어야 함

5) 테스트 조직

- 게획 단계에서부터 필요

- 테스트 실행 단계에서는 상대적으로 다수의 인력을 필요로 함

테스트 계획과 제어(통제) (Planning and control)

1. 테스트 계획 수립 관련 주요 작업

- 테스트 목표와 임무를 확인하고 필요한 활동을 정의하는 것

1) 테스트 범위, 리스크 결정, 테스트 목적에 대한 식별

a. 테스트 범위

- 인터페이스 정도, 관련 품질 특성, 호환성 테스팅 범위, 커버하고자 하는 테스트 레벨 등

b. 리스크 기반 테스트 전략

- 각각의 테스트 레벨에 대해 테스트 대상 제품이 충족해야할 품질 수준 및 특성과 기술적 어려움 고려 

- 비지니스 리스크 고려

c. 테스팅 목적

-     품질 요구 수준

- 테스트 레벨 별 목적(결함 발견, 요구사항 충족 등)

- 커버하고자 하는 품질 특성(기능성, 효율성, 신뢰성, 유지 보수성 등)

2) 테스팅 정책의 실현과 테스트 전략의 구현

- 조직 구조 형태 및 인력 구성/자격, 중점 테스트 타겟과 테스트 레벨, 테스트 프로세스 개선 방향, 고객 및 이해관계자와의 관계 등

3) 테스트 접근 방법에 대한 결정

- 테스트 기법 및 대상 테스트 베이시스 포함여부, 테스트 아이템, 커버리지, 테스팅에 참여할 팀의 식별과 팀간 의사소통(Interfacing), 테스트웨어 등

4) 테스트에 필요한 리소스의 결정

- 조직, 인원, 테스트 환경 등

5) 테스트 분석과 설계 작업의 일정 관리

6) 테스트 구현, 실행 및 평가의 일정관리

7) 테스트 완료 조건의 결정

2. 테스트 제어의 주요한 작업

- 계획 대비 실제 진행 상황을 비교하는 지속적인 활동

- 진행 상태 보고(계획과의 차이, 계획과의 일치 정도 등)

- 테스트 프로젝트의 목표 및 임무를 달성하기 위해 계획과의 차이에 대해 조치를 취하는 것을 의미

- 테스팅 제어를 위해 프로젝트 내내 테스팅 활동 모니터링 필요

- 테스트 계획은 테스팅의 제어와 모니터릴 활동으로 부터 받는 피드백을 반영

1) 테스트 결과에 대한 측정과 분석

2) 테스트 진척 상황, 테스트 커버리지와 완료 조건의 모니터링과 문서화

3) 테스트 계획과의 차이를 교정하는 활동

4) 테스팅의 진행과 변경에 대한 의사 결정 활동

테스트 분석과 설계(Analysis and design)

- 테스트 분석과 설계: 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동

1. 테스트 분석과 설계 주요 작업

1) 테스트 베이시스 리뷰

- 요구사항 명세서(Requirement Specification)

- 아키텍처(소프트웨어 구조)

- 개발 설계 문서

- 인터페이스

2) 테스트 상황을 식별하고 우선 순위 결정

- 테스트 대상 아이템 또는 제품, 명세, 동작 구조의 분석을 통해 이루어짐

3) 테스트 케이스 설계, 우선순위 선정

- 공식적인 테스트 기법을 활용한 테스트 케이스 도출

4) 비공식적인 테스트 기법으로 테스트 케이스 추가 도출 및 보완

5) 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별

6) 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설 및 도구의 식별

테스트 구현과 실행(Implementation and execution)

- 테스트를 실행하기 위해 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저(Test procedure) 또는 테스트 스크립트(Test script)를 명세화 하는 활동

- 테스트 실행에 필요한 테스트 환경이 구축되어 있어야 함

1. 테스트 구현과 실행 주요활동

1) 테스트 케이스의 개발, 구현과 우선순위 선정

- 테스트 프로시저 작성, 우선순위 선정, 테스트 데이터의 생성

2) 자동화 테스트 스크립트 작성

3) 테스트 하네스(Test harnesses) 준비

- 테스트 하네스: 테스트를 수행하기 위해 필요한 스텁, 드라이버로 구성된 테스트 환경

4) 효율적인 테스트 실행을 위해 테스트 수트(Test Suites, 테스트 케이스 묶음) 생성

5) 테스트환경의 올바른 구축 여부 확인

6) 계획된 순서에 의거하여 수동 또는 테스트 실행 도구로 준비된 테스트 프로시저를 수행

7) 테스트 수행 결과를 기록해주고, 테스트 중인 소프트웨어, 테스트 도구, 테스트웨어의 식별과 버전을 기록

8) 예상 결과와 실제 결과를 비교

9) 예상 결과와 실제 결과간의 차이에서 오는 불일치를 인시던트 또는 결합으로 보고

- 인시던트: 결함을 포함하는 개념으로 이슈와 거의 유사한 의미

10) 불일치의 원인을 알아내기 위해서 실제 결과나 현상을 분석

a. 테스트 케이스 결함

- 테스트 실행의 실패가 어플리케이션 결합이 아닌 테스트 케이스 자체의 결합 때문에 생긴 경우(스크립트, 시나리오, 잘못된 테스트 데이터 또는 입력값)

b. 테스트 정황 결함

- (스크립트, 시나리오 등의) 테스트 수행 상의 오류

c. 어플리케이션 결함

- 테스트 대상 소프트웨어/하드웨어 결합, 진행 절차 상의 결함, 설치상의 결함, 코드상의 결함

d. 어플리케이션 정황 결함

- 사용상의 오류, 테스트 환경(OS, DBMS 등)과 관련된 소프트웨어 결함

11) 각각의 불일치를 조치한 결과를 확인하기 위해 테스트 활동을 반복

- 수정을 확인하기 위해 이전에 실패한 테스트를 실행

- 수정으로 인해 새로운 버그가 추가 발생하지 않았는지 또는 변경되지 않은 부분에 수정 사항과 연관된 버그가 발생하지 않는지 확인하는 테스트 실행

2. 테스트 실행 중 발견할 수 있는 결함

1) 유형별로 분류 

- 결함을 분석하여 개발 프로세스 및 품질 보증 절차를 개선을 고려할 수 있음

a. 기획 시 유입된 결함

- 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 기타 결함

b. 설계시 유입된 결함

- 설계의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 인터페이스 결함, 기타 결함

c. 코딩 시 유입된 결함

- 연관 변수 파악 부족, 예외 사항 고려 부족 등

- 코드의 표준 미 준수, 불완선, 불일치, 인터페이스 결함, 데이터 결함, 기타 결함

d. 테스트 부족으로 유입된 결함

e. 마무리 부족

f. 팀간 의사소통 부족

g. 코딩 실수

2) 결함 심각도(Severity level)별로 분류

- 심각도를 표현하는 단어를 정확하게 사용하는 것이 중요, 조직 내에서 각 결함 심각도의 구분을 명확한 기준을 가지고 정의

- 결함 심각도 구분별로 해당하는 내용이 모호할 경우 결함 리포팅의 신뢰성이 떨어질 수 있음

- 결함 심각도를 보는 조직이나 사람마다 다르게 평가하여 논쟁에 불필요한 시간을 반복적으로 낭비할 수 있음

a. 결함 심각도 구분의 업계 모범 사례

- 치명적(Show stopper)

- 매우 심각(Fetal)

- 심각(No Workaround)

- 보통(Workaraound)

- 경미(Cosmetic)

- 치명적 결함(Critical Defects): 하드웨어 또는 소프트웨어 장애, 시스템 중지, 시스템 잠김, 데이터 손실 또는 변조

- 주요 결함(Major Defects): 기능 상실, 잘못된 기능, 주요 기능 오작동

- 일반 결함(Average Defects): 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스

- 사소한 결함(Minor Defects): 타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스

- 개선사항(Enhancement): 에러는 아니지만 개선이 필요한 사항

b. 부적절한 결함 심각도

- Major, Minor, Trifle: 심각도가 상대적으로 높은 결함임에도 불구하고 받아들이는 사람이 사소한 결함으로 인지할 수 있음

- A, B, C: 용어의 모호함으로 인해 전달받는 이에게 그 의미가 잘못 전달되는 사고를 사전에 방지

3) 결함 우선순위(Defect priority)

- 결함의 심각도를 구분할 경우 개발자가 처리해야 할 결함의 우선순위를 판단하게 하는 좋은 근거가 됨

- 결함 심각도와 처리해야 할 결함 우선순위를 별도로 구분해야 함

- 모든 경우 결함 심각도가 가장 높다고 해서 가장 먼저 그 결함을 수정해야 되는 것은 아님

(정해진 일자에 제품을 출시해야 하는데 기간 내에 심각도가 가장 높은 결함 해결이 불가능할 경우 제품 완성도를 조금이라도 더 높이기 위해 다른 결함들을 우선적으로 처리해야 하는 것이 유리)

a. 결함 우선순위를 표현하는 사례

- 즉시 해결(Resolve immediately)

- 주의 요망(Give high attention)

- 대기(Normal queue)

- 낮은 순위(Low priority)

테스트 완료 조건의 평가와 리포팅(Evaluating exit criteria and reporting)

- 완료 조건 평가: 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가하는 활동

- 테스트 목표를 달성하였다며 테스트가 완료, 추가 테스트를 수행할 것인지 테스트 목표를 변경하여 테스트를 완료할 것인지를 결정해야 함

- 시간이나 예산 소요로 인해 테스팅이 종료되기도 하지만 미리 정해둔 기준을 모두 달성한 것이 가장 의미 있는 완료 조건

- 릴리즈를 결정할 수 있는 제품에 대한 충분한 정보가 있을 때 태스트를 완료함

- 각 활동은 각 테스트 레벨(컴포넌트, 통합, 시스템, 인수 테스팅)마다 수행되는 것이 원칙

1. 완료 조건의 평가와 관련된 주요작업

1) 테스트 실행 결과가 테스트 계획에 명시된 완료 조건을 만족하는지 확인

2) 추가적인 테스트가 필요한지, 명세된 테스트 완료 조건을 변경 해야 하는지에 대한 평가 수행

3) 이해관계자(Stakeholders)에게 배포할 테스트 요약 보고서 작성

2. 리포팅 

- 진행보고, 릴리즈 조언 및 최종보고 형태로 이루어 짐

- 진행보고: 테스트 제어 활동 단계에서 테스트의 진행 상황을 모니터링 하는 활동으로 분류

- 릴리즈 조언과 최종 보고: 테스트 완료 단계에서의 활동

- 테스팅을 수행하면서 수집한 결함 및 테스트 진행 관련 데이터를 가공하여 메트릭으로 수치화하고 관련 정보를 표현하는 작업

1) 발견된 결함과 미해결 결함의 추이 및 우선순위

2) 테스트 진척도

3) 리스크 및 메트릭으로 실증된 조언

4) 테스트 환경의 가용성

5) 테스트 커버리지, 결함 발견 효과성/효율성, 품질 평가 결과, 결함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수, 요구사항 별 테스트 일 수, 해결되지 않은 결함과 그 영향, 오랫동안 수정되지 않은 결함 분석 등

1. 효과적인(Effective) 테스트

- 계획했거나 원했던 테스트 결과 산출

- 효과적인 테스터는 테스팅 노력으로부터 어떤 결과를 도출할 것인지 결정

2. 효율적인(Efficient) 테스트

- 계획된 테스트를 생산적(효율적)으로 수행

- 효율적 테스터는 가용한 리소스(시간, 자금, 인력)를 적절하고 현명하게 배치

3. 테스트 효과성을 높이기 위한 방법

- 높은 커버리지의 테스트 기법을 적용

4. 테스트 효율성을 높이기 위한 방법

- 자동화 도구를 활용

- TPI Next나 TMMi 모델을 활용해 테스트 프로세스를 개선

- 테스트 환경을 개선

테스트 마감 활동

- 완료된 테스트 활동에서 데이터를 수집, 테스트에서 발견된 사실, 수치적 데이터와 함께 테스팅 경험, 테스트웨어를 종합하고 축적하는 활동

- 테스팅이 체계적으로 수행되었는지를 평가

- 향후 테스팅을 개선하기 위해 모범 사례를 모델로 테스트 프로세스를 심사(평가)

1. 테스트 마감활동의 발생

1) 소프트웨어 시스템이 출시되어 테스트 프로젝트가 완료되었을 때

2) 테스트 프로젝트가 취소되었을 때

3) 계획된 모든 마일스톤이 달성되었을 때

4) 유지보수 활동 중 추가 개발되거나 업데이트된 부분이 출시 완료되었을 때

2. 테스트 마감 활동의 주요 포함사항

1) 테스트 결과 마감

- 예정된 산출물 확인

- 인시던트 리포트(결함 리포트 포함) 종료

- 해결되지 않은 추가 및 변경 요구 사항에 대한 처리

- 시스템을 인수화 하는 것 문서화

2) 테스트 웨어, 테스트 환경, 테스트 기반설비를 차후에 사용할 것을 대비하여 마감하고 보관

3) 테스트웨어를 유지보수 조직에 이관

4) 테스트 프로세스 심사(평가) 및 개선 사항 제안

5) 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석

3. 테스트 프로세스를 심사하는 모델

- 테스트 프로세스 심사 모델: MMAST, TAP, TCMM, TIM, TOM, TPI, TSM

1) 대표적인 테스트 프로세스 심사 모델

- TMMi(Test Maturity Model integration)

- TIM(Test Improvement Model)

- TPI Next(Test Process Improvement Model Next)