//구글콘솔 광고 추가가
들어가기 전 알아둬야 하는 1.4 용어 설명
: 사전적으로는 용어설명 글에서 설명했고, 이제는 이해하기 쉽게 되도록 공부한 설명.
리그레션 테스팅 : 반복 테스팅.
테스트웨어 : 테스트 산출물.
테스트 차터 :  테스트 세션의 목적 또는 목표를 설명하는 문서.
테스트 환경 : 테스트 수행에 필요한 하드웨어, 계측, 시뮬레이터, 소프트웨어 도구 그리고 기타 지원 요소를 포함하고 있는 환경.
테스트 하네스 : 테스트 스위트를 실행하는 데 필요한 스텁 및 드라이버 모음.
테스트 스위트 : 특정 테스트 실행에서 실행될 일련의 테스트 스크립트 또는 테스트 절차.

 

1.4 테스트 활동, 테스트웨어, 테스트 역할
- 테스팅은 정황에 의존적이지만, 상위 수준에서 봤을 때 만약 없다면 테스팅이 테스트 목적을 달성하기 어렵게 되는 보편적인 테스트 활동이 있다.
- 이런 테스트 활동들이 테스트 프로세스를 구성하게 된다.
- 테스트 프로세스는 여러 요인을 기반으로 주어진 상황에 맞게 조정될 수 있다.
- 테스트 프로세스에 포함할 테스트 활동과 그러한 활동의 구현 방법과 수행시기는 보통 해당하는 상황의 테스트 계획을 할 때 결정한다.

 

1.4.1 테스트 활동과 업무
테스트 프로세스를 구성하는 주요 활동 7가지 :
순차적으로 수행되는 것 처럼 보일수 있으나 실제로는 반복적 또는 병렬로 구현되는 경우가 많다.
테스팅 활동은 일반적으로 시스템과 프로젝트에 맞게 조정한다.
테스트 계획 - 테스트 목적을 정의.
- 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법을 선택.
- 시작 조건 & 완료조건
테스트 모니터링과 제어 - 테스트 모니터링 : 지속적으로 모든 테스트 활동을 점검하고, 실제 진행 상황을 계획과 비교하는 활동.( == 완료 조건 충족했나)
- 테스트 제어 : 테스트 목적을 달성하는 데 필요한 조치를 하는 활동.
( == 우선순위 재지정, 시작 조건 & 완료 조건 충족하는지 재평가, 테스트 일정 조정)
테스트 분석 - 테스트 베이시스를 분석해 테스트 가능한 기능을 식별하고, 관련된 테스트 컨디션을 정의하고, 우선 순위를 정하는 활동이 포함, 이와 관련된 리스크와 리스크 수준도 같이 고려된다. 
- 테스트 베이시스와 테스트 대상을 평가해 결함을 식별하고 테스트 용이성을 평가.
- 테스트 분석을 지원하기 위해 테스트 기법(경계값 분석, 동등분할)을 사용하는 경우가 많다.
- 측정할 수 있는 커버리지 조건으로 "무엇을 테스트할 것인가?"라는 질문에 대한 답을 제공.
테스트 설계 - 테스트 컨디션을 테스트 케이스와 기타 테스트웨어(예: 테스트 차터)로 구체화하는 작업을 포함. 이 활동은 테스트 케이스 입력값을 구체화하는 데 도움이 되는 커버리지 항목의 식별을 포함하는 경우가 많다.
- 테스트 기법을 활용할 수 있다.
- "어떻게 테스트 할 것인가?"라는 질문에 답을 제공.
테스트 구현 - 테스트 실행에 필요한 테스트웨어(예: 테스트 데이터)를 만들거나 획득하는 작업을 포함.
- 효율적인 테스트 실행을 위해  테스트 케이스는 테스트 절차로 묶을 수 있고, 테스트 스위트로 조합하는 경우도 많다.
- 수동 및 자동 테스트 스크립트를 만들게 된다.
- 우선 순위를 반영한 테스트 실행 일정으로 테스트 절차를 정리한다. 테스트 환경(테스트 하네스)을 구축하고 올바르게 설정되었는지 확인한다.
테스트 실행 - 지속적 테스팅, 페어 테스팅 세션 등 다양한 형태로 이루어 질 수 있다.
- 실제 테스트 결과를 기대 결과와 비교한다.
- 테스트 결과는 기록된다. 이상 현상을 분석해 가능한 원인을 파악한다. 이런 분석을 통해 관찰한 장애를 기반으로 이상 현상을 보고할 수 있다.
테스트 완료 - 일반적으로 프로젝트 마일스톤(예 : 릴리스, 반복 주기 완료, 테스트 레벨 완료)에서 수행
- 해결되지 않은 결함에 대해서는 변경 요청서 또는 제품 백로그 항목을 만든다.
- 테스트웨어를 식별해서 보관하거나 적절한 팀에 인계한다.
- 테스트 환경은 합의된 상태로 종료하게 된다.
- 테스트 활동을 분석해 향후 반복 주기, 릴리스, 프로젝트를 위한 교훈과 개선 사항을 파악한다.
- 테스트 완료 보고서를 작성해 이해관계자에게 전달한다.

 

