ISTQB_CTFL 1. 소프트웨어 테스팅의 기초

서론

1장의 핵심 학습 목표는 "소프트웨어 테스팅이 왜 필요한 지 설명할 수 있으며, 품질 보증과 오류 및 결함의 의미에 대해 알아야 한다. 또한 테스팅의 목적과 일반적인 원리를 설명할 수 있어야 하며, 개발 전반에 걸친 각 테스트 활동의 주요 업무를 이해해야 한다. 마지막으로 테스팅의 심리적 요인을 이해해야 한다."이다. 이를 기억하고 내용을 이해해 보자.

배우기에 앞서 용어 정리

용어를 확실하게 아는 것이 이해에 도움이 된다. ISTQB가 개발자뿐만 아니라 다른 직군도 시험을 충분히 볼 수 있기에 이해하기 쉽게 용어의 정의를 살펴보자.

테스팅: 소프트웨어 제품과 관련 직업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스.
오류(Error): 부정확한 결과를 초래하는 인간의 활동.
장애(Failure): 컴포턴트나 시스템이 예상된 인도(delivery)나 서비스 또는 예상 결과와 실제적인 편차를 보이는 것.
결함: 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점, 결함의 예는 부정확한 구문이나 부정확한 데이터 정의 등이 있다. 실행 중에 결함이 발생한 경우, 컴포넌트나 시스템의 장애를 야기실킬 수 있다.
결점: 결함과 같은 의미이다.
리스크(Risk): 미래에 부정적 결과로 끝날 수 있는 요소.(영향력(impact)이나 발생가능성(likehood)으로 표현됨)
디버깅(Debug): 소프트웨어에서 장애의 원인을 발견하고, 분석하여 제거하는 절차.
커버리지(Coverage): 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도.
테스트 스위트(Test Suite): 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트 케이스의 집합.
살충제 패러독스(Pesticide paradox): "같은 테스트 케이스를 가지고, 테스트를 계속해서 반복하는 경우 어느 시점부터는 더 이상 결함을 발견하지 못한다. "라는 이론.
테스트 베이시스(Test Basis): 요구사항을 내포하고 있는 모든 문서.
테스트 프로세스: 기본적인 테스트 프로세스는 테스트 기획, 명세, 실행, 기록 그리고 완료 여부의 점검으로 구성된다.
테스트 오라클(test oracle): 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거.
독립성: 객관적인 테스팅을 완수하기 위한 책임의 분리.
인스펙션: 개발 표준 위반과 상위 레벨 개발 문서와의 불일치 등과 같은 결함을 발견하기 위해 문서를 눈으로 검사하는 리뷰의 한 종류.
ROI(Return On Investment): 지출 대비 수익률.
컴포넌트: 독립적으로 테스트될 수 있는 최소 소프트웨어 항목.
추적성(traceability): 요구사항과 이와 연관된 테스트에서와 같이 문서나 소프트웨어에서 연관된 항목을 식별하는 능력.
밸리데이션(확인, validation): 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.
베리피케이션(검증, verification): 명세된 요구사항이 충족되었는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.

소프트웨어 테스팅이 왜 필요한가?

필요성

소프트웨어 시스템은 광범위한 부분에서 사용되고 있으며 그 비중은 나날이 증가하고 있다. 소프트웨어가 올바르게 작동하지 않거나 사람들의 기대와 다른 동작을 하는 경우로 여러 문제가 생긴다. 예를 들어 금전적 손실, 시간 낭비, 비즈니스 이미지 손상, 익명 피해 등이 있다. 이러한 소프트웨어 시스템의 문제를 최소화하기 위해 반드시 테스팅이 필요하다.

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

테스팅은 결함을 식별하는 비용 효율적인 방법이다. 식별한 결함은(테스팅 활동이 아닌 디버깅을 통해) 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여하게 된다.

테스팅은 소프트웨어 개발수명주기(SDLC)의 여러 단계에서 테스트 대상의 품질을 직접 평가하는 방법을 제공한다. 이런 평가결과는 대규모 프로젝트 관리 활동에서 릴리스 여부의 판단과 같은, 소프트웨어 개 발수명주기(SDLC) 다음 단계로의 이동여부 결정에 기여하게 된다.

소프트웨어 결함의 원인

개발자는 코드를 쓰거나 소프트웨어나 시스템 또는 문서를 작성할 때 결함(결점, 버그, Default, Bug)을 만드는 오류(실수, Error)를 범할 수 있다. 코드에 존재하는 결함은 장애(Failure)의 원인이 된다. 주의할 점으로는 결함은 장애의 원인이 되지만, 모든 결함이 장애를 일으키는 것은 아니다.

결함은 인간이 오류를 범하기 쉽기 때문에 발생한다. 장애는 이와 같은 결함에 의해서뿐만 아니라 환경적인 조건에 의해서도 발생한다. 대표적인 오류 발생 원인은 다음과 같다.

