[Part 1] 소프트웨어 테스팅의 기초

- 용어 -

테스트 컨디션 - 특정 테스트 목적 달성과 관련된 테스트 베이시스의 한 측면 - 하나 또는 그 이상의 테스트 케이스로 검증될 수 있는 항목(item)이나 이벤트로서 정의된다. 유의어 : 테스트 요구사항 , 테스트 상황 (리모컨 예로 전원을 킨다 OR 전원을 끈다.)(실라버스 샘플-A-Q1)

테스트 베이시스 - 요구사항을 내포하고 있는 모든 문서. 테스트 케이시스는 테스트 베이시스를 토대로 만들어 진다. 테스트 분석 및 설계의 기초로 사용되는 지식 체계.

리그레션 테스팅 - 개선을 위한 소프트웨어 수정 후 변경 결과로 소프트웨어의 변경되지 않은 영역에서 결함이 발견되거나 유입되지 않았는지 확인하기 위해 이전 테스트 구성 요소 또는 시스템에 대해 진행하는 테스팅 

메트릭 - 측정을 위해 사용되는 측정 척도 및 방법 
명세(서) - 컴포넌트나 시스템의 요구사항, 설계, 동작, 기타 특성을 지정하는 문서. 이상적인 명세는 완전하고 정확하며, 검증 가능한 방식으로 작성되어 있고, 많은 경우 이러한 규정이 충족되었는지를 확인할 수있는 절차가 포함됨.

테스트 차터 - 세션 기반 탐색적 테스팅에서의 테스트 활동에 대한 문서. 테스트 목적과 테스트 방법에 대한 가능한 테스트 아이디어를 적은것(테스트 분석의 결과로 테스트 컨디션 생성되는 경우도 있음) (실라버스 샘플 A-Q8)

테스트 스위트 - 테스트 구현 산출물에는 테스트 스크립트뿐 아니라 테스트 실행 일정의 묶음인 테스트 스위트.

(실라버스 샘플 A-Q8)

테스트케이스 - 테스트 컨디션에 기반하여 개발된 전제 조건, 입력값, 조치, 기대결과 및 사후 조건의 조합.

(실라버스 샘플 A-Q8)

테스트 스크립트 - 테스트 실행을 위한 일련의 지침. (실라버스샘플 A-Q8)

테스트웨어 - 테스팅에 대한 계획, 설계, 살행, 평가, 보고 등에 활용하기위한 목적으로 테스트 프로세스 동안 생성되는 작업 산출물.

테스팅 - 소프트웨어 제품 및 관련 작업산출물이 특정 요구사항을 충족하는지 확인하고, 목적에 부합하는지 여부를 입증하고, 결함을 발견하기 위해 정적/동적의 모든 계획, 준비, 평가와 관련된 수명주기 활동으로 구성된 프로세스

- - - - - - -

1.1 소프트웨어 테스팅이란 - 소프트웨어 테스팅은 소프트웨어의 품질을 평가하고 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다. (가능한 많은 장애를 찾아내어 결함을 식별하고 수정한다. 샘플-A-Q2)

1.1.1 테스팅의 일반적인 목적

일반적인 프로젝트에서 테스팅은 다음과 같은 목적을 가질 수 있다.

• 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방

• 명시된 모든 요구사항이 충족됐는지 검증

• 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인

• 테스트 대상의 품질 수준에 대한 자신감 획득

• 장애 및 결함 발견과 이에 따른 부적절한 소프트웨어 품질의 리스크 레벨의 감소

• 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공

• 계약, 법적, 규범적 요구사항이나 표준 준수나 테스트 대상이 그런 요구사항이나 표준을 준수하는지 확인

* 테스팅의 목적은 테스트하고 있는 컴포넌트나 시스템의 정황(현재의 테스트 레벨과 사용하는 소프트웨어 개발 수명주기 모델 등에 따라 달라질 수 있다.)

• 컴퍼넌트 테스팅의 목적 중 하나는 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고 수정하는 것일 수 있다. 또 다른 목적은 코드 커버리지를 높이는 것일 수도 있다. ( 결함을 최대한 조기 발견 및 수정 , 코드 커버리지율 증가)
• 인수 테스팅의 목적중 하나는 시스템이 기대한 대로 동작하는지, 또 요구사항을 충족하는지 확인하는 것일 수 있다.또 요구사항을 충족하는지 확인하는 것일 수 있다.또 다른 목적은 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공하는 것일 수 있다.( 시스템이 기대한 대로 동작 확인, 요구사항 충족 확인, 시스템 배포 리스크 정보 전달)