1.4.2 정황에 따른 테스트 프로세스
- 테스팅은 단독으로 수행되지 않는다.
- 테스팅 비용은 이해관계자가 부담하게 되며, 테스팅의 최종 목표는 이해관계자의 비즈니스 목표 달성을 지원하는 것이다.

>> 따라서 수행 방식은 다음과 같은 여러 정황요소에 따라 달라진다.
이해관계자(필요, 기대, 요구사항, 협력 의지 등)
팀원(기술, 지식, 경험 수준, 가용성, 훈련 필요성 등)
비즈니스 도메인(테스트 대상의 중요도, 식별된 리스크, 시장 요구사항, 구체적인 법적 규제 등)
기술적 요인(소프트웨어 유형, 제품 아키텍처, 사용된 기술 등)
프로젝트 제약 조건(범위, 시간, 예산, 자원 등)
조직적 요인(조직 구조, 기존 정책, 적용한 실천법 등)
소프트웨어 개발수명 주기(SDLC)(공학적 실천법, 개발 방법론 등)
도구(가용성, 사용성, 규정 준수 등)
>> 이런 요소는 테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트 문서 상세화 수준, 보고 등 많은 테스트 관련 문제에 영향을 미친다.

 

1.4.3 테스트웨어( == 테스트 산출물)
- 테스트웨어는 테스트 활동의 결과물로 만들어진다. 조직마다 테스트웨어를 생성/ 구체화/ 명명/ 구성/ 관리하는 방식에 상당한 차이가 있다.
- 적절한 형상관리는 작업 산출물의 일관성과 무결성을 보장한다.
테스트 작업 산출물
테스트 계획 작업 산출물 테스트 계획, 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건.
리스크 관리 대장은 리스크 발생 가능성, 리스크 영향, 리스크 완화 정보가 들어있는 리스크 목록.
테스트 계획서에 종종 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건이 들어간다.
테스트 모니터링과 제어 작업 산출물 테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보.
테스트 분석 작업 산출물 (우선순위가 지정된)테스트 컨디션(예: 인수 기준), 
(바로 수정하지 않았다면)테스트 베이시스의 결함에 관한 결함 보고서.
테스트 설계 작업 산출물 (우선순위가 지정된)테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항.
테스트 구현 작업 산출물 테스트 절차, 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정, 테스트 환경 요소(예: 스텁, 드라이버, 시뮬레이터, 서비스 가상화)
테스트 실행 작업 산출물 테스트 로그, 결함 보고서.
테스트 완료 작업 산출물 테스트 완료 보고서, 향후 프로젝트 또는 반복 주기 때 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서(예: 제품 백로그 항목)

 

1.4.4 테스트 베이시스와 테스트웨어 간의 추적성
- 효과적인 테스트 모니터링과 제어를 구현하려면 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소, 개별 요소와 관련된 테스트웨어(예: 테스트 컨디션, 리스크, 테스트 케이스), 테스트 결과, 식별한 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.
- 정확한 추적성은 커버리지 평가를 지원하며, 측정 가능한 커버리지 기준이 테스트 베이시스에 정의되어 있을 때 매우 중요. 커버리지 기준은 테스트 목적 달성 상태를 나타내는 활동을 촉진하는 핵심 성과 지표로 기능할 수 있다.

 

< 좋은 추적성 5가지 >

  • 커버리지 평가 외에도 변경사항의 영향을 파악할 수 있게 한다.
  • 테스트 감사를 용이하게 한다.
  • IT 운영 및 관리 기준을 충족하는데 도움이 된다.
  • 테스트 진행 상황 및 완료 보고서에 테스트 베이시스 개별 요소의 상태를 명시하여 보고서를 더 쉽게 이해할 수 있게 한다.
  • 이해관계자에게 테스팅의 기술적 측면을 이해하기 쉬운 방식으로 전달하는 데 도움이 된다. 

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

 