시간적인 압박
사람의 실수
경험이 적거나 기술이 부족한 프로젝트 참여자
요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제
코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도
시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우
새롭고 익숙하지 않은 기술

소프트웨어의 개발, 유지보수, 운영 시 테스팅의 역할

소프트웨어 개발 과정에서는 테스팅이 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석을 통해 정적으로 시작될 수 있으며 각각의 개발 단계에 대응하는 테스트 레벨(Test level)에 따른 테스팅이 이루어진다. 컴포넌트(단위) 테스팅과 통합 테스팅은 개발조직이 중심이 되어 수행되고, 시스템이 갖춰진 이후의 테스팅은 개발조직의 지원을 받아 독립성을 가진 테스트 조직을 중심으로 수행하는 것이 바람직하다. 최종 소프트웨어 사용자가 인수하는 과정에서의 테스팅도 전체 개발 과정에서의 한 가지 테스팅이다. 이와 같이 테스트 레벨에 따른 테스팅은 개발과정에서 소프트웨어의 품질을 높이고 소프트웨어가 고객에게 전달된 이후 결함이 발생할 가능성을 최소화한다. 이 외에도 소프트웨어 테스팅은 계약적(법적) 요구조건들 또는 산업에 특화된 표준들을 만족시키기 위해서도 필요하다.

테스팅과 품질

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

테스팅을 통해 발견한 결함(데이터)에 근거하여 대상 소프트웨어의 기능 또는 비기능적 요구사항과 품질특성(가능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등) 관련 품질 측정이 가능하다. 테스팅으로 발견된 결함이 극소수이거나 없다면 테스트 설계 및 실행이 정상적으로 진행되었다는 전제하에 소프트웨어의 품질에 대한 확신(Confidence)을 가질 수 있다. 올바르게 설계된 테스팅은 시스템의 전반적인 리스크 수준을 감소시킨다. 테스팅이 결함을 찾아내고, 발견된 결함이 수정될 때 소프트웨어 시스템의 품질은 향상된다.

품질 보증의 한 가지 관점에서 볼 때, 품질을 높이기 위해서는 이전 프로젝트를 통해 많은 테스트 경험과 정보를 확보하여야 한다. 다른 프로젝트에서 발견된 결함의 근본 원인에 대한 이해를 바탕으로 프로세스를 개선할 수 있으며, 그러한 결함의 재발을 방지함으로써, 결과적으로 차후 시스템의 품질을 개선할 수 있다.

테스팅, 얼마나?

적절한 테스팅의 정도를 파악하기 위해서는 리스크(Risk) 수준과 제약 사항을 고려해야 한다.

테스팅이란 무엇인가?

테스팅이란 응용 프로그램 또는 시스템(구성요소를 포함해서)의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘이다. 과거에는 응용 프로그램 또는 시스템의 정상 작동 여부 확인하는 개념이었지만, 현재의 테스팅은 사용자의 기대 수준과 요구 사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고, 최종적으로 결함 데이터를 근간으로 개발 프로젝트의 리스크 정보를 정략적 수치로 의사결정권자에게 전달하는 것이다.

테스팅의 일반적인 목적

테스팅은 다양한 목적으로 테스트를 실행하지만, 일반적으로 남아있는 결함 발견, 명세 충족 확인, 사용자 및 비즈니스의 요구 충족 확인, 결함 예방하는 목적(+ 품질 수준에 대한 자신감 획득과 정보 제공, 비즈니스 리스크를 감소시키는 정보에 근거한 조언 제공, 개발 프로세스 점검 및 이슈 제기)을 가지고 있다. 자세히 살펴보자면, 아래와 같다.

요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
명시된 모든 요구사항이 충족됐는지 검증
테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
테스트 대상의 품질 수준에 대한 자신감 획득
부적절한 소프트웨어 품질의 리스크 레벨 감소로 장애와 결함을 발견
이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
계약/법률/규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인

또한 목적이 정황에 따라 달라진다.

소프트웨어의 품질을 평가하기 위한 테스팅은 특정 시간에 시스템을 출시(Release)하는 것의 리스크를 개발 프로젝트 관련자(Stakeholders)에게 전달하는 것이다.
테스팅(컴포넌트, 통합, 시스템 테스팅)의 목적 중 하나는 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고 수정하는 것일 수 있다. 또 다른 목적은 코드 커버리지를 높이는 것일 수도 있다.
인수 테스팅의 주요 목적 중 하나는 시스템이 기대한 대로 동작하는지, 또 요구사항을 충족하는지 확인하는 것일 수 있다. 또 다른 목적은 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공하는 것일 수 있다.
유지보수 테스팅은 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하는 리그레션 ㅇ테스팅(Regression testing) 과정을 포함한다.
운영 테스팅 기간의 주요한 목적은 신뢰성 또는 가용성과 같은 시스템의 특성을 평가하는 것일 수 있다.

