[1장] 테스팅의 기초 Fundamentals of Testing

용어 (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?

소프트웨어 테스팅은 소프트웨어의 품질을 평가하고, 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다.

테스팅에 대해 많이 오해하는 것 중 하나는 테스팅이 단지 소프트웨어를 실행하고 결과를 확인하는 테스트 수행에 국한된다고 생각하는 것이다. 테스트 프로세스는 테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 및 결과 보고, 테스트 대상 품질 평가 등 많은 활동을 포함한다.

 

테스팅 활동에는 테스트 대상 컴포넌트나 시스템을 실행하는 것도 있다. 이런 테스팅을 동적 테스팅이라 부른다.

반면 테스트 대상 컴포넌트나 시스템을 실행하지 않는 테스팅도 있다. 이런 테스팅은 정적 테스팅이라 부른다.

따라서 요구사항, 사용자 스토리, 소스 코드와 같은 작업 산출물에 대한 리뷰 역시 테스팅에 포함된다.

 

테스팅에 대한 또 다른 오해는 테스팅이 요구사항, 사용자 스토리, 그 외 기타 명세의 베리피케이션(검증 verification)에만 국한된 활동이라는 것이다. 시스템이 주어진 명세를 충족하는지 확인하는 것이 테스팅에 포함되긴 하지만, 시스템이 운영 환경에서 사용자 또는 기타 이해관계자의 요구를 만족시키는지를 확인하는 밸리데이션(확인 validation) 또한 테스팅에 포함된다.

1.1.1 테스팅의 일반적인 목적 (Typical Objective 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.2.2 품질 보증과 테스팅 (Quality Assurance and Testing)

일반적으로 사람들이 품질 보증(QA, Quality Assurance)과 테스팅을 혼용해서 사용하는 경우가 많은데 어느 정도 연관성이 있지만 품질 보증과 테스팅은 다른 개념이다.

둘 다 좀 더 포괄적인 개념인 품질 관리(quality management)에 속한다.

품질 관리는 또한 품질 보증과 품질 제어를 포함한 여러 가지 활동을 포함한다.

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

품질 제어에는 적합한 품질 수준을 달성하기 위한 다양한 활동이 있으며, 테스트 활동도 여기에 포함된다. 테스트 활동은 전반적인 소프트웨어 개발 및 유지보수 프로세스의 일부이다.

품질관리 ⊃ 품질 보증 + 품질 제어 (∋테스트 활동)

1.2.3 오류, 결함, 장애 (Errors, Defects, and Failures)

사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시키는 오류(실수)를 범할 수 있다

장애는 코드 결함뿐만 아니라 환경 조건으로 인해 발생할 수도 있다.

 

테스트 결과가 기대한 것과 다르다고 해서 무조건 장애가 있다고 볼 수는 없다.

거짓음성은 테스트가 발견했어야 할 결함을 발견하지 못하는 경우,

거짓양성은 결함으로 보고됐지만 실제 결함이 아닌 경우를 말한다.

1.2.4 결함, 근본 원인, 결과 (Defects, Root Causes and Effects)

결함의 근본 원인은 해당 결함을 만들어낸 최초의 행동이나 조건을 말한다.

 

예를 들어 :

단 한 줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만을 초래한다. 제품 소유자가 이자 계산법을 잘못 이해해서 작성한 애매모호한 사용자 스토리를 기반으로 코드가 잘못 작성되었다.

대부분의 결함이 이자 계산식에 존재하며 해당 결함들의 근본 원인 역시 비슷한 오해로 인한 것이라면, 차후 유사한 결함의 발생 가능성을 낮추기 위해 제품 소유자에게 이자 계산에 대한 교육을 제공할 수 있다.

 

앞의 예제에서의 결과는 소비자 불만이며 장애는 잘못된 이자 지급이다. 결함은 코드에 포함된 잘못된 계산식이며, 그것의 원인이 되는 최초 결함은 사용자 스토리의 모호성이다. 최초 결함의 근본 원인은 제품 소유자의 지식 부족이었으며, 그 결과로 제품 소유자가 사용자 스토리를 작성할 때 오류를 범했다고 볼 수 있다.

 

근본 원인 분석 프로세스는 ISTQB-CTFL-TM 및 ISTQB-CTFL-ITP 에서 다루고 있다.

1.3 테스팅의 7 가지 원리 Seven Testing Principles

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)
4. 결함은 집중된다
   (Defects cluster together)
5. 살충제 패러독스(pesticide paradox)에 유의하라
   (Beware of the pesticide paradox)
6. 테스팅은 정황(context)에 의존적이다
   (Testing is context dependent)
   테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전 최우선 산업에서 사용하는 제어 소프트웨어는 이커머스 모바일 애플리케이션과는 다르게 테스트한다. 또, 애자일 프로젝트에서의 테스팅은 순차적 소프트웨어 개발 수명주기 프로젝트에서의 테스팅과는 다르게 진행된다 (2.1 절 참조).
7. 오류 부재는 궤변이다
   (Absence-of-errors is a fallacy)

1.4 테스트 프로세스 Test Process

모두가 사용하는 일반적인 테스트 프로시저는 없지만, 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트(sets)는 존재한다. 이런 테스트 활동 세트를 테스트 프로세스라 한다.

1.4.1 정황에 따른 테스트 프로세스 (Test Process in Context)

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

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

다음 절은 아래의 관점에서 조직 테스트 프로세스의 일반적인 요소에 대해 설명하고 있다:

• 테스트 활동과 작업
• 테스트 작업 산출물
• 테스트 베이시스와 테스트 작업 산출물 간의 추적성

테스트 레벨과 유형에 상관없이, 테스트 베이시스에 대한 측정 가능한 커버리지 조건이 설정되어 있으면 매우 유용하다. 커버리지 조건은 소프트웨어 테스트의 목적 달성 여부를 보여주는 활동의 주요 성능 지표(KPI, key performance indicator)로 사용하기 용이하다 (1.1.1 절 참조).

 

※ 테스트 베이시스 란?

테스트 케이스의 기준이 되는 시스템과 컴포넌트의 요구사항을 추론할 수 있는 테스트 케이스의 기반이 되는 모든 문서를 뜻함

1.4.2 테스트 활동과 작업 (Test Activities and Tasks)

테스트 프로세스를 구성하는 주요 활동은 다음과 같다:

• 테스트 계획
• 테스트 모니터링과 제어
• 테스트 분석
• 테스트 설계
• 테스트 구현
• 테스트 실행
• 테스트 완료

이러한 주요 활동들이 대부분 순차적으로 이루어지는 것처럼 보일 수 있으나 반복적으로 구현되는 경우가 많다.

 

테스트 계획 (test planning)

테스트 계획은 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동을 포함한다.

 

테스트 모니터링과 제어 (test monitoring and control)

테스트 모니터링은 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척상황과 지속적으로 비교하는 활동을 말한다.

테스트 제어(test control)는 시간이 지나면서 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행하는 것이다.

종료 조건(exit criteria) 평가도 테스트 모니터링과 제어에 필요한 활동이며, 일부 소프트웨어 개발 수명주기 모델에서는 종료 조건을 완료의 정의(definition of done)로 칭하기도 한다

 

테스트 분석 (Test analysis)

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

즉, 테스트 분석은 측정 가능한 커버리지 조건의 측면에서 "무엇을 테스트할지"를 결정하는 것이다.

테스트 분석의 주요 활동은 다음과 같다

• 고려 중인 테스트 레벨에 적합한 테스트 베이시스 평가
• 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별
• 테스트할 기능과 기능 세트 식별
• 테스트 베이시스를 평가하고 기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정
• 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착 (1.4.3 절, 1.4.4 절 참조)

테스트 설계 (Test design)

테스트 설계에서 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어(testware)를 생성한다. 즉, 테스트 분석은 "무엇을 테스트할 것인가?"라는 질문에 답변하는 반면, 테스트 설계는 "어떻게 테스트할 것인가?"를 다루게 된다.

테스트 설계에 속하는 주요 활동은 다음과 같다:

• 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정
• 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별
• 테스트 환경 설계와 필요한 인프라 및 도구 식별
• 테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정 (1.4.4 절 참조)

테스트 구현 (Test implementation)

테스트 구현 중 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트 프로시저를 만드는 것도 여기에 포함된다. 결국, 테스트 설계는 "어떻게 테스트할 것인가?"라는 질문에 대한 답을 제공하는 반면, 테스트 구현은 "테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?"라는 질문에 답하는 활동이다.

테스트 구현에 속하는 주요 활동은 다음과 같다:

• 테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성
• 테스트 프로시저와 (있다면) 자동 테스트 스크립트로부터 테스트 스위트(test suite) 생성
• 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치 (5.2.4 절 참조)
• 테스트 환경 구축, 가능하다면 테스트 하네스(test harness), 서비스 가상 현실화, 시뮬레이터, 기타
• 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인
• 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인
• 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로 간의 양방향 추적성 검증과 업데이트 (1.4.4 절 참조)

테스트 실행 (Test execution)

테스트 실행 단계에서는 테스트 스위트를 테스트 실행 일정에 따라 실행한다. 테스트 실행의 주요 활동은 다음과 같다:

• 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
• 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
• 기대 결과와 실제 결과 비교
• 이상 현상(anomalies)을 분석해 원인 파악
  (예를 들어, 장애가 코드 결함 때문에 발생할 수도 있지만 거짓양성일 수도 있다 (1.2.3 절 참조))
• 관찰한 장애를 기반으로 결함 보고 (5.6 절 참조)
• 테스트 실행 결과 기록(예:합격,불합격,실행할수없음)
• 이상 현상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복
  (예:수정된 테스트 실행, 확인 테스팅이나 리그레션 테스팅 등)
• 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트

테스트 완료 (Test completion)

테스트 완료 활동은 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동이다. 테스트 완료 활동은 소프트웨어 시스템을 릴리스 했을 때, 테스트 프로젝트를 완료(또는 취소)했을 때, 애자일 반복주기가 끝났을 때, 특정 테스트 레벨을 완료했을 때, 또는 유지보수 릴리스를 완료했을 때와 같은 프로젝트 마일스톤 시점에서 일어난다.

테스트 완료의 주요 활동은 다음과 같다:

• 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인
• 이해관계자에게 전달할 테스트 요약 보고서 생성
• 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관
• 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계
• 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리스, 또는 프로젝트를 위해
• 수정해야 하는 사항 판단
• 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용

1.4.3 테스트 작업 산출물 (Test Work Products)

테스트 작업 산출물은 테스트 프로세스의 일부로 생성된다. 조직마다 테스트 프로세스를 구현하는 방법이 다르듯이, 테스트 프로세스 중 생성되는 작업 산출물의 유형, 이 작업 산출물을 정리하고 관리하는 방법과 부르는 명칭 또한 다양하다.

• 테스트 계획 작업 산출물 (Testing 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)

테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소 및 해당 요소와 연관된 다양한 테스트 작업 산출물 간의 추적성을 확립하고 유지하는 것이 중요하다. 좋은 추적성은 테스트 커버리지에 대한 평가를 가능하게 할 뿐만 아니라 아래와 같은 장점도 제공한다:

• 수정으로 인한 영향 평가를 가능하게 한다.
• 테스팅에 대한 감사(audit)를 가능하게 한다.
• IT 통제(IT governance) 조건을 충족할 수 있게 한다.
• 테스트 베이시스 개별 요소의 상태에 대한 정보(예: 연관된 테스트에 합격한 요구사항, 연관된 테스트에 불합격한 요구사항, 연관된 테스트를 다 실행하지 못한 요구사항)를 포함함으로써 테스트
• 진행 상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있게 한다.
• 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달한다.
• 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.

1.5 테스팅의 심리학 The Psychology of Testing

1.5.1 인간 심리학과 테스팅 (Human Psychology and Testing)

요구사항 리뷰나 사용자 스토리 개선 세션에서 결함을 식별하거나 동적 테스트 실행 중 장애를 발견하는 것은 테스트 대상 제품과 제작자에 대한 비판으로 오해 받을 소지가 있다. 나쁜 소식을 전달하는 사람을 탓하는 것은 인간이 가지고 있는 기본 성향 중 하나인데 테스팅으로 얻은 정보는 나쁜 소식을 포함하고 있는 경우가 많다. 테스터와 테스트 관리자는 결함, 장애, 테스트 결과, 테스트 진행 상황, 리스크 등을 효과적으로 전달하기 위해, 또는 동료와 긍정적인 관계를 구축하기 위해 좋은 대인 관계 기술을 가질 필요가 있다.

 

[참고 문헌]

ISTQB_CTFL_파운데이션레벨(FL)_v.2018_실러버스_v3.1.1_한글_v1.0