[ISTQB] 1장 테스팅의 기초 (3)

 

 

 

1.4 테스트 프로세스

Test Process​

​

1.4.1 정황에 따른 테스트 프로세스

Test Process in Context

​

테스트 프로세스에 영향을 줄 수 있는 정황 요소

· 소프트웨어 개발 수명주기 모델과 프로젝트 방법론

· 테스트 레벨과 테스트 유형

· 제품 및 프로젝트 리스크

· 운영상의 제약 상황 : 예산과 자원(resource), 일정, 복잡도, 계약 및 규제 요구 사항

· 준수해야 하는 표준

​

조직 테스트 프로세스의 일반적인 요소

· 테스트 활동과 작업

· 테스트 작업 산출물

· 테스트 베이시스와 테스트 작업 산출물 간의 추적성

​

테스트 베이시스에 대한 측정 가능한 커버리지 조건이 설정되어 있으면 매우 유용하다.

커버리지 조건은 소프트웨어 테스트의 목적 달성 여부를 보여주는 활동의 주요 성능 지표(KPI, Key Performance Indicator)로 사용하기에 용이하다.

​

예시 > 모바일 애플리케이션

☞ 테스트 베이시스 : 요구 사항 목록과 지원 대상 모바일 기기 목록

☞ 커버리지 조건 : 테스트 베이시스 요소를 적어도 하나의 케이스로 다루어야 한다는 것​

​

---

 

​

1.4.2 테스트 활동과 작업

Test Activities and Tasks

​

테스트 프로세스를 구성하는 주요 활동

☞ 계획, 모니터링과 제어, 분석, 설계, 구현, 실행, 완료

​

테스트 계획 Test Planning

☞ 테스트의 목적과 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동

☞ 적합한 테스트 기법과 작업 명시, 테스트 일정 수립

☞ 테스트 계획은 모니터링과 제어 활동에서 나온 피드백을 기반으로 수정할 수 있다.

​

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

테스트 모니터링 : 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동

테스트 제어(test control) : 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행하는 것

☞ 종료 조건(exit criteria) 평가도 테스트 모니터링과 제어에 필요한 활동이다.

​

​

테스트 분석 Test Analysis

☞ 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석하는 것

☞ 측정 가능한 커버리지 조건의 측면에서 "무엇을 테스트할지"를 결정하는 것

​

☞ 테스트 분석의 주요 활동

a. 테스트 레벨에 적합한 테스트 베이시스 평가

• · 요구 사항 명세 : 기능/시스템 요구 사항, 유스케이스, 기능/비기능 컴포넌트나 시스템 동작이 명시된 작업 산출물 등
• · 설계/구현 정보 : 아키텍처/모델링 다이어그램, 설계/인터페이스 명세, 컴포넌트나 시스템 구조가 명시된 작업 산출물
• · 컴포넌트나 시스템 : 코드, 데이터베이스 메타데이터(database metadata), 쿼리(queries), 인터페이스 등
• · 컴포넌트나 시스템의 기능, 비기능, 구조 측면을 고려한 리스크 분석 보고서

b. 다양한 형태의 결함 식별

• · 모호함 (Ambiguities)
• · 누락 (Omissions)
• · 불일치 (Inconsistencies)
• · 부정확 (Inaccuracies)
• · 모순 (Contradictions)
• · 불필요한 구문 (Superfluous Statements)
• c. 테스트할 기능과 기능 세트 식별

d. 기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정

e. 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착

​

☞ 테스트 분석에 블랙박스, 화이트박스, 경험 기반 기법을 적용하면 더 정확하고 정밀한 테스트 컨디션 도출에 도움이 된다.

☞ 테스트 분석 활동은 요구 사항이 일관성 있게 제대로 설명되고 완성되었는지 검증할 뿐 아니라, 요구 사항이 고객, 사용자, 기타 이해관계자의 요구를 제대로 반영하고 있는지 확인하게 해준다.

 

​​

테스트 설계 Test Design

☞ 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어(testware)를 생성

☞ 테스트 설계는 "어떻게 테스트할 것인가?"를 다룬다.

 

💡 테스트웨어: 테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물 = 묶음이라고 생각

​

☞ 테스트 설계의 주요 활동

a. 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정

b. 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별

c. 테스트 환경 설계와 필요한 인프라 및 도구 식별

d. 테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정

​

☞ 테스트 분석과 마찬가지로, 테스트 설계에서도 테스트 베이시스에서 유사한 유형의 결함을 식별할 수 있다.

​

​

테스트 구현 Test Implementation

☞ 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트 프로시저를 만든다.

☞ 테스트 구현은 "테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?"를 다룬다.

 

💡 테스트 프로시저: 테스트케이스의 실행 순서 (자동화 테스팅에서는 '테스트 스크립트'로 불린다)

 

​

☞ 테스트 구현의 주요 활동

a. 테스트 프로시저 개발과 우선순위 선정 (가능하면 자동 테스트 스크립트 생성)

b. 테스트 프로시저( or 자동 테스트 스크립트)로부터 테스트 스위트(test suite) 생성

c. 효과적인 테스트 실행을 위해 테스트 스위트를 테스트 실행 일정 내에 배치

d. 테스트 환경 구축 (테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목..)

e. 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인

f. 테스트 베이시스, 컨디션, 케이스, 프로지서, 테스트 스위트 서로 간의 양방향 추적성 검증과 업데이트

​

☞ 테스트 설계와 테스트 구현 작업은 합쳐지는 경우가 많다.

 

💡 테스트 스위트(수트/슈트) : 테스트케이스의 집합
💡 테스트 시나리오 : 테스트 스위트(수트/슈트) + 스토리