테스트와 디버깅

테스팅과 디버깅은 다르다. 테스트를 실행하면 소프트웨어 결함으로 인한 장애를 찾아낼 수 있으며, 그런 장애의 원인을 찾고 분석해서 수정하는 개발 활동이다. 이때 결함을 발견하기 위한 활동이 테스팅이며, 결함의 원인을 밝히고 코드를 수정하는 활동이 디버깅이다.

테스팅의 7가지 원리

1 - 테스팅은 결함이 존재함을 밝히는 활동이다.

테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수 없다. 테스팅은 소프트웨어에 발견되지 않은 결함의 존재 가능성을 줄일 수는 있지만, 결함이 전혀 발견되지 않았다 하더라도 해당 소프트웨어가 완벽하다는 뜻은 아니다.

2 - 완벽한 테스팅은 불가능하다.

모든 것(입력과 사전 조건의 모든 조합)을 테스팅한다는 것은 매우 간단한 소프트웨어를 제외하고는 불가능하다. 완벽한 테스팅이 불가능한 이유로는 무한 경로, 무한 입력값, 무한 타이밍 등 경우의 수가 무한의 가깝기 때문이다. 따라서, 완벽하게 테스트하고자 하기보다는 리스크 분석과 우선순위를 토대로 한 테스트에 노력을 집중하는 것이 좋다.

3 - 테스팅을 개발 초기에 시작한다.

초기에 결함을 찾기 위해서는 정적 및 동적 테스트 활동 모두 소프트웨어 개발 수명주기 중 가능한 이른 시점에 시작해야 한다. 초기부터 시작하는 테스팅을 시프트 레프트(shift left)라고도 부른다. 소프트웨어 수명주기 초기부터 테스팅을 함으로써 나중에 큰 비용이 동반되는 수정을 줄이거나 없앨 수 있다.

4 - 결함 집중

출시 전 테스팅에서 발견하는 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보이며, 운영상 장애의 대부분 역시 소수의 모듈에서 발생한다. 예상 결함 집중 영역과 테스트와 운영 중 실제로 관측한 결함 집중 영역은 리스크 분석의 주요 입력값으로 사용된다. 리스크 분석은 테스트 노력을 집중시키는 데 필요하다. 일반적으로 결함이 집중될 수 있는 모듈은 다음과 같다.

자체적으로 복잡한 구조를 가지고 있는 모듈
소프트웨어나 시스템의 다른 부분 또는 다른 모듈과 다량의 복잡한 상호 작용을 하는 모듈(복잡한 인터페이스)
개발 난이도가 높거나 최신 기술을 사용한 모듈
크기가 큰 모듈
경험이 미흡한 개발팀에서 개발한 모듈

5 - 살충제 패러독스

만일 같은 테스트를 계속해서 반복 실행한다면, 결국 해당 테스트로는 결함을 더 이상 발견할 수 없게 된다. 새로운 결함을 발견하기 위해서는 기존 테스트와 테스트 데이터를 바꾸고 새로운 테스트를 작성할 필요가 있다. 그러나 살충제를 계속 사용하다 보면 결국 해충을 잡지 못하는 경우가 있듯, 테스트도 반복하다 보면 결국 결함을 더 이상 찾지 못하고 넘어가는 겨우도 있다. 자동 리그레션 테스팅의 경우 리그레션 결함이 적다는 것을 의미할 수도 있다.

6 - 테스팅은 정황에 의존적

테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전 최우선 산업에서 사용하는 제어 소프트웨어는 이커머스 모바일 애플리케이션과는 다르게 테스트한다. 또, 애자일 프로젝트에서의 테스팅은 순차적 소프트웨어 개발 수명주기 프로젝트에서의 테스팅과는 다르게 진행된다.

7 - 오류 부재는 궤변

개발된 시스템이 사용자의 필요와 기대의 부응하지 못하고 사용성이 현저히 낮가면 아무리 결함을 찾고 수정하더라도 아무 소용이 없다. 즉, 사용자 또는 비즈니스의 요구를 충족시켜주지 못한다면, 설사 결함을 모두 발견하여 제거하였다고 하더라도 품질이 높다고 할 수 있다. 그렇기에 단순히 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 궤변(즉, 잘못된 믿음)이다.

테스트 프로세스의 기초

모두가 사용하는 일반적인 테스트 프로시저는 없지만, 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트(sets)는 존재한다. 이런 테스트 활동 세트를 테스트 프로세스라 한다. 주어진 상황에 맞는 구체적인 소프트웨어 테스트 프로세스는 다양한 변수에 따라 결정된다

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

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

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

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

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

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

테스트 활동과 작업

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

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