1.4.5 테스팅에서의 역할
실라버스에서는 테스트 관리 역할과 테스팅 역할을 다룬다.
이 두 역할에 할당되는 활동과 업무는 프로젝트 및 제품의 정황, 역할 담당자의 기술 수준, 조직 상황 등의 요소에 따라 달라진다.
테스트 관리 역할 테스트 프로세스, 테스트팀 그리고 테스트 활동 리더십에 대한 전반적인 책임을 지는 것.
- 주요 관심 영역 : 테스트 계획, 테스트 모니터링과 제어, 테스트 완료 활동.
- 수행 방식은 정황에 따라 달라짐
ex> 애자일 소프트웨어 개발에서 테스트 관리 업무의 일부를 애자일팀이 처리할 수 있다. 여러 팀 또는 조직 전체의 협업이 필요한 업무는 개발팀 외부의 테스트 관리자가 수행할 수도 있다.
테스팅 역할 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다.
- 주로 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동에 초점을 둔다.
- 시기에 따라 역할을 수행하는 사람이 달라질수 있음.
ex> 테스트 관리 역할은 팀 리더, 테스트 관리자, 개발 관리자등이 수행할 수 있다. 또한 한 사람이 테스팅과 테스트 관리 역할을 동시에 수행하는 경우도 있다.

 

 

++ 테스트 활동이랑 테스트웨어는 함께 보는게 좋을 것 같으니 표를 합쳐서 같이 봐보자.

테스트 활동과 테스트웨어 합쳐보기
테스트 활동 테스트웨어
테스트 계획 - 테스트 목적을 정의.
- 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법을 선택.
- 시작 조건 & 완료조건
테스트 계획, 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건.
테스트 모니터링과 제어 - 테스트 모니터링 : 지속적으로 모든 테스트 활동을 점검하고, 실제 진행 상황을 계획과 비교하는 활동.( == 완료 조건 충족했나)
- 테스트 제어 : 테스트 목적을 달성하는 데 필요한 조치를 하는 활동.
( == 우선순위 재지정, 시작 조건 & 완료 조건 충족하는지 재평가, 테스트 일정 조정)
테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보.
테스트 분석 - 테스트 베이시스를 분석해 테스트 가능한 기능을 식별하고, 관련된 테스트 컨디션을 정의하고, 우선 순위를 정하는 활동이 포함, 이와 관련된 리스크와 리스크 수준도 같이 고려된다. 
- 테스트 베이시스와 테스트 대상을 평가해 결함을 식별하고 테스트 용이성을 평가.
- 테스트 분석을 지원하기 위해 테스트 기법(경계값 분석, 동등분할)을 사용하는 경우가 많다.
- 측정할 수 있는 커버리지 조건으로 "무엇을 테스트할 것인가?"라는 질문에 대한 답을 제공.
(우선순위가 지정된)테스트 컨디션(예: 인수 기준), 
(바로 수정하지 않았다면)테스트 베이시스의 결함에 관한 결함 보고서.
테스트 설계 - 테스트 컨디션을 테스트 케이스와 기타 테스트웨어(예: 테스트 차터)로 구체화하는 작업을 포함. 이 활동은 테스트 케이스 입력값을 구체화하는 데 도움이 되는 커버리지 항목의 식별을 포함하는 경우가 많다.
- 테스트 기법을 활용할 수 있다.
- "어떻게 테스트 할 것인가?"라는 질문에 답을 제공.
(우선순위가 지정된)테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항.
테스트 구현 - 테스트 실행에 필요한 테스트웨어(예: 테스트 데이터)를 만들거나 획득하는 작업을 포함.
- 효율적인 테스트 실행을 위해  테스트 케이스는 테스트 절차로 묶을 수 있고, 테스트 스위트로 조합하는 경우도 많다.
- 수동 및 자동 테스트 스크립트를 만들게 된다.
- 우선 순위를 반영한 테스트 실행 일정으로 테스트 절차를 정리한다. 테스트 환경(테스트 하네스)을 구축하고 올바르게 설정되었는지 확인한다.
테스트 절차, 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정, 테스트 환경 요소(예: 스텁, 드라이버, 시뮬레이터, 서비스 가상화)
테스트 실행 - 지속적 테스팅, 페어 테스팅 세션 등 다양한 형태로 이루어 질 수 있다.
- 실제 테스트 결과를 기대 결과와 비교한다.
- 테스트 결과는 기록된다. 이상 현상을 분석해 가능한 원인을 파악한다. 이런 분석을 통해 관찰한 장애를 기반으로 이상 현상을 보고할 수 있다.
테스트 로그, 결함 보고서.
테스트 완료 - 일반적으로 프로젝트 마일스톤(예 : 릴리스, 반복 주기 완료, 테스트 레벨 완료)에서 수행
- 해결되지 않은 결함에 대해서는 변경 요청서 또는 제품 백로그 항목을 만든다.
- 테스트웨어를 식별해서 보관하거나 적절한 팀에 인계한다.
- 테스트 환경은 합의된 상태로 종료하게 된다.
- 테스트 활동을 분석해 향후 반복 주기, 릴리스, 프로젝트를 위한 교훈과 개선 사항을 파악한다.
- 테스트 완료 보고서를 작성해 이해관계자에게 전달한다.
테스트 완료 보고서, 향후 프로젝트 또는 반복 주기 때 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서(예: 제품 백로그 항목)

 

728x90

+ Recent posts