1.1.2 테스팅과 디버깅

테스팅 - 소프트웨어 결함으로 인한 장애를 찾을 수 있다. -> 디버깅에서 수정을 한 후 제대로 수정했는지 확인.

디버깅 - 결함의 장애의 원인을 찾고 분석해서 수정하는 개발 활동.

( 동적 테스팅은 결함으로 발생하는 장애를 보여주고, 디버깅은 소프트웨어에서의 장애의 원인을 찾아 분석하고 제거한다. 실라버스 A-Q3)

1.2 테스팅이 왜 필요한가?

• 컴포넌트 , 시스템 및 관련 문서에 대한 철저한 테스팅은 운영 중 장애 발생 가능성을 줄이는 데 도움.

• 결함을 발견하고 또 발견된 결함을 수정하는 것은 컴포넌트나 시스템의 품질에 기여.

• 계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해 필요 가능성.

1.2.1 성공을 위한 테스팅의 기여

• 결함으로 장애가 발생하거나 이해관계자의 요구를 충족시키지 못하는 상황을 개선

1.2.2 품질 보증과 테스팅

품질관리 - 품질 측면에서 조직이 나아가야하는 방향을 제시하고 제어하는 모든 활동이 포함. ( 품질보증,품질제어 포괄)

       - 품질 보증 - 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는것에 초점.

       - 품질 제어 - 테스팅 - 품질을 높이는데 다양한 방법으로 기여(시스템의 품질 리스크 수준을 낮춰준다).요구사항이 충분히 상세하다는 것을 보증.
       (실라버스 샘플A-Q6)

1.2.3 오류, 결함, 장애

사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점,버그)을 발생시키는 오류(실수)를 범할 수 있고, 이로인해 프로그램은 장애를 일으킬수 있음. (실라버스 샘픔A-Q4)

 

- 대표적 오류 발생원인

• 시간적인 압박

• 사람의 실수

• 경험이 적거나 기술이 부족한 프로젝트 참여자

• 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제

• 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도

• 시스템 내/외부 인터페이스에 대한 이해부족, 특히 내/외부 인터페이스 수가 많은 경우

• 새롭고 익숙하지 않은 기술

1.2.4 결함, 근본 원인, 결과

결함의 근본 원인이란 해당 결함을 생성하는 데 기여한 최초의 행동이나 조건을 지칭. 결함을 분석함으로써 근본 원인을 찾을 수 있으며 , 차후 유사한 결함의 발생 가능성을 낮출 수 있다.

 

*1.3 테스팅의 7 가지 원리 *

1. 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없을 밝히는 활동이 아니다.- 테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 없다는 것을 증명할 수 없다.
2. 완벽한 테스팅은 불가능하다.- 모든 것(입력과 사전 조건의 모든 조합)을 테스팅 한다는 것은 매우 간단한 소프트웨어를 제외하고는 불가능하다. 완벽하게 테스트하고자 확신보다는 리스크 분석과 우선순위를 토대로한 테스트에 노력을 집중하 것이 좋다. 
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.- 초기에 결함을 찾기 위해서는 정적 및 동적 테스트 활동 모두 소프트웨어 개발 수명주기 중 가능한 이른 시점에 시작해야 한다. 초기부터 시작하는 테스팅을 시프트 레프트라고도 부른다. 소프트웨어 수명주기 초기부터 테스팅을 함으로써 나중에 큰 비용이 동반되는 수정을 줄이거나 없앨 수 있다.
4. 결함은 집중된다.- 출시 전 테스팅에서 발견하는 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보이며, 운영상 장애의 대부분 역시 소수의 모듈에서 발생한다. 예상 결함 집중 영역과 테스트와 운영 중 실제로 관측한 결함 집중 영역은 리스크 분석의 주요 입력값으 로 사용된다.
5. 살충제 패러독스에 유의하라- 만일 같은 테스트를 계속해서 반복 실행한다면, 결국 해당 테스트로는 결함을 더 이상 발견할 수 없게 된다. 새로운 결함을 발견하기 위해서는 기존 테스트와 테스트 데이터를 바꾸고 새로운 테스트를 작성할 필요가 있다.(살충제를 계속 사용하다 보면 결국 해충을 잡지 못하듯 테스트도 동일) 자동 리그레션 테스팅의 경우 리그레션 결함이 적다는것을 의미할수도 있다.
6. 테스팅은 정황에 의존적이다.- 테스팅은 정황에 따라 다르게 진행된다. 예를 들어 애자일 프로젝트에서의 테스팅은 순차적 소프트웨어 개발 수명주기 프로젝트에서의 테스팅과는 다르게 진행된다.
7. 오류 부재는 궤변이다.- 조직에 따라서는 테스터가 모든 가능한 테스트를 실행하고 존재하는 모든 결함을 발견하기를 기대하는 경우도 있지만, 원리1과2가 말해주듯 이것은 불가능하다. 단순히 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 궤변(잘못된 믿음)이다.