각 구성 활동은 다시 다수의 개별 작업으로 나눠지며 프로젝트마다 또는 릴리즈마다 달라질 수 있다. 또한, 이러한 주요 활동들이 대부분 순차적으로 이루어지는 것처럼 보일 수 있으나 반복적으로 구현되는 경우가 많다.(예. 에자일 개발) 따라서, 순차적 소프트웨어 개발에서도 개별 활동의 논리적인 순서는 중첩(overlap), 조합(combination), 동시 실행(concurrency) 되거나 누락되기 때문에 시스템과 프로젝트의 정황에 따라 이런 주요 활동들을 어느 정도 조정하는 것이 필요하다.

테스트 계획

테스트 계획은 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동을 포함한다. 또한 테스트 설계 및 구현의 기반이 되는 테스트 베이시스는 테스트 계획 단계에서부터 필요하고 설계 시에는 반드시 필요하다. 이 과정은 모니터링과 제어 활동에서 나온 피드백을 기반으로 수정할 수 있다.

테스트 계획 수립 관련 주요 작업은 다음과 같다.

테스트 범위(scope)와 테스트를 위한 리스크에 대한 결정, 그리고 테스팅의 목적에 대한 식별
- 테스트 범위: 다른 시스템과의 인터페이스 정도, 관련 품질 특성, 호환성(Compatibility) 테스팅 범위, 커버하고자 하는 테스트 레벨 등
- 리스크 기반 테스트 전략: 각각의 테스트 레벨에 대해 테스트 대상 제품이 충족해야 할 품질 수준 및 특성과 기술적 어려움, 비즈니스 리스크를 고려한 테스트 전략 수립
- 테스팅의 목적: 품질 요구 수준, 테스트 레벨 별 목적, 커버하고자 하는 품질 특성 등
테스트 정책의 실현과 테스트 전략의 구현
테스트 접근 방법에 대한 결정
테스트에 필요한 리소스 결정
테스트 분석과 설계 작업의 일정관리
테스트 구현, 실행 및 평가의 일정관리
테스트 완료 조건의 결정

테스트 모니터링과 제어

테스트 모니터링은 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동을 말한다. 테스트 제어(test control)는 시간이 지나면서 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행하는 것이다. 종료 조건(exit criteria) 평가도 테스트 모니터링과 제어에 필요한 활동이며, 일부 소프트웨어 개발 수명주기 모델에서는 종료 조건을 완료의 정의(definition of done)로 칭하기도 한다.

테스트 제어의 주요한 작업은 아래와 같다.

테스트 결과에 대한 측정과 분석
테스트 진척 사항, 테스트 커버리지와 완료 조건의 모니터링과 문서화
테스트 계획과의 차이를 교정하는 활동
테스팅의 진행과 변경에 대한 의사 결정 활동

테스트 실행의 종료 조건 평가는 다음을 포함할 수 있다.

명시된 커버리지 조건 대비 테스트 결과와 로그 확인
테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가
추가 테스트 필요 여부 결정

테스트 분석

테스트 분석에서는 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석한다. 즉, 테스트 분석은 측정 가능한 커버리지 조건의 측면에서 "무엇을 테스트할지"를 결정하는 것이다.

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

고려 중인 테스트 레벨에 적합한 테스트 베이시스 평가.
- 요구사항 명세. 여기에 포함되는 것으로는 비즈니스 요구사항, 기능 요구사항, 시스템 요구사항, 사용자 스토리, 에픽(epic), 유스케이스, 요구되는 기능/비기능 컴포넌트나 시스템의 동작이 명시된 유사한 작업 산출물 등이 있다.
- 설계와 구현 정보. 여기에 포함되는 것으로는 시스템이나 소프트웨어 아키텍처 다이어그램 또는 문서, 설계 명세, 콜흐름도(call flow graphs), 모델링 다이어그램, 인터페이스 명세, 컴포넌트나 시스템 구조를 명시하고 있는 기타 유사한 작업 산출물 등이 있다.
- 구현한 컴포넌트나 시스템. 여기에 포함되는 것으로는 코드, 데이터베이스 메타데이터(database metadata), 쿼리(queries), 인터페이스 등이 있다.
- 컴포넌트나 시스템의 기능, 비기능, 구조 측면을 고려한 리스크 분석 보고서
테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별.
- 모호함 (Ambiguities)
- 누락 (Omissions)
- 불일치 (Inconsistencies)
- 부정확 (Inaccuracies)
- 모순 (Contradictions)
- 불필요한 구문 (Superfluous Statements)
테스트할 기능과 기능 세트 식별
테스트 베이시스를 평가하고 기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정
테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착

테스트 분석의 결과로 테스트 차터(test charter)의 테스트 목적으로 사용할 테스트 컨디션이 생성되는 경우도 있다. 테스트 차터는 일부 경험 기반 테스팅 유형에서 일반적으로 사용하는 작업 산출물이다. 테스트 목적과 테스트 베이시스 간의 추적성을 확인할 수 있는 경우, 이런 경험 기반 테스팅으로 달성하는 커버리지를 측정할 수 있다.