💡 테스트 하네스:

​

테스트 하네스 도구란 테스트가 실행될 환경을 시뮬레이션 해주는 도구입니다.

 

테스트 하네스의 구성 요소:

- 테스트를 수행하기 위해 필요한 스텁과 드라이버로 구성된 테스트 환경으로 단위테스트 및 통합테스트에 주로 이용됨

 

테스트 드라이버	테스트 스텁	테스트 슈트	테스트 케이스	테스트 스크립트	목 오브젝트
(상향식) 테스트 대상의 하위 모듈을 호출하는 도구	(하향식) 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈	테스트 케이스의 집합	테스트 항목의 명세서	자동화된 테스트 실행 절차에 대한 명세서	사전에 사용자 행위를 조건부로 입력해 두면, 그 상황에 맞는 행위를 수행하는 객체

https://beluga9.tistory.com/154 

 

​

테스트 실행 Test Execution

☞ 테스트 스위트를 테스트 실행 일정에 따라 실행

​

☞ 테스트 실행의 주요 활동

a. 테스트 항목, 대상, 도구, 테스트웨어 등의 고유번호와 버전 기록

b. 테스트를 수동/자동으로 실행

c. 기대 결과와 실제 결과 비교

d. 이상 현상(anomalies)을 분석해 원인 파악

e. 관찰한 장애를 기반으로 결함 보고

f. 테스트 실행 결과 기록

g. 테스트 활동 반복 (수정된 테스트 실행, 확인 테스팅이나 리그레션 테스팅 등)

h. 테스트 베이시스, 컨디션, 케이스, 프로시저, 결과 간의 양방향 추적성 검증과 업데이트

​

​

테스트 완료 Test Completion

☞ 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 정보를 축적하는 활동

☞ 소프트웨어 시스템을 릴리스했을 때, 테스트 프로젝트를 완료했을 때, 애자일 반복 주기가 끝났을 때.. 등 프로젝트 마일스톤 시점에서 일어난다.

​

☞ 테스트 완료의 주요 활동

a. 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 결함에 대해 수정 요청서 또는 백로그 항목을 생성했는지 확인

b. 테스트 요약 보고서 생성

c. 재사용을 위해 테스트 환경, 테스트 인프라, 테스트웨어의 마무리 및 보관

d. 테스트웨어를 유지 보수팀, 다른 프로젝트팀 등에 인계

e. 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복 주기, 릴리스, 또는 프로젝트를 위해 수정할 사항 판단

​​

​

 

---

​

1.4.3 테스트 작업 산출물

Test Work Products

​

테스트 계획 작업 산출물 Test Planning Work Products

☞ 하나 이상의 테스트 계획이 포함된다.

☞ 테스트 계획은 테스트 베이시스에 대한 정보를 포함한다.

​

테스트 모니터링과 제어 작업 산출물 Test Monitoring and Control Work Products

☞ 다양한 형태의 보고서를 포함

ㄴ 지속적, 정기적으로 생성되는 테스트 진행 현황 보고서

ㄴ 테스트 완료 마일스톤에서 생성되는 테스트 요약 보고서

 

☞ 테스트 진행 상황 관련 필요한 정보를 제공해야 한다.

​

테스트 분석 작업 산출물 Test Analysis Work Products

☞ 분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션

​

테스트 설계 작업 산출물 Test Design Work Products

☞ 테스트 분석에서 정의한 테스트 컨디션을 실행할 수 있는 테스트 케이스와 테스트 케이스 세트

☞ 테스트 환경 설계, 인프라와 도구의 식별

☞ 입력 데이터와 기대 결과로 사용할 값이 고정되지 않은 상위 수준 테스트 케이스를 먼저 설계하는 것이 좋은 경우가 많다.

​

테스트 구현 작업 산출물 Test Implementation Work Products

☞ 테스트 프로시저와 이 프로시저의 배열

☞ 테스트 스위트

☞ 테스트 실행 일정

☞ 테스트 데이터와 테스트 환경을 구현 및 검증

ㄴ 테스트 데이터는 테스트 케이스의 입력 값과 기댓값을 확정값을 할당하는 데 사용

ㄴ 이렇게 확정된 값은 상위 수준의 테스트 케이스를 실행 가능한 하위 수준의 테스트 케이스로 변화시킴

​

테스트 실행 작업 산출물 Test Execution Work Products

☞ 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서 (합격, 불합격, 실행 못함 등)

☞ 결함 보고서

☞ 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한 문서

​

테스트 완료 작업 산출물 Test Completion Work Products

☞ 테스트 요약 보고서, 수정 요청서 혹은 제품 백로그 항목, 완성된 테스트웨어 등

​​

​

 

---

​

1.4.4 테스트 베이시스와 테스트 작업 산출물 간의 추적성

Traceability between the Test Basis and Test Work Products

​

☞ 효과적인 테스트 모니터링과 제어를 구현하기 위해 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소 및 해당 요소와 연관된 다양한 작업 산출물 간의 추적성을 유지하는 것이 좋다.

​

좋은 추적성의 장점

1. 테스트 커버리지에 대한 평가가 가능

2. 수정으로 인한 영향 평가가 가능

3. 테스팅에 대한 감사(audit)가 가능

4. IT 통제(IT governance) 조건을 충족

5. 테스트 베이시스 개별 요소의 상태 정보를 포함하므로 테스트 진행 상황 보고서와 요약 보고서를 쉽게 이해할 수 있음

6. 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달

7. 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.

​

​

​

 

---

Reference

https://m.blog.naver.com/PostList.naver?blogId=jing_new_&tab=1