*1.4 테스트 프로세스*

- 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트(테스트 프로세스) ,주어진 상황에 맞는 구체적은 소프트웨어 프로세스는 다양한 변수에 따라 결정.

테스트 프로세스에 속하는 테스트활동과 이런 활동을 어떻게 구현할지, 또 이런 활동을 언제 수행할지에 대한 내용은 조직의 테스트 전략에서 다룰 수 있다.

 

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

다음은 조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소 중 일부이다.

• 사용 중인 소프트웨어 개발 수명주기 모델과 프로젝트 방법론
• 적용하고자 하는 테스트 레벨과 테스트 유형
• 제품 및 프로젝트 리스크
• 비즈니스 도메인
• 다음과 같은 운영상의 제약사항:- 예산과 자원 / 일정 / 복잡도 / 계약 및 규제 요구사항
• 운영 정책과 프랙티스
• 준수해야 하는 내부 및 외부 표준

1.4.2 테스트 활동과 작업

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

• 테스트 계획 - 테스트 계획서의 수립 또는 수정 활동 (계획서 - 테스트 활동 조정에 사용되며 ,달성할 목표와 방법 일정을 설명하는 문서)
• 테스트 모니터링과 제어 - 테스트 활동의 상황을 확인하고, 계획된 또는 예상된 상태와의 편차를 식별하고 상태를 이해관계자에게 보고하는 테스트 관리 활동
• 테스트 분석 - 테스트 베이시스를 분석하여 테스트 컨디션을 식별하는 활동
• 테스트 설계 - 테스트 컨디션으로부터 테스트 케이스를 유도하고 도출하는 활동
• 테스트 구현 - 테스트 분석과 설계를 기반으로 테스트 실행에 필요한 테스트웨어를 준비하는 활동
• 테스트 실행 - 테스트 대상 컴포넌트나 시스템에 대한 테스트를 실행하고 실제 결과를 생성하는 프로세스
• 테스트 완료 - 테스트 자산을 향후 이용 가능하게 하고, 테스트 환경을 만족스러운 상황으로 유지하고, 관련 이해당사자들에게 테스팅 결과를 전달하는 활동.