테스트 분석 중 결함 식별은 큰 잠재적 이점이다. 특히, 사용하는 리뷰 프로세스가 없거나 테스트 프로세스가 리뷰 프로세스와 밀접하게 연관된 경우 더 그렇다. 이런 테스트 분석 활동은 요구사항이 일관성 있게 제대로 설명되고 완성되었는지 검증할 뿐 아니라, 요구사항이 고객, 사용자, 기타 이해관계자의 요구를 제대로 반영하고 있는지 확인하게 해 준다.

테스트 설계

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

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

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

테스트 설계 중 테스트 컨디션을 테스트 케이스와 테스트 케이스 세트로 전환할 때 테스트 기법을 사용하는 경우가 많다. 테스트 분석과 마찬가지로, 테스트 설계에서도 테스트 베이시스에서 유사한 유형의 결함을 식별할 수 있다. 또한, 테스트 설계 중 결함 식별은 테스트 분석에서와 마찬가지로 큰 잠재적 이점이다.

즉, 테스트 분석과 설계는 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동이다.

테스트 구현

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

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

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

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

테스트 실행

테스트 실행 단계에서는 테스트 스위트를 테스트 실행 일정에 따라 실행한다.

테스트 실행의 주요 활동은 다음과 같다.

테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
기대 결과와 실제 결과 비교
이상 현상(anomalies)을 분석해 원인 파악
- 테스트 케이스 결함
- 테스트 정황 결함
- 어플리케이션 결함
- 어플리케이션 정황 결함
관찰한 장애를 기반으로 결함 보고
테스트 실행 결과 기록
이상 현상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복
테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트

테스트 실행 중 발견할 수 있는 결함은 개발 프로세스 및 품질 보증 절차를 개선하기 위해 유형별로 분류가 가능하다. 분류 가능한 결함 유형은 다음과 같다.

기획 시 유입된 결함
설계 시 유입된 결함
코딩 시 유입된 결함
테스트 부족으로 유입된 결함
마무리 부족
팀 간 의사소통 부족
코딩 실수

만일 결함 분석 결과 "마무리 부족으로 유입된 결함" 유형이 상대적으로 많다면 개발 과정에서 마무리하는 절차를 별도로 가져가거나 품질 보증자가 마무리가 제대로 되도록 감시하는 활동을 강화하는 등의 개발 프로세스 개선을 고려할 수 있다.

결함을 유형별로 분류하는 것 외에도 결함 심각도(Severity level) 별로 분류하여 관리해야 한다. 이때 결함의 심각도를 정확하게 전달하는 것이 중요하다. 아래는 결함 심각도 구분 기준 예이다.

치명적 결함(Critical Defects)
- 하드웨어 또는 소프트웨어 장애, 시스템 중지, 시스템 잠김(접근 불가), 데이터 손실 또는 변조
주요 결함(Major Defects)
- 기능 손실, 잘못된 기능, 주요 기능 오작동
일반 결함(Average Defects)
- 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스
사소한 결함(Minor Defects)
- 타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스
개선 사항(Enhancement)
- 에러는 아니지만 개선이 필요한 사항

명확하게 결함의 심가도를 구분할 경우 개발자가 처리해야 할 결함의 우선순위를 판단하는 좋은 근거가 된다. 그러나 결함 심각도와 처리해야 할 결함 우선순위(Defects priority)를 별도로 구분해야 한다. 즉, 모든 경우 결함 심각도가 가장 높다고 해서 가장 먼저 그 결함을 수정해야 하는 것은 아니다. 아래는 결함 우선순위를 표현한 예이다.

즉시 해결(Resolve immediately)
주의 요망(Give high attention)
대기(Normal queue)
낮은 순위(Low priority)

테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포한하는 테스트 프로시저 또는 테스트 스크립트를 명세화하는 활동이다.

테스트 완료(마감)

테스트 완료 활동은 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동이다. 테스팅이 얼마나 체계적으로 수행되었는지 평가하고 향후 테스팅을 개선하기 위해 모범 사례를 모델로 테스트 프로세스를 평가하는 것 또한 테스트 마감 활동의 중요한 부분이다. 테스트 완료 활동은 소프트웨어 시스템을 릴리스 했을 때, 테스트 프로젝트를 완료(또는 취소)했을 때, 애자일 반복주기가 끝났을 때, 특정 테스트 레벨을 완료했을 때, 또는 유지보수 릴리스를 완료했을 때와 같은 프로젝트 마일스톤 시점에서 일어난다.

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

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

리포팅은 진행보고와 릴리즈 조언 및 최종보고 형태로 이루어지며 테스팅을 수행하면서 수집한 결함 및 테스트 진행 관련 데이터를 가공하여 메트릭(Metrics)으로 수치화하고 관련 정보를 표현하는 작업이다.

리포팅에 표현되는 내용은 다음과 같다.

