자격증/ISTQB FL2020. 3. 23. 08:00

학습목표
1.1 테스팅이 왜 필요한가? 

1.1.1 소프트웨어의 결함이 사람 , 환경 , 또는 기업에 어떤 악영향을 끼치는지 예를 들어 설명할 수
있다 

1.1.2 결함의 원인과 그 결과를 구별할 수 있다 

1.1.3 테스팅이 필요한 이유를 예를 들어서 설명할 수 있다 

1.1.4 품질보증 QA에서 테스팅이 필요한 이유를 설명하고 더욱 높은 품질 확보에 테스팅이 어떻게
기여하는지 예를 들 수 있다 

1.1.5 오류(Error), 결함 (Defect), 결점 (Fault), 장애 (Failure) 등의 용어 와 거기에 상응하는 실수 (Mistake) 및 버그 ( 라는 용어를 예를 들어 설명하고 비교할 수 있다
 
1.2 테스팅이란 무엇인가? 

1.2.1 테스팅의 일반적인 목적을 상기할 수 있다 

1.2. 2 소프트웨어 수명주기에서의 각 단계별 테스팅 목적을 예를 들어 설명할 수 있다 

1.2. 3 테스팅과 디버깅 을 구별할 수 있다 

1.3 테스팅의 7가지 기본 원리 

1.3.1 테스팅의 7 가지 기본 원리를 설명할 수 있다 

1.4 테스트 프로세스의 기초 

1.4.1 테스트 계획부터 테스트 마감까지 , 5 가지 기본 테스트 활동과 각 활동의 주요 업무를 상기할 수
있다 

1.5 테스팅의 심리학 

1.5.1 테스팅의성공에 영향을 주는 심리적인 요인을 상기할 수 있다 

1.5. 2 테스터와 개발자의 심리 및 사고방식을 대조할 수 있다 - Certified Tester Foundation Level Syllabus Version 2018

용어 (Keywords)
커버리지(coverage), 디버깅(debugging), 결함(defect), 오류(error), 장애(failure), 품질(quality), 품질 보증(quality assurance), 근본 원인(root cause), 테스트 분석(test analysis), 테스트 베이시스(test basis), 테스트 케이스(test case), 테스트 완료(test completion), 테스트 컨디션(test condition), 테스트 제어(test control), 테스트 데이터(test data), 테스트 설계(test design), 테스트 실행(test execution), 테스트 구현(test implementation), 테스트 모니터링(test monitoring), 테스트 대상(test object), 테스트 목적(test objective), 테스트 오라클(test oracle), 테스트 계획(test planning), 테스트 절차(test procedure), 테스트 프로세스(test process), 테스트 스위트(test suite), 테스팅(testing), 테스트웨어(testware), 추적성(traceability), 밸리데이션(확인 validation), 베리피케이션(검증 verification)

학습목표
1.1 테스팅이란 무엇인가? (What is Testing?)
FL-1.1.1  테스팅의 일반적인 목적을 파악한다.
FL-1.1.2  테스팅과 디버깅을 구별할 수 있다.

1.2 테스팅이 왜 필요한가? (What is Testing Necessary?)
FL-1.2.1  테스팅이 왜 필요한지 예를 들 수 있다.
FL-1.2.2  품질 보증과 테스팅의 관계를 설명하고, 높은 품질 확보에 테스팅이 어떻게
기여하는지 예를 들 수 있다.
FL-1.2.3  오류(error), 결함(defect), 장애(failure)를 구별할 수 있다.
FL-1.2.4  결함의 근본 원인과 그것의 영향을 구별할 수 있다.

1.3 테스팅의 7 가지 원리 (Seven Testing Principles)
FL-1.3.1  테스팅의 7 가지 원리를 설명할 수 있다.

1.4 테스트 프로세스 (Test Precess)
FL-1.4.1  정황이 테스트 프로세스에 미치는 영향에 대해 설명할 수 있다.
FL-1.4.2  테스트 프로세스의 테스트 활동과 연관된 작업에 대해 설명할 수 있다.
FL-1.4.3  테스트 프로세스를 지원하는 작업 산출물을 구별할 수 있다.
FL-1.4.4  테스트 베이시스와 테스트 작업 산출물 간의 추적성을 유지하는 것이 어떻게 도움이 되는지 설명할 수 있다.
 
1.5 테스팅의 심리학 (The Psychology of Testing)
FL-1.5.1  테스팅의 성공에 영향을 주는 심리 요인을 식별할 수 있다.
FL-1.5.2  테스트 활동에 필요한 사고방식과 개발 활동에 필요한 사고방식을 구별할 수 있다.

 

소프트웨어 시스템은 인터넷 은행과 같은 비즈니스 응용 프로그램부터 자동차와 같은 소비자 제품까지 생활의
많은 부분과 밀접하게 연관되어 있다. 많은 사람들은 소프트웨어를 사용하면서 기대한 것과 다르게 동작하는 걸
느낀 적이 있을 것이다. 올바르게 작동하지 않는 소프트웨어는 금전, 시간, 비즈니스 평판 손실은 물론, 심하게는
부상이나 사망에 이르기까지 심각한 문제를 일으킬 수 있다. 소프트웨어 테스팅은 소프트웨어의 품질을
평가하고, 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다.
테스팅에 대해 많이 오해하는 것 중 하나는 테스팅이 단지 소프트웨어를 실행하고 결과를 확인하는 테스트
수행에 국한된다고 생각하는 것이다. 1.4 절에 설명하고 있는 바와 같이, 소프트웨어 테스팅이란 다양한 활동을
포함하는 프로세스이며 테스트 실행(결과 확인 포함)은 그 많은 활동 중 하나일 뿐이다. 테스트 프로세스는
테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 및 결과 보고, 테스트 대상 품질 평가 등 많은 활동을
포함한다.
테스팅 활동에는 테스트 대상 컴포넌트나 시스템을 실행하는 것도 있다. 이런 테스팅을 동적 테스팅이라
부른다. 반면 테스트 대상 컴포넌트나 시스템을 실행하지 않는 테스팅도 있다. 이런 테스팅은 정적 테스팅이라
부른다. 따라서 요구사항, 사용자 스토리, 소스 코드와 같은 작업 산출물에 대한 리뷰 역시 테스팅에 포함된다.
테스팅에 대한 또 다른 오해는 테스팅이 요구사항, 사용자 스토리, 그 외 기타 명세의 베리피케이션(검증
verification)에만 국한된 활동이라는 것이다. 시스템이 주어진 명세를 충족하는지 확인하는 것이 테스팅에
포함되긴 하지만, 시스템이 운영 환경에서 사용자 또는 기타 이해관계자의 요구를 만족시키는지를 확인하는
밸리데이션(확인 validation) 또한 테스팅에 포함된다.
테스팅 활동은 수명주기 모델에 따라 다르게 계획하고 수행한다 (2.1 절 참조).

1.1.1 테스팅의 일반적인 목적 (Typical Objectives of Testing)
일반적인 프로젝트에서 테스팅은 다음과 같은 목적을 가질 수 있다:
● 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
● 명시된 모든 요구사항이 충족됐는지 검증
● 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
● 테스트 대상의 품질 수준에 대한 자신감 획득
● 장애 및 결함 발견과 이에 따른 부적절한 소프트웨어 품질의 리스크 레벨의 감소
● 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
● 계약, 법적, 규범적 요구사항이나 표준 준수나 테스트 대상이 그런 요구사항이나 표준을 준수하는지 확인
테스팅의 목적은 테스트하고 있는 컴포넌트나 시스템의 정황 즉, 현재의 테스트 레벨과 사용하는 소프트웨어
개발 수명주기 모델 등에 따라 달라질 수 있다. 목적이 정황에 따라 달라지는 예는 다음과 같다:
● 컴포넌트 테스팅의 목적 중 하나는 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고
수정하는 것일 수 있다. 또 다른 목적은 코드 커버리지를 높이는 것일 수도 있다.
● 인수 테스팅의 주요 목적 중 하나는 시스템이 기대한 대로 동작하는지, 또 요구사항을 충족하는지
확인하는 것일 수 있다. 또 다른 목적은 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를
이해관계자에게 제공하는 것일 수 있다.

1.1.2 테스팅과 디버깅 (Testing and Debugging)
테스팅과 디버깅은 다르다. 테스트를 실행하면 소프트웨어 결함으로 인한 장애를 찾아낼 수 있으며, 디버깅은
그런 장애의 원인을 찾고 분석해서 수정하는 개발 활동이다. 이후 실행되는 확인 테스팅에서 결함을 제대로
수정했는지 확인한다. 테스터가 초기 테스트와 마지막 확인 테스트를 담당하고 개발자는 디버깅 관련 컴포넌트
및 컴포넌트 통합 테스팅 (지속적 통합)을 수행한다. 반면, 애자일 개발 및 기타 소프트웨어 수명주기
모델에서는 테스터가 디버깅과 컴포넌트 테스팅에 관여하기도 한다.
소프트웨어 테스팅 개념에 대한 추가적인 정보는 ISO 표준(ISO/IEC/IEEE 29119-1)에서 찾을 수 있다.


1.2 테스팅이 왜 필요한가? Why is Testing Necessary?
컴포넌트, 시스템 및 관련 문서에 대한 철저한 테스팅은 운영 중 장애 발생 가능성을 줄이는 데 도움이 된다.
결함을 발견하고 또 발견된 결함을 수정하는 것은 컴포넌트나 시스템의 품질에 기여하는 것이다. 또한,
소프트웨어 테스팅이 계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해 필요할 수도 있다.
1.2.1 성공을 위한 테스팅의 기여 (Testing’s Contributions to Success)
컴퓨터의 역사에서 소프트웨어와 시스템이 운영을 위해 배포된 후로, 결함으로 장애가 발생하거나
이해관계자의 요구를 충족시키지 못하는 상황은 늘 있었다. 하지만 적절한 테스트 기법을 적절한 테스트
전문성을 가지고 적절한 테스트 레벨과 개발 수명주기 단계에 적용하면, 소프트웨어와 시스템이 그런 문제를
안고 배포되는 경우를 줄일 수 있다. 대표적인 예로는:
● 테스터를 요구사항 리뷰 혹은 사용자 스토리 개선에 참여시키면 해당 작업 산출물에서 결함을 발견할
수 있다. 요구사항 결함을 식별하고 제거하면 잘못된 혹은 테스트할 수 없는 기능이 개발되는 리스크를
줄일 수 있다.
● 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우, 설계와 그것을 어떻게
테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 된다. 이렇게 이해도가 올라가면 기능
설계에 결함이 유입되는 리스크가 줄어들게 되고, 필요한 테스트를 좀 더 일찍 식별할 수 있다.
● 코드를 개발하는 동안 테스터가 개발자와 적극적으로 협업할 경우, 코드와 그것을 어떻게 테스트해야
하는지에 대해 서로 좀 더 깊이 있게 이해하게 된다. 이렇게 이해도가 높아짐변 코드와 테스트에서의
결함 발생 리스크가 줄어든다.
● 테스터가 릴리스 전에 소프트웨어를 확인하고 검증하면, 그러지 않았을 경우 놓쳤을 수 있는 장애를
발견하고 그 장애의 원인인 결함을 제거(즉, 디버깅)하는 데 도움을 줄 수 있다. 이렇게 함으로써
소프트웨어가 이해관계자의 필요와 요구사항을 충족시킬 가능성을 높일 수 있다.
이런 경우뿐만 아니라 정의된 테스트 목적(1.1.1 절 참조)을 충족하는 것은 소프트웨어 개발과 유지보수 전반의
성공 확률을 높여준다.

1.2.2 품질 보증과 테스팅 (Quality Assurance and Testing)
일반적으로 사람들이 품질 보증(QA, Quality Assurance)과 테스팅을 혼용해서 사용하는 경우가 많은데 어느
정도 연관성이 있지만 품질 보증과 테스팅은 다른 개념이다. 둘 다 좀 더 포괄적인 개념인 품질 관리(quality
management)에 속한다. 품질 관리에는 품질 측면에서 조직이 나아가야 하는 방향을 제시하고 제어하는 모든
활동이 포함된다. 품질 관리는 또한 품질 보증과 품질 제어를 포함한 여러 가지 활동을 포함한다. 일반적으로
품질 보증은 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에
초점을 두고 있다. 프로세스를 따를 경우, 해당 프로세스를 바탕으로 생성되는 작업 산출물의 품질은 더 월등한
경우가 많으며, 높은 작업 산출물 품질은 결함 예방에 도움이 된다. 또한, 결함의 원인을 찾아서 제거하기 위한
근본 원인 분석(root cause analysis)의 활용과 회고 회의(retrospective meetings)의 결과를 적절하게 적용해서
프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항들이다.
품질 제어에도 적합한 품질 수준을 달성하기 위한 다양한 활동이 있으며, 테스트 활동도 여기에 포함된다.
테스트 활동은 전반적인 소프트웨어 개발 및 유지보수 프로세스의 일부이다. 품질 보증에서는 전반적인
프로세스의 올바른 수행 여부에 관심을 가지기 때문에 올바른 테스팅의 적용에도 관심을 가진다. 1.1.1 절과
1.2.1 절에서 설명하는 바와 같이, 테스팅은 품질을 높이는 데 다양한 방법으로 기여한다.

1.2.3 오류, 결함, 장애 (Errors, Defects, and Failures)
사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시키는 오류(실수)를 범할
수 있다. 특정 작업 산출물 내 결함의 원인이 되는 오류는 연관된 다른 작업 산출물의 결함의 원인이 되는 또
다른 오류의 계기가 될 수 있다. 예를 들어, 요구사항을 도출하면서 범해진 오류는 요구사항 결함이 되며, 이런
요구사항 결함은 프로그램 작성 시 오류를 일으켜 결국 코드 결함의 원인이 된다.
코드의 결함이 실행되면 장애를 일으킬 수 있지만 반드시 그런 것은 아니다. 예를 들어, 결함 중 일부는 발생
가능성이 없거나 매우 낮아서 특수한 입력이나 사전조건이 충족돼야 장애를 일으킬 수 있다.
대표적인 오류 발생 원인은 다음과 같다:
● 시간적인 압박
● 사람의 실수
● 경험이 적거나 기술이 부족한 프로젝트 참여자
● 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제
● 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도
● 시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우
● 새롭고 익숙하지 않은 기술장애는 코드 결함뿐만 아니라 환경 조건으로 인해 발생할 수도 있다. 
예를 들어, 방사능, 전자기장, 환경 오염 등은 펌웨어 결함의 원인이 되거나 하드웨어 상태를 변화시킴으로써 소프트웨어 실행에 영향을 줄 수 있다.
테스트 결과가 기대한 것과 다르다고 해서 무조건 장애가 있다고 볼 수는 없다. 테스트 실행 방식의 오류나
테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우, 또는 그 외 다양한 이유로 거짓양성(false
positive)이 발생할 수 있다. 비슷한 오류나 결함이 거짓음성(false negative)의 원인이 되는 반대의 경우도
발생할 수 있다. 거짓음성은 테스트가 발견했어야 할 결함을 발견하지 못하는 경우이며, 거짓양성은 결함으로
보고됐지만 실제 결함이 아닌 경우를 말한다.

1.2.4 결함, 근본 원인, 결과 (Defects, Root Causes and Effects)
결함의 근본 원인이란 해당 결함을 생성하는 데 기여한 최초의 행동이나 조건을 지칭한다. 결함을 분석함으로써
근본 원인을 찾을 수 있으며, 차후 유사한 결함의 발생 가능성을 낮출 수 있다. 가장 근본적인 원인을 분석하고
여기에 집중하기 때문에, 이를 기반으로 이루어지는 프로세스 개선은 이후 발생하는 결함 수를 상당 부분
줄여준다.
예를 들어, 단 한 줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만을 초래한다. 제품 소유자가 이자
계산법을 잘못 이해해서 작성한 애매모호한 사용자 스토리를 기반으로 코드가 잘못 작성되었다. 대부분의
결함이 이자 계산식에 존재하며 해당 결함들의 근본 원인 역시 비슷한 오해로 인한 것이라면, 차후 유사한
결함의 발생 가능성을 낮추기 위해 제품 소유자에게 이자 계산에 대한 교육을 제공할 수 있다.
앞의 예제에서의 결과는 소비자 불만이며 장애는 잘못된 이자 지급이다. 결함은 코드에 포함된 잘못된
계산식이며, 그것의 원인이 되는 최초 결함은 사용자 스토리의 모호성이다. 최초 결함의 근본 원인은 제품
소유자의 지식 부족이었으며, 그 결과로 제품 소유자가 사용자 스토리를 작성할 때 오류를 범했다고 볼 수 있다.
근본 원인 분석 프로세스는 ISTQB-CTFL-TM 및 ISTQB-CTFL-ITP 에서 다루고 있다.

1.3 테스팅의 7 가지 원리 Seven Testing Principles
지난 50 년간 모든 테스팅에 적용할 수 있는 공통 지침을 제공하는 다양한 테스팅 원리가 제안되어 왔다.
1. 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다 (Testing shows the
presence of defects, not their absence)
테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수 없다. 테스팅은
소프트웨어에 발견되지 않은 결함의 존재 가능성을 줄일 수는 있지만, 결함이 전혀 발견되지 않았다 하더라도
해당 소프트웨어가 완벽하다는 뜻은 아니다.
2. 완벽한(exhaustive) 테스팅은 불가능하다 (Exhaustive testing is impossible)
모든 것(입력과 사전 조건의 모든 조합)을 테스팅 한다는 것은 매우 간단한 소프트웨어를 제외하고는
불가능하다. 따라서, 완벽하게 테스트하고자 하기보다는 리스크 분석과 우선순위를 토대로한 테스트에 노력을
집중하는 것이 좋다.
3. 조기 테스팅(early testing)으로 시간과 비용을 절약할 수 있다 (Early testing saves time and money)
초기에 결함을 찾기 위해서는 정적 및 동적 테스트 활동 모두 소프트웨어 개발 수명주기 중 가능한 이른 시점에
시작해야 한다. 초기부터 시작하는 테스팅을 시프트 레프트(shift left)라고도 부른다. 소프트웨어 수명주기
초기부터 테스팅을 함으로써 나중에 큰 비용이 동반되는 수정을 줄이거나 없앨 수 있다 (3.1 절 참조).
4. 결함은 집중된다 (Defects cluster together)
출시 전 테스팅에서 발견하는 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보이며, 운영상 장애의
대부분 역시 소수의 모듈에서 발생한다. 예상 결함 집중 영역과 테스트와 운영 중 실제로 관측한 결함 집중
영역은 리스크 분석의 주요 입력값으로 사용된다. 리스크 분석은 테스트 노력을 집중시키는 데 필요하다 (원리
2 참조).
5. 살충제 패러독스(pesticide paradox)에 유의하라 (Beware of the pesticide paradox)
만일 같은 테스트를 계속해서 반복 실행한다면, 결국 해당 테스트로는 결함을 더 이상 발견할 수 없게 된다.
새로운 결함을 발견하기 위해서는 기존 테스트와 테스트 데이터를 바꾸고 새로운 테스트를 작성할 필요가 있다.
(살충제를 계속 사용하다 보면 결국 해충을 잡지 못하듯, 테스트도 반복하다 보면 결국 결함을 더 이상 찾지
못하게 된다.) 하지만 살충제 패러독스가 좋은 것을 의미하는 경우도 있다. 자동 리그레션 테스팅의 경우
리그레션 결함이 적다는 것을 의미할 수도 있다.
6. 테스팅은 정황(context)에 의존적이다 (Testing is context dependent)
테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전 최우선 산업에서 사용하는 제어 소프트웨어는
이커머스 모바일 애플리케이션과는 다르게 테스트한다. 또, 애자일 프로젝트에서의 테스팅은 순차적
소프트웨어 개발 수명주기 프로젝트에서의 테스팅과는 다르게 진행된다 (2.1 절 참조).
7. 오류 부재는 궤변이다 (Absence-of-errors is a fallacy)
조직에 따라서는 테스터가 모든 가능한 테스트를 실행하고 존재하는 모든 결함을 발견하기를 기대하는 경우도
있지만, 원리 1 과 2 가 말해주듯 이것은 불가능하다. 뿐만 아니라, 단순히 많은 결함을 발견하고 고쳤다고 해서
시스템의 성공이 보장된다고 생각하는 것은 궤변(즉, 잘못된 믿음)이다. 예를 들어, 정의된 모든 요구사항을
충분히 테스트하고 발견된 모든 결함을 수정하더라도 여전히 사용하기 어렵거나, 사용자의 요구와 기대를
충족시키지 못하거나, 경쟁 시스템에 비해 부족한 시스템을 만들어낼 수 있다.
위에 나열된 원리와 기타 테스팅 원리에 대한 예제를 위해서는 Myers 2011, Kaner 2002, Weinberg 2008,
Beizer 1990 을 참조하라.

1.4 테스트 프로세스 Test Process
모두가 사용하는 일반적인 테스트 프로시저는 없지만, 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트
활동 세트(sets)는 존재한다. 이런 테스트 활동 세트를 테스트 프로세스라 한다. 주어진 상황에 맞는 구체적인
소프트웨어 테스트 프로세스는 다양한 변수에 따라 결정된다.
테스트 프로세스에 속하는 테스트 활동과 이런 활동을 어떻게 구현할지, 또 이런 활동을 언제 수행할지에 대한
내용은 조직의 테스트 전략에서 다룰 수 있다.
1.4.1 정황에 따른 테스트 프로세스 (Test Process in Context)
다음은 조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소 중 일부이다:
● 사용 중인 소프트웨어 개발 수명주기 모델과 프로젝트 방법론
● 적용하고자 하는 테스트 레벨과 테스트 유형
● 제품 및 프로젝트 리스크
● 비즈니스 도메인
● 다음과 같은 운영상의 제약사항:
Ο 예산과 자원 (resource)
Ο 일정
Ο 복잡도
Ο 계약 및 규제 요구사항
● 운영 정책과 프랙티스 (practices)
● 준수해야 하는 내부 및 외부 표준
다음 절은 아래의 관점에서 조직 테스트 프로세스의 일반적인 요소에 대해 설명하고 있다:
● 테스트 활동과 작업
● 테스트 작업 산출물
● 테스트 베이시스와 테스트 작업 산출물 간의 추적성
테스트 레벨과 유형에 상관없이, 테스트 베이시스에 대한 측정 가능한 커버리지 조건이 설정되어 있으면 매우
유용하다. 커버리지 조건은 소프트웨어 테스트의 목적 달성 여부를 보여주는 활동의 주요 성능 지표(KPI, key
performance indicator)로 사용하기 용이하다 (1.1.1 절 참조).
예를 들어, 모바일 애플리케이션에 대해서는 요구사항 목록과 지원 대상 모바일 기기 목록을 테스트 베이시스로
사용할 수 있는데, 각각의 요구사항과 테스트 대상 기기를 하나의 테스트 베이시스 요소로 볼 수 있다. 커버리지
조건은 각 테스트 베이시스 요소를 적어도 하나의 테스트 케이스로 다루어야 한다는 것일 수 있다. 실행한
테스트 케이스의 결과는 명시된 요구사항의 충족 여부와 지원 대상 기기에서 장애가 발생했는지에 대한 정보를
이해관계자에게 제공한다.
테스트 프로세스에 대해서는 ISO 표준(ISO/IEC/IEEE 29119-2)에서 자세히 다루고 있다.
1.4.2 테스트 활동과 작업 (Test Activities and Tasks)
테스트 프로세스를 구성하는 주요 활동은 다음과 같다:
● 테스트 계획
● 테스트 모니터링과 제어
● 테스트 분석
● 테스트 설계
● 테스트 구현
● 테스트 실행
● 테스트 완료
각 주요 활동은 구성 활동들로 이루어지며, 아래 하위 섹션에서 하나씩 다룹니다. 각 구성 활동은 다시 다수의
개별 작업으로 나눠지며 프로젝트마다 또는 릴리즈마다 달라질 수 있다.
또한, 이러한 주요 활동들이 대부분 순차적으로 이루어지는 것처럼 보일 수 있으나 반복적으로 구현되는 경우가
많다. 예를 들어, 애자일 개발은 지속적인 계획을 바탕으로 소프트웨어 설계, 빌드(build), 테스트로 구성된 작은
주기를 반복해서 배치한다. 따라서, 이런 소프트웨어 개발 접근법에 포함된 테스트 활동 또한 반복적,
지속적으로 이루어지게 된다. 순차적 소프트웨어 개발에서도 개별 활동의 논리적인 순서는 중첩(overlap),
조합(combination), 동시 실행(concurrency) 되거나 누락되기 때문에 시스템과 프로젝트의 정황에 따라 이런
주요 활동들을 어느 정도 조정하는 것이 필요하다.

테스트 계획 (test planning)
테스트 계획은 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한
접근법을 정의하는 활동을 포함한다. 예를 들어, 적합한 테스트 기법과 작업 명시, 정해진 출시 일정 전에
완료하기 위한 테스트 일정 수립 등이 여기에 포함된다. 테스트 계획은 모니터링과 제어 활동에서 나온
피드백을 기반으로 수정할 수 있다. 테스트 계획은 5.2 절에서 더 구체적으로 다루고 있다.
테스트 모니터링과 제어 (test monitoring and control)
테스트 모니터링은 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척
상황과 지속적으로 비교하는 활동을 말한다. 테스트 제어(test control)는 테스트 계획에 따른 목적 달성을 위해
필요한 행동을 취하는 활동을 포함한다. 테스트 계획에 나와 있는 목적은 시간이 지남에 따라 수정될 수 있다.
종료 조건(exit criteria) 평가도 테스트 모니터링과 제어에 필요한 활동이며, 일부 소프트웨어 개발 수명주기
모델에서는 종료 조건을 완료의 정의(definition of done)로 칭하기도 한다 [ISTQB-CTFL-AT] 참조. 예를 들어,
특정 테스트 레벨에서 이루어진 테스트 실행의 종료 조건 평가는 다음을 포함할 수 있다:
● 명시된 커버리지 조건 대비 테스트 결과와 로그 확인
● 테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가
● 추가 테스트 필요 여부 결정 (예: 일정 수준의 제품 리스크 커버리지를 달성하고자 했던 테스트가
그러지 못했을 경우, 추가적인 테스트 작성 및 실행 요구)
계획 대비 테스트 진행 상황은 이해관계자에게 테스트 진행 상황 보고서의 형태로 전달되며, 여기에는 계획
대비 편차와 테스팅을 그만하기로 결정했다면 그것을 뒷받침해 줄 정보도 포함되어야 한다.
테스트 모니터링과 제어는 5.3 절에서 좀 더 상세히 다루고 있다.

테스트 분석 (Test analysis)
테스트 분석에서는 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석한다.
즉, 테스트 분석은 측정 가능한 커버리지 조건의 측면에서 "무엇을 테스트할지"를 결정하는 것이다.
테스트 분석의 주요 활동은 다음과 같다:
● 고려 중인 테스트 레벨에 적합한 테스트 베이시스 평가. 예를 들어:
Ο 요구사항 명세. 여기에 포함되는 것으로는 비즈니스 요구사항, 기능 요구사항, 시스템 요구사항,
사용자 스토리, 에픽(epic), 유스케이스, 요구되는 기능/비기능 컴포넌트나 시스템의 동작이 명시된
유사한 작업 산출물 등이 있다.
Ο 설계와 구현 정보. 여기에 포함되는 것으로는 시스템이나 소프트웨어 아키텍처 다이어그램 또는
문서, 설계 명세, 콜흐름도(call flow graphs), 모델링 다이어그램 (예: UML 또는 개체-관계
다이어그램 (entity-relationship diagrams), 인터페이스 명세, 컴포넌트나 시스템 구조를 명시하고
있는 기타 유사한 작업 산출물 등이 있다.
Ο 구현한 컴포넌트나 시스템. 여기에 포함되는 것으로는 코드, 데이터베이스 메타데이터(database
metadata), 쿼리(queries), 인터페이스 등이 있다.
Ο 컴포넌트나 시스템의 기능, 비기능, 구조 측면을 고려한 리스크 분석 보고서
● 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별. 예를 들어:
Ο 모호함 (Ambiguities)
Ο 누락 (Omissions)
Ο 불일치 (Inconsistencies)
Ο 부정확 (Inaccuracies)
Ο 모순 (Contradictions)
Ο 불필요한 구문 (Superfluous Statements)
● 테스트할 기능과 기능 세트 식별
● 테스트 베이시스를 평가하고 기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을
고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정
● 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착 (1.4.3 절, 1.4.4 절
참조)
테스트 분석(4 장 참조)에 블랙박스, 화이트박스, 경험 기반 기법을 적용하면 주요 테스트 컨디션의 누락을
방지하고 더 정확하고 정밀한 테스트 컨디션 도출에 도움이 될 수 있다.
테스트 분석의 결과로 테스트 차터(test charter)의 테스트 목적으로 사용할 테스트 컨디션이 생성되는 경우도
있다. 테스트 차터는 일부 경험 기반 테스팅 유형에서 일반적으로 사용하는 작업 산출물이다 (4.4.2 절 참조).
테스트 목적과 테스트 베이시스 간의 추적성을 확인할 수 있는 경우, 이런 경험 기반 테스팅으로 달성하는
커버리지를 측정할 수 있다.
테스트 분석 중 결함 식별은 큰 잠재적 이점이다. 특히, 사용하는 리뷰 프로세스가 없거나 테스트 프로세스가
리뷰 프로세스와 밀접하게 연관된 경우 더 그렇다. 이런 테스트 분석 활동은 요구사항이 일관성 있게 제대로
설명되고 완성되었는지 검증할 뿐 아니라, 요구사항이 고객, 사용자, 기타 이해관계자의 요구를 제대로
반영하고 있는지 확인하게 해준다. 예를 들면 코딩(coding) 전에 사용자 스토리와 인수 조건으로부터 테스트
컨디션과 테스트 케이스를 도출하는 행위 주도 개발(BDD, Behavior Driven Development)과 인수 테스트 주도
개발(ATDD, Acceptance Test Driven Development)이 있다. 이런 기법에서는 사용자 스토리와 인수 조건에
대해서도 검증, 확인, 결함 발견 활동을 수행한다 (ISTQB CTFL-AT 참조).
테스트 설계 (Test design)
테스트 설계에서 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타
테스트웨어(testware)를 생성한다. 즉, 테스트 분석은 "무엇을 테스트할 것인가?"라는 질문에 답변하는 반면,
테스트 설계는 "어떻게 테스트할 것인가?"를 다루게 된다.
테스트 설계에 속하는 주요 활동은 다음과 같다:
● 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정
● 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별
● 테스트 환경 설계와 필요한 인프라 및 도구 식별
● 테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정 (1.4.4 절 참조)
테스트 설계 중 테스트 컨디션을 테스트 케이스와 테스트 케이스 세트로 전환할 때 테스트 기법을 사용하는
경우가 많다 (4 장 참조).
테스트 분석과 마찬가지로, 테스트 설계에서도 테스트 베이시스에서 유사한 유형의 결함을 식별할 수 있다.
또한, 테스트 설계 중 결함 식별은 테스트 분석에서와 마찬가지로 큰 잠재적 이점이다.
테스트 구현 (Test implementation)
테스트 구현 중 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트
프로시저를 만드는 것도 여기에 포함된다. 결국, 테스트 설계는 "어떻게 테스트할 것인가?"라는 질문에 대한
답을 제공하는 반면, 테스트 구현은 "테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?"라는 질문에
답하는 활동이다.
테스트 구현에 속하는 주요 활동은 다음과 같다:
● 테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성
● 테스트 프로시저와 (있다면) 자동 테스트 스크립트로부터 테스트 스위트(test suite) 생성
● 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치 (5.2.4 절 참조)
● 테스트 환경 구축, 가능하다면 테스트 하네스(test harness), 서비스 가상 현실화, 시뮬레이터, 기타
인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인
● 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인
● 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로 간의 양방향
추적성 검증과 업데이트 (1.4.4 절 참조)
테스트 설계와 테스트 구현 작업은 합쳐지는 경우가 많다.
탐색적 테스팅과 기타 경험 기반 테스팅 유형에서 테스트 설계와 구현이 테스트 실행의 일부로 이루어지거나
기록될 수 있다. 탐색적 테스팅은 테스트 분석에서 생성되는 테스트 차터를 기반으로 이루어질 수 있으며,
탐색적 테스트는 설계되고 구현되면서 바로 실행된다 (4.4.2 절 참조).
테스트 실행 (Test execution)
테스트 실행 단계에서는 테스트 스위트를 테스트 실행 일정에 따라 실행한다.
테스트 실행의 주요 활동은 다음과 같다:
● 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
● 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
● 기대 결과와 실제 결과 비교
● 이상 현상(anomalies)을 분석해 원인 파악 (예를 들어, 장애가 코드 결함 때문에 발생할 수도 있지만
거짓양성일 수도 있다 (1.2.3 절 참조))
● 관찰한 장애를 기반으로 결함 보고 (5.6 절 참조)
● 테스트 실행 결과 기록 (예: 합격, 불합격, 실행할 수 없음)
● 이상 현상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복 (예: 수정된
테스트 실행, 확인 테스팅이나 리그레션 테스팅 등)
● 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성
검증과 업데이트

테스트 완료 (Test completion)
테스트 완료 활동은 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는
활동이다. 테스트 완료 활동은 소프트웨어 시스템을 릴리스 했을 때, 테스트 프로젝트를 완료(또는 취소)했을 때,
애자일 반복주기가 끝났을 때, 특정 테스트 레벨을 완료했을 때, 또는 유지보수 릴리스를 완료했을 때와 같은
프로젝트 마일스톤 시점에서 일어난다.
테스트 완료의 주요 활동은 다음과 같다:
● 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는
프로젝트 백로그 항목을 생성했는지 확인
● 이해관계자에게 전달할 테스트 요약 보고서 생성
● 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관
● 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계
● 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리스, 또는 프로젝트를 위해
수정해야 하는 사항 판단
● 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용

1.4.3 테스트 작업 산출물 (Test Work Products)
테스트 작업 산출물은 테스트 프로세스의 일부로 생성된다. 조직마다 테스트 프로세스를 구현하는 방법이
다르듯이, 테스트 프로세스 중 생성되는 작업 산출물의 유형, 이 작업 산출물을 정리하고 관리하는 방법과
부르는 명칭 또한 다양하다. 이 실러버스는 위에서 설명한 테스트 프로세스와 이 실러버스 및 ISTQB
용어사전(glossary)의 작업 산출물을 기준으로 설명하고 있다. 작업 산출물에 대한 설명은 ISO 표준
(ISO/IEC/IEEE 29119-3)에서도 찾을 수 있다.
이 절에서 설명하고 있는 테스트 작업 산출물 중 다수는 테스트 관리 도구와 결함 관리 도구를 활용해서 작성
및 관리할 수 있다 (6 장 참조).
테스트 계획 작업 산출물 (Testing planning work products)
테스트 계획 작업 산출물에는 일반적으로 하나 이상의 테스트 계획이 포함된다. 테스트 계획은 테스트
베이시스에 대한 정보를 포함한다. 테스트 베이시스는 추적성 정보를 통해 다른 작업 산출물뿐만 아니라,
테스트 모니터링과 제어에 사용되는 종료 조건(또는 완료 기준)과도 연결된다 (아래와 1.4.4 절 참조). 테스트
계획은 5.2 절에서 설명하고 있다.
테스트 모니터링과 제어 작업 산출물 (Test monitoring and control work products)
테스트 모니터링과 제어 작업 산출물은 보통 지속적, 정기적으로 생성되는 테스트 진행 현황 보고서와 다양한
테스트 완료 마일스톤에서 생성되는 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서를 포함한다. 모든
테스트 보고서는 작성일 기준 테스트 진행 상황 관련 필요한 정보를 독자에게 제공해야 한다. 테스트 실행
결과가 나오면 그것에 대한 요약도 포함해야 한다.
테스트 모니터링과 제어 작업 산출물은 작업 완료, 리소스 할당과 사용, 공수 등과 같이 프로젝트 관리에서
관심을 가지는 사항에 대해서도 다루어야 한다.
테스트 모니터링과 제어, 또 이런 활동 중 생성되는 작업 산출물에 대해서는 이 실러버스 5.3 절에서 상세히
다루고 있다.

테스트 분석 작업 산출물 (Test analysis work products)
분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션은 테스트 분석 작업 산출물에 속한다. 이상적으로는 각
테스트 컨디션과 그것이 커버하는 테스트 베이시스 요소와의 양방향 추적성이 성립되어 있어야 한다. 탐색적
테스팅에서는 테스트 분석 중 테스트 차터를 생성할 수 있다. 또, 테스트 분석에서 테스트 베이시스의 결함을
발견, 보고할 수 있다.

테스트 설계 작업 산출물 (Test design work products)
테스트 설계의 결과로 테스트 분석에서 정의한 테스트 컨디션을 실행할 수 있는 테스트 케이스와 테스트
케이스 세트가 만들어진다. 입력 데이터와 기대 결과로 사용할 값이 고정되지 않은 상위 수준 테스트 케이스를
먼저 설계하는 것이 좋은 경우가 많다. 이런 상위 수준 테스트 케이스는 입력 데이터와 기대 결과값을
바꿔가면서 다양한 테스트 주기에서 재활용할 수 있으며, 동시에 테스트 케이스의 범위를 충분히 기록할 수
있게 해준다. 이상적으로는 각각의 테스트 케이스와 그것이 커버하는 테스트 컨디션 간의 양방향 추적성이
성립되어 있어야 한다.
테스트 설계는 또한 다음과 같은 결과를 가져온다:
 필요한 테스트 데이터의 설계나 식별,
 테스트 환경 설계,
 인프라와 도구의 식별
그러나 이런 결과를 문서로 기록하는 정도의 차이는 상당히 큰 편이다.

테스트 구현 작업 산출물 (Test implementation work products)
테스트 구현 작업 산출물로는 다음과 같은 것들이 있다:
● 테스트 프로시저와 이 프로시저의 배열
● 테스트 스위트
● 테스트 실행 일정
이상적인 상황에서는 테스트 구현이 끝나면, 테스트 케이스와 테스트 컨디션을 통해 테스트 프로시저와 테스트
베이시스 개별 요소 간의 양방향 추적성을 확인함으로써 테스트 계획에서 정의한 커버리지 조건의 달성 여부를
확인할 수 있다.
테스트 구현이 도구를 사용하거나 도구로 생성되는 작업 산출물을 포함하는 경우도 있다. 예를 들어, 서비스
가상화와 자동 테스트 스크립트가 이런 경우에 해당한다.
테스트 구현의 결과로 테스트 데이터와 테스트 환경을 구현 및 검증할 수도 있다. 데이터나 환경의 검증 결과에
대한 문서의 완성도는 경우에 따라 많이 다를 수 있다.
테스트 데이터는 테스트 케이스의 입력값과 기대 결과값에 확정값을 할당하는 데 사용한다. 해당값의 사용에
대한 세부적인 지침으로 이렇게 확정된 값은 상위 수준 테스트 케이스를 실행 가능한 하위 수준 테스트
케이스로 변화시킨다. 테스트 대상의 다른 릴리스에 대해 같은 상위 수준 테스트 케이스를 실행할 경우 다른
테스트 데이터를 사용할 수 있다. 확정된 테스트 데이터에 대한 확정 기대 결과값은 테스트 오라클(test
oracle)을 통해 식별할 수 있다.
탐색적 테스팅에서는 테스트 실행 중 테스트 설계 및 구현 작업 산출물을 생성할 수 있지만, 탐색적
테스트(테스트 베이시스의 개별 요소로의 추적성 포함) 중 무엇이 문서로 기록되는지는 상황에 따라 상당히
달라질 수 있다.
테스트 분석에서 정의한 테스트 컨디션은 테스트 구현 중 추가로 개선할 수 있다.
테스트 실행 작업 산출물 (Test execution work products)
테스트 실행 작업 산출물에는 다음과 같은 것들이 있다:
● 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서 (예: 실행 준비 완료, 합격, 불합격,
실행하지 못함, 의도적으로 실행하지 않음 등)

● 결함 보고서 (5.6 절 참조)
● 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한 문서
이상적인 상황에서는, 테스트 실행이 끝나면 연관된 테스트 프로시저와의 양방향 추적성을 활용해서 테스트
베이시스 개별 요소의 상태에 대해 판단하고 보고할 수 있다. 예를 들어, 우리는 모든 계획된 테스트에 합격한
요구사항이 무엇인지, 불합격한 테스트나 결함을 가지고 있는 요구사항이 무엇인지, 계획된 것 중 아직
실행하지 못한 테스트를 가지고 있는 요구사항이 무엇인지 얘기할 수 있다. 그 결과로 커버리지 조건 충족
여부를 검증할 수 있으며, 테스트 결과를 이해관계자가 이해할 수 있는 형태로 보고할 수 있다.
테스트 완료 작업 산출물 (Test completion work products)
테스트 완료 작업 산출물로는 테스트 요약 보고서, 차후 프로젝트나 반복주기의 개선을 위한 액션 아이템, 수정
요청서 혹은 제품 백로그 항목, 완성된 테스트웨어 등이 있다.
1.4.4 테스트 베이시스와 테스트 작업 산출물 간의 추적성 (Traceability between the Test Basis and
Test Work Products)
1.4.3 절에서 설명한 바와 같이, 테스트 작업 산출물과 그 작업 산출물의 명칭은 매우 다양하다. 비록 그렇다
하더라도 효과적인 테스트 모니터링과 제어를 구현하기 위해서는 위에서 설명한 바와 같이, 테스트 프로세스
전반에 걸쳐 테스트 베이시스의 개별 요소 및 해당 요소와 연관된 다양한 테스트 작업 산출물 간의 추적성을
확립하고 유지하는 것이 중요하다. 좋은 추적성은 테스트 커버리지에 대한 평가를 가능하게 할 뿐만 아니라
아래와 같은 장점도 제공한다:
● 수정으로 인한 영향 평가를 가능하게 한다.
● 테스팅에 대한 감사(audit)를 가능하게 한다.
● IT 통제(IT governance) 조건을 충족할 수 있게 한다.
● 테스트 베이시스 개별 요소의 상태에 대한 정보(예: 연관된 테스트에 합격한 요구사항, 연관된
테스트에 불합격한 요구사항, 연관된 테스트를 다 실행하지 못한 요구사항)를 포함함으로써 테스트
진행 상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있게 한다.
● 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달한다.
● 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를
제공한다.
테스트 관리 도구 중 이 절에서 다룬 테스트 작업 산출물 일부 또는 전부를 포함한 테스트 작업 산출물 모델을
제공하는 것도 있다. 작업 산출물을 정리하고 필요한 추적성 정보를 제공하기 위해 자체 관리 시스템을
구축하는 조직도 있다.
1.5 테스팅의 심리학 The Psychology of Testing
소프트웨어 테스팅을 포함한 소프트웨어 개발은 사람이 하는 일이다. 따라서, 인간 심리학은 소프트웨어
테스팅에 중요한 영향을 미친다.
1.5.1 인간 심리학과 테스팅 (Human Psychology and Testing)
요구사항 리뷰나 사용자 스토리 개선 세션에서 결함을 식별하거나 동적 테스트 실행 중 장애를 발견하는 것은
테스트 대상 제품과 제작자에 대한 비판으로 오해 받을 소지가 있다. 인간 심리학의 한 요소인 확증
편향(confirmation bias)은 현재 가지고 있는 믿음과 맞지 않는 정보를 받아들이기 어렵게 만들 수 있다. 예를
들어, 개발자는 자신의 코드가 옳다고 생각하기 때문에 코드가 잘못됐다는 사실을 받아들이기 힘들게 하는 확증
편향을 가지고 있다. 확증 편향 외에도 사람들이 테스팅으로 얻은 정보를 이해하고 받아들이기 힘들게 하는
다른 인지 편향(cognitive biases)들도 있다. 또한, 나쁜 소식을 전달하는 사람을 탓하는 것은 인간이 가지고 있는
기본 성향 중 하나인데 테스팅으로 얻은 정보는 나쁜 소식을 포함하고 있는 경우가 많다.
이런 심리학적인 요소로 인해, 테스팅이 프로젝트 진행과 제품 품질에 상당한 기여를 함에도 불구하고 (1.1 절과
1.2 절 참조) 테스팅을 파괴적인 활동으로 간주하는 사람들도 있다. 이런 편견을 줄이기 위해 결함과 장애에
대한 정보는 건설적인 방법으로 전달할 필요가 있다. 그렇게 함으로써 테스터와 분석가, 제품 소유자, 설계자,
개발자 간의 긴장을 완화할 수 있다. 이것은 정적, 동적 테스팅 모두에 해당한다.
테스터와 테스트 관리자는 결함, 장애, 테스트 결과, 테스트 진행 상황, 리스크 등을 효과적으로 전달하기 위해,
또는 동료와 긍정적인 관계를 구축하기 위해 좋은 대인 관계 기술을 가질 필요가 있다. 다음은 의사소통을 더
잘할 수 있는 방법에 대한 예제이다:
● 다툼보다는 협력으로 시작하라. 더 나은 품질의 시스템을 개발한다는 공통 목표를 모두에게
인식시킨다.
● 테스팅의 이점을 강조하라. 예를 들어, 결함 정보는 저자가 자신의 작업 산출물의 품질과 역량을
향상하는 데 도움이 될 수 있다. 조직 차원에서 본다면, 테스팅 도중 발견하고 수정한 결함은 시간과
비용을 아껴주며 제품 품질의 전반적인 리스크를 낮춰준다.
● 테스트 결과와 기타 발견 사항을 중립적이면서 사실에 기반을 둔 방법으로 전달해야 한다. 결함이
발생한 항목을 제작한 사람을 비판해서는 안 된다. 객관적이고 사실에 기반을 둔 결함 보고서와 리뷰
결과서를 작성하라.
● 상대방이 어떤 느낌을 받을지, 또 해당 정보에 대해 부정적으로 반응하는 이유가 뭔지를 이해하려고
해야 한다.
● 상대방이 전달받은 내용을 이해했는지, 또 반대로 상대방이 하고자 하는 말을 제대로 이해했는지
확인하라.
일반적인 테스트 목적은 앞에서 다루었다 (1.1 절 참조). 올바른 테스트 목표 세트를 명확하게 정의하는 것은
심리학적으로도 중요한 영향을 미친다. 대부분의 사람은 자신의 일정과 행동을 팀, 관리자, 기타 이해관계자가설정한 목표와 맞추려는 성향을 가진다. 
테스터도 개인의 성향은 최대한 배제하고 이런 목표와 부합하려고 하는
자세가 매우 중요하다.

1.5.2 테스터와 개발자의 사고방식 (Tester’s and Developer’s Mindsets)
개발자와 테스터는 생각하는 방식이 다른 경우가 많다. 개발의 일차적인 목표는 제품을 설계하고 구축하는
것이다. 앞서 언급한 바와 같이, 테스팅의 목적은 제품에 대한 밸리데이션(확인 validation)과 베리피케이션 (검증
verification), 릴리스 전 결함 발견 등 다양하다. 이처럼 목적이 다르기 때문에 필요한 사고방식도 다르다. 이런
사고방식을 적절히 조합해서 사용하면 더 높은 수준의 제품 품질을 달성할 수 있다.
사고방식은 개인이 가지고 있는 성향과 선호하는 결정 및 문제 해결 방식을 반영한다. 테스터는 호기심, 전문적
비평(professional pessimism) 능력, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적인 의사소통과 관계 수립에
대한 동기 등의 사고방식을 가지고 있어야 한다. 이 테스터의 사고방식은 테스터가 경험을 쌓아감에 따라 점차
확대되고 성숙해지는 경향을 가지고 있다.
개발자의 사고방식에도 테스터의 사고방식과 같은 요소가 일부 있을 수 있지만, 성공적인 개발자는 해결책을
설계하고 구축하는 데 더 관심을 기울이며 그런 해결책에 무슨 문제가 있는지에 대해 관심을 가지는 경우는
많지 않다. 또한, 확증 편향(confirmation bias) 때문에 자신이 만든 오류에 대해 인지하기 어렵다.
올바른 사고방식을 가지고 있다면, 개발자는 자신이 만든 코드를 직접 테스트할 수 있다. 소프트웨어 개발
수명주기 모델에 따라 테스터 구성 및 테스트 활동 방식이 다르다. 테스트 활동의 일부를 독립적인 테스터가
하면 결함 발견 효과를 높일 수 있는데, 이것은 특히 규모가 크고 복잡하며 안전이 필수적인 시스템일 경우
중요하다. 독립적인 테스터는 저자와는 다른 확증 편향을 가지기 때문에 작업 산출물 작성자(즉, 비즈니스
분석가, 제품 오너, 설계자, 개발자 등)와는 다른 관점을 갖게 된다.

 

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."
Posted by 프리스케이터