용어	내용	주요 활동
테스트 계획	테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동	적합한 테스트 기법과 작업 명시, 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립(계획은 모니터링과 제어활동에서 나온 피드백을 기반으로 수정할 수 있다.
테스트 모니터링과 제어	테스트 모니터링 – 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동. 테스트 제어 – 테스트 계획에 따른 목적 달성을 위해 필요한 행동을 취하는 활동.	종료조건평가 -명시된 커버리지 조건 대비 테스트 결과와 로그 확인 -테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가 -추가 테스트 필요 여부 결정
테스트 분석	테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석. 즉 측정 가능한 커버리지 조건의 측면에서 “무엇을 테스트 할지”를 결정 .테스트 차터 생성 태스트 베이시스의 테스트 용이성 평가 (샘플A-Q7) *( 테스트 분석 중 결함 식별)	- 고려중인 테스트 레벨에 적합한 테스트 베이시스 평가 -테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별 -테스트할 기능과 기능 세트식별 -테스트 베이시스를 평가하고 기능 , 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준등을 고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정 -테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착
테스트 설계	테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어를 생성 “어떻게 테스트 할 것인가?“ 필요한 인프라와 도구식별 (샘플A-Q7) *( 테스트 분석 중 결함 식별)	-테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정 -테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별 -테스트 환경 설계와 필요한 인프라 및 도구 식별 -테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정
테스트 구현	테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트 프로시저를 만드는 것도 여기에 포함된다. “어떻게 테스트할 것인가?＂의 답을 제공하는 반면 “테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?＂질문에 답하는 활동 테스트 스크립트로 테스트 스위트 생성 (샘플A-Q7)	-테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성 -테스트 프로시저와 (있다면) 자동 테스트 스크립트로부터 테스트 스위트 생성 -효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치 -테스트 환경 구축, 가능하다면 테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인 -테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인 -테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로간의 양방향 추적성 검증과 업데잍,
테스트 실행	테스트 스위트를 테스트 실행 일정에 따라 실행.	-테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록 -테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행 -기대 결과와 실제 결과 비교 -이상현상을 분석해 원인 파악 -관찰한 장애를 기반으로 결함 보고 -이상 형상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복(ex. 수정된 테스트 실행, 확인테스팅,리그레션 테스팅등) -테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트
테스트 완료	완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동. 테스트완료 활동은 소프트웨어 시스템을 릴리스 했을 때, 테스트 프로젝트를 완료(또는 취소) 했을때, 애자일 반복주기가 끝났을 때, 특정 테스트 레벨을 완료했을 때, 또는 유지보수 릴리스를 완료했을 때와 같은 프로젝트 마일스톤 시점에서 일어남. 프로세스 개선을 위한 교훈 도출	-모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인 -이해관계자에게 전달할 테스트 요약 보고서 생성 -차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관 -테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계 -완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리스, 또는 프로젝트를 위해 수정해야 하는 사항 판단 -테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용

1.4.3 테스트 작업 산출물

• 테스트 계획 작업 산출물 - 하나이상의 테스트 계획(테스트 베이시스에 대한 정보 포함)
• 테스트 모니터링과 작업 산출물 - 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서(작성일 기준 테스트 진행 상황 관련 필요한 정보를 제공해야함) 산출물은 작업완료, 리소스 할당과 사용, 공수등과 같이 프로젝트 관리에서 관심을 가지는 사항에 대해서도 다뤄야 함.
• 테스트 분석 작업 산출물 - 분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션은 테스트 분석 작업 산출물에 속함. 이상적으로는 각 테스트 컨디션과 그것이 커버하는 테스트 베이시스 요소와의 양방향 추적성이 성립 되어야함. 탐색적 테스팅에서는 테스트 분석 중 테스트 차터를 생성할 수 있음. 테스트 베이시스의 결함을 발견 보고 가능.(샘플 A-Q8)
• 테스트 설계 작업 산출물 - 테스트 컨디션을 실행할 수 있는 테스트 케이스와 테스트 케이스 세트가 만들어짐. 입력 데이터와 기대 결과로 사용할 값이 고정되지 않은 상위 수준 테스트 케이스를 먼저 설계하는 것이 좋은 경우가 많다. 이런 상위 수준 테스트 케이스는 입력 데이터와 기대 결과값을 바꿔가면서 다양한 테스트 주기에서 재활용할 수 있음.동시에 테스트 케이스의 범위를 충분히 기록 이상적으로는 테스트 케이스와 그것이 커버하는 테스트 컨디션 간의 양방향 추적성이 성립 -테스트 설계는 다음과 같은 결과를 가져옴 - 필요한 테스트 데이터의 설계나 식별 , 테스트 환경 설계, 인프라 도구의 식별
• 테스트 구현 작업 산출물 - 테스트 프로시저와 이 프로시저의 배열. 테스트 스위트, 테스트 실행일정 **이상적인 상황에서는 테스트 쿠현이 끝나면, 테스트 케이스와 테스트 컨디션을 통해 테스트 프로시저와 테스트 베이시스 개별 요소 간의 양방향 추적성을 확인함으로써 테스트 계획에서 정의한 커버리지 조건의 달성 여부를 확인할 수 있다. (샘플 A-Q8)
• 테스트 실행 작업 산출물 - 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서 (실행 준비 완료, 합격 ,불합격, 실행하지 못함, 의도적으로 실행하지 않음 등) ,결함 보고서. 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트 웨어 등에 대한 문서 ** 이상적인 상황에서는, 테스트 실행이 끝나면 연관된 테스트 프로시저와의 양방향 추적성을 활용해서 테스트 베이시스 개별 요소의 상태에 대해 판단하고 보고할 수 있음.
• 테스트 완료 작업 산출물 - 테스트 요약 보고서, 차후 프로젝트나 반복주기의 개선을 위한 액션 아치템, 수정요청서 혹은 제품 백로그 항목, 완성된 테스트웨어 등이 있음.

참고 - ISTQB 실라버스