테스트 진척도
리스크 및 메트릭으로 실증된 조언
테스트 환경의 가용성
테스트 커버리지, 결함 발견 효과성/효율성, 품질 평가 결과, 결함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수, 요구사항 별 테스트 일 수, 해결되지 않은 결함과 그 영향, 오랫동안 수정되지 않은 결함 분석 등

테스트 작업 산출물

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

테스트 계획 작업 산출물

테스트 계획 작업 산출물에는 일반적으로 하나 이상의 테스트 계획이 포함된다. 테스트 계획은 테스트 베이시스에 대한 정보를 포함한다. 테스트 베이시스는 추적성 정보를 통해 다른 작업 산출물뿐만 아니라, 테스트 모니터링과 제어에 사용되는 종료 조건(또는 완료 기준)과도 연결된다.

테스트 모니터링과 제어 작업 산출물

테스트 모니터링과 제어 작업 산출물은 보통 지속적, 정기적으로 생성되는 테스트 진행 현황 보고서와 다양한 테스트 완료 마일스톤에서 생성되는 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서를 포함한다. 모든 테스트 보고서는 작성일 기준 테스트 진행 상황 관련 필요한 정보를 독자에게 제공해야 한다. 테스트 실행 결과가 나오면 그것에 대한 요약도 포함해야 한다. 테스트 모니터링과 제어 작업 산출물은 작업 완료, 리소스 할당과 사용, 공수 등과 같이 프로젝트 관리에서 관심을 가지는 사항에 대해서도 다루어야 한다.

테스트 분석 작업 산출물

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

테스트 설계 작업 산출물

테스트 설계의 결과로 테스트 분석에서 정의한 테스트 컨디션을 실행할 수 있는 테스트 케이스와 테스트 케이스 세트가 만들어진다. 입력 데이터와 기대 결과로 사용할 값이 고정되지 않은 상위 수준 테스트 케이스를 먼저 설계하는 것이 좋은 경우가 많다. 이런 상위 수준 테스트 케이스는 입력 데이터와 기대 결괏값을 바꿔가면서 다양한 테스트 주기에서 재활용할 수 있으며, 동시에 테스트 케이스의 범위를 충분히 기록할 수 있게 해 준다. 이상적으로는 각각의 테스트 케이스와 그것이 커버하는 테스트 컨디션 간의 양방향 추적성이 성립되어 있어야 한다.

테스트 설계는 또한 다음과 같은 결과를 가져온다.

필요한 테스트 데이터의 설계나 식별
테스트 환경 설계
인프라와 도구의 식별

그러나 이런 결과를 문서로 기록하는 정도의 차이는 상당히 큰 편이다.

테스트 구현 작업 산출물

테스트 구현 작업 산출물로는 다음과 같은 것들이 있다.

테스트 프로시저와 이 프로시저의 배열
테스트 스위트
테스트 실행 일정

이상적인 상황에서는 테스트 구현이 끝나면, 테스트 케이스와 테스트 컨디션을 통해 테스트 프로시저와 테스트 베이시스 개별 요소 간의 양방향 추적성을 확인함으로써 테스트 계획에서 정의한 커버리지 조건의 달성 여부를 확인할 수 있다. 테스트 구현이 도구를 사용하거나 도구로 생성되는 작업 산출물을 포함하는 경우도 있다. 테스트 구현의 결과로 테스트 데이터와 테스트 환경을 구현 및 검증할 수도 있다. 데이터나 환경의 검증 결과에 대한 문서의 완성도는 경우에 따라 많이 다를 수 있다.

테스트 데이터는 테스트 케이스의 입력값과 기대 결과값에 확정값을 할당하는 데 사용한다. 테스트 대상의 다른 릴리스에 대해 같은 상위 수준 테스트 케이스를 실행할 경우 다른 테스트 데이터를 사용할 수 있다. 확정된 테스트 데이터에 대한 확정 기대 결과값은 테스트 오라클(test oracle)을 통해 식별할 수 있다.

탐색적 테스팅에서는 테스트 실행 중 테스트 설계 및 구현 작업 산출물을 생성할 수 있지만, 탐색적 테스트(테스트 베이시스의 개별 요소로의 추적성 포함) 중 무엇이 문서로 기록되는지는 상황에 따라 상당히 달라질 수 있다. 테스트 분석에서 정의한 테스트 컨디션은 테스트 구현 중 추가로 개선할 수 있다.

테스트 실행 작업 산출물

테스트 실행 작업 산출물에는 다음과 같은 것들이 있다.

개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서
결함 보고서
테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한 문서

이상적인 상황에서는, 테스트 실행이 끝나면 연관된 테스트 프로시저와의 양방향 추적성을 활용해서 테스트 베이시스 개별 요소의 상태에 대해 판단하고 보고할 수 있다.

테스트 완료 작업 산출물

테스트 완료 작업 산출물로는 테스트 요약 보고서, 차후 프로젝트나 반복주기의 개선을 위한 액션 아이템, 수정 요청서 혹은 제품 백로그 항목, 완성된 테스트웨어 등이 있다.

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

테스트 작업 산출물과 그 작업 산출물의 명칭은 매우 다양하다. 비록 그렇다 하더라도 효과적인 테스트 모니터링과 제어를 구현하기 위해서는 위에서 설명한 바와 같이, 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소 및 해당 요소와 연관된 다양한 테스트 작업 산출물 간의 추적성을 확립하고 유지하는 것이 중요하다. 좋은 추적성은 테스트 커버리지에 대한 평가를 가능하게 할 뿐만 아니라 아래와 같은 장점도 제공한다.

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

테스팅의 심리학

인간 심리학과 테스팅

요구사항 리뷰나 사용자 스토리 개선 세션에서 결함을 식별하거나 동적 테스트 실행 중 장애를 발견하는 것은 테스트 대상 제품과 제작자에 대한 비판으로 오해받을 소지가 있다. 인간 심리학의 한 요소인 확증 편향(confirmation bias)은 현재 가지고 있는 믿음과 맞지 않는 정보를 받아들이기 어렵게 만들 수 있다. 또한, 나쁜 소식을 전달하는 사람을 탓하는 것은 인간이 가지고 있는 기본 성향 중 하나인데 테스팅으로 얻은 정보는 나쁜 소식을 포함하고 있는 경우가 많다. 이런 심리학적인 요소로 인해, 테스팅이 프로젝트 진행과 제품 품질에 상당한 기여를 함에도 불구하고 테스팅을 파괴적인 활동으로 간주하는 사람들도 있다. 이런 편견을 줄이기 위해 결함과 장애에 대한 정보는 건설적인 방법으로 전달할 필요가 있다. 그렇기에 테스터는 다음과 같은 의사소통 방식을 권장하고 있다.

다툼보다는 협력으로 시작하라. 더 나은 품질의 시스템을 개발한다는 공통 목표를 모두에게 인식시킨다.
소프트웨어를 개발한 "사람"에 대한 비평을 배제하고, 중립적이고 사실에 근거한 제품의 결함만을 전달하려고 노력한다.
테스팅의 이점을 강조하라.
테스트 결과와 기타 발견 사항을 중립적이면서 사실에 기반을 둔 방법으로 전달해야 한다. 결함이 발생한 항목을 제작한 사람을 비판해서는 안 된다. 객관적이고 사실에 기반을 둔 결함 보고서와 리뷰 결과서를 작성하라.
상대방이 어떤 느낌을 받을지, 또 해당 정보에 대해 부정적으로 반응하는 이유가 뭔지를 이해하려고 해야 한다.
상대방이 전달받은 내용을 이해했는지, 또 반대로 상대방이 하고자 하는 말을 제대로 이해했는지 확인하라.

테스터와 개발자의 사고방식

개발자와 테스터는 생각하는 방식이 다른 경우가 많다. 개발의 일차적인 목표는 제품을 설계하고 구축하는 것이다. 앞서 언급한 바와 같이, 테스팅의 목적은 제품에 대한 밸리데이션과 베리피케이션, 릴리스 전 결함 발견 등 다양하다. 이처럼 목적이 다르기 때문에 필요한 사고방식도 다르다.

테스터는 호기심, 전문적 비평(professional pessimism) 능력, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적인 의사소통과 관계 수립에 대한 동기 등의 사고방식을 가지고 있어야 한다. 이 테스터의 사고방식은 테스터가 경험을 쌓아감에 따라 점차 확대되고 성숙해지는 경향을 가지고 있다.

개발자의 사고방식에도 테스터의 사고방식과 같은 요소가 일부 있을 수 있지만, 성공적인 개발자는 해결책을 설계하고 구축하는 데 더 관심을 기울이며 그런 해결책에 무슨 문제가 있는지에 대해 관심을 가지는 경우는 많지 않다. 또한, 확증 편향(confirmation bias) 때문에 자신이 만든 오류에 대해 인지하기 어렵다.

올바른 사고방식을 가지고 있다면, 개발자는 자신이 만든 코드를 직접 테스트할 수 있다. 소프트웨어 개발 수명주기 모델에 따라 테스터 구성 및 테스트 활동 방식이 다르다. 테스트 활동의 일부를 독립적인 테스터가 하면 결함 발견 효과를 높일 수 있는데, 이것은 특히 규모가 크고 복잡하며 안전이 필수적인 시스템일 경우 중요하다. 독립적인 테스터는 저자와는 다른 확증 편향을 가지기 때문에 작업 산출물 작성자(즉, 비즈니스 분석가, 제품 책임자, 설계자, 개발자 등)와는 다른 관점을 갖게 된다.

소프트웨어 테스팅을 제약하는 요소

전체 개발비의 40~60%는 소프트웨어 테스팅 비용에 소요된다는 것과 테스팅이 중요하다는 것은 잘 알려진 사실이다. 그러나 개발 관련자들은 고정 업무만으로도 버거워 테스팅에는 시간과 관심을 크게 두지 못하는 것이 현실이다. 그렇기에 이를 방치하면 심각할 경우, 개발비용보다 유지보수 비용이 더 많이 소요되는 상황이 다수 발생한다. 그렇기에 프로젝트가 취소되는 일이 비일비재하다. 이 중 대부분은 적절하지 못한 리스크 관리 때문이며 만일 적절하고 체계적인 테스팅이 개발 프로젝트의 리스크를 관리하는 데 사용되었더라면 결과는 크게 달라졌을 것이다.

개발 자체가 실제 소요되는 일정보다 짧은 기간 동안 부족한 인력과 리소스로 진행되고 있기 때문에 테스팅에 대한 투자를 고려하기가 쉽지 않다. 이런 개발 환경에서 테스팅을 체계적으로 하기 위하여 노력이 필요하며 이때문에 리스크를 중심으로 테스팅의 우선순위를 결정하여 진행하는 것이 필수적이다.

일반적으로 테스팅에 관심을 가진 관리자나 테스트 업무를 하고 있는 테스터가 테스팅에 대해 너무 단편적으로 알고 있다는 것 또한 체계적인 테스팅을 제약하는 요인이다. 또한 의사결정권자 또는 매니저들의 테스팅에 대한 인식 부족으로 테스팅에 제동이 거릴 수 있다. 이 경우 테스팅 지식을 습득하고 단계적으로 테스팅을 적용하도록, 더 나아가 비즈니스에 데스팅을 적극 활용하도록 의사결정권자를 설득하는 것이 필요하다. 그 외에 테스팅을 투자가 아닌 불필요한 비용으로 보는 시선으로 보는 경우도 있다. 이 때 어떤 활동보다 가장 ROI가 높은 활동임을 알려줘야 한다.

테스팅 분야 및 테스터 전문가

일반적으로 자신이 개발하고 자신이 테스트를 하지만 이를 개발 기간 내에 해내는 것이 힘들다. 그렇기에 개발팀과 QA팀을 나누어 각자 분야에 집중할 수 있게 해 준다. 또한, 테스팅으로 개발 기간 단축, 개발 비용 감소 등의 이점으로 소프트웨어 분야에서 큰 관심을 가지고 있는 분야이다. 또한 테스트 전문 지식을 가진 개발자 또한 매리트가 크다. 개발 분야 커리어는 일반적으로 연령적 한계가 있는 반면 테스팅 커리어는 상대적으로 연령 때문에 커리어가 제한되는 경우가 적다.

테스터의 자질 및 갖춰야 할 요건은 늘 변화하지만 일반적으로 다음과 같다.

분류	기본 요건	추가 요건
기술 능력	테스팅 수행 능력, 테스트(설계) 기법에 대한 이해, 소프트웨어 공학에 대한 이해	테스트 계획 능력, 단위/통합 테스팅 가이드, 리포팅 능력, 테스트 프로세스에 대한 이해, 도구 사용 능력(버그추적시스템, 다양한 테스트 자동화 도구, 정적분석 도구, 소스코드 관리 시스템 등), 정적 테스트, 개발, SQA, CMMI, ISO/IEC 15504 등에 대한 이해
습관	테스팅 할 부분에 대해 충분히 이해하려는 노력, 다양한 테스팅 경험을 체계적으로 해보려는 노력	조용한 작업환경, 모법사례 테스트 프로세스 준수 노력, 자신의 테스팅 능력 평가, 테스트 지원 도구 사용, 조직내 테스트 표준화 노력, 잘하는 테스터 또는 개발자와 협업하려는 노력
개인 능력	커뮤니케이션, 분석력, 문서화	일정 업데이트, 업무 처리 노력 예측, 결함을 유추해 내는 경험
사고방식 & 태도	주인의식, 열정적, 적극적, 긍정적, 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 논리적	끈기, 자기발전 욕망, 끊임없는 스터디, 개방적 태도

주섬주섬

공부 정리를 위한 블로그이며, "개발자도 알아야 할 소프트웨어 테스팅 실무 제3판"과 실라버스를 참고하였다.

참고

STEN

www.sten.or.kr

저작자표시

'IT 진로 > 자격증' 카테고리의 다른 글

STQB_CTFL 6. 테스트 지원 도구 (1)	2024.05.17
STQB_CTFL 5. 테스트 관리 (0)	2024.05.16
STQB_CTFL 4. 테스트 설계 기법 (1)	2024.05.16
STQB_CTFL 3. 정적 테스팅 (0)	2024.05.12
ISTQB_CTFL 2. 소프트웨어 개발 수명주기와 테스팅 (0)	2024.05.11