[CTFL] 1장. 테스팅의 기초

#ISTQB

ISTQB-CTFL 시험 준비 시작

전체 시험 범위

1장. 테스팅의 기초

  • 테스팅 관련 기본 원칙
  • 테스팅 하는 이유와 목표
  • 테스트 절차와 주요 테스트 활동 및 테스트웨어(산출물)
  • 테스팅에 필요한 필수 기술

2장. 소프트웨어 개발 수명주기와 테스팅

  • 여러 개발 접근 방식과 테스팅이 통합되는 과정
  • 테스트 우선 접근 방식과 DevOps
  • 다양한 테스트 레벨과 유형 및 유지관리 테스팅

3장. 정적 테스팅

  • 정적 테스팅의 기본 사항, 피드백과 리뷰 프로세스

4장. 테스트 분석 및 설계

  • 블랙박스 vs 화이트박스 vs 경험 기반 테스트

5장. 테스트 활동 관리

  • 테스트 계획법과 노력을 추정하는 방법
  • 리스크가 테스트 범위에 가져올 수 있는 영향
  • 테스트 활동을 모니터링하고 제어하는 방법
  • 구성 관리가 테스트를 지원하는 방법
  • 결함을 보고하는 방법

6장. 테스트 지원 도구

  • 테스팅 도구와 테스트 자동화의 장단점

1장. 테스팅의 기초

용어

커버리지: 테스트 수행 범위를 측정하는 지표로, 코드나 요구사항 등이 얼마나 테스트되었는지를 나타냄
디버깅: 결함의 원인을 분석하고 수정하는 활동
결함: 시스템이나 컴포넌트에 존재하는 문제로 인해 기대한 결과와 다른 결과를 발생시키는 요소
오류: 사람이 수행한 실수나 잘못된 판단 및 행동
장애: 결함이 실행되어 시스템이 요구된 기능을 수행하지 못하는 상태
품질: 명시적·묵시적 요구사항을 충족하는 정도
품질 보증: 품질 요구사항이 충족될 것이라는 신뢰를 제공하기 위한 계획적이고 체계적인 활동
근본 원인: 문제 발생의 근본적인 이유(예: 오류로 이어지는 상황)
 
테스트 분석: 테스트 베이시스를 분석하여 테스트 조건을 식별하는 활동
테스트 베이시스: 테스트 케이스를 도출하는 근거가 되는 요구사항, 설계서, 코드 등의 산출물
테스트 케이스: 특정 테스트 조건을 검증하기 위한 입력값, 수행 절차, 예상 결과의 집합
테스트 완료: 정의된 종료 기준을 만족하여 테스트 활동을 마무리하는 상태
테스트 컨디션: 하나 이상의 테스트 케이스로 검증 가능한 테스트 대상의 항목이나 특성
테스트 제어: 테스트 활동을 계획 대비 모니터링하고 필요 시 수정 조치를 수행하는 활동
테스트 데이터: 테스트 수행에 필요한 입력값, 환경 데이터, 예상 결과 데이터
테스트 설계: 테스트 조건을 기반으로 테스트 케이스와 테스트 데이터를 설계하는 활동
테스트 실행: 테스트 케이스를 실제로 수행하고 결과를 기록하는 활동
테스트 구현: 테스트 절차, 테스트 스크립트, 테스트 데이터 등을 준비하는 활동
테스트 모니터링: 테스트 진행 상황을 지속적으로 추적하고 상태를 파악하는 활동
테스트 대상: 테스트의 대상이 되는 여러 산출물(요구사항, 설계서, 코드, 시스템 등)
테스트 목적: 테스트를 수행하는 이유와 달성하고자 하는 목표
테스트 계획: 테스트 범위, 일정, 자원, 전략 등을 정의하는 활동 및 결과물
테스트 절차: 테스트 케이스를 실행하기 위한 구체적인 순서와 단계
테스트 결과: 테스트 수행 후 얻어진 실제 결과 및 기록
테스팅: 소프트웨어 품질을 평가하고 결함을 발견하기 위한 전반적인 활동
테스트웨어: 테스트 수행을 위해 생성된 산출물(테스트 케이스, 스크립트, 데이터 등)
추적성: 요구사항, 테스트 조건, 테스트 케이스, 결함 간의 관계를 추적할 수 있는 정도
 
Validation(확인): 시스템이 운영 환경에서 사용자 또는 이해관계자가 필요한 바를 만족하는지 확인
Verification(검증): 시스템이 주어진 요구사항을 충족하는지 확인

1.1 테스팅이란 무엇인가?

올바르게 동작하지 않는 SW는 금전적, 시간적, 비즈니스 평판 손실은 물론 인명 피해까지 다양한 문제를 일으킬 수 있다. SW 테스팅은 SW 품질을 평가하고 SW 사용 시 나타날 수 있는 장애의 위험을 줄여줄 수 있다.

SW 테스팅은 결함을 식별하고 SW 산출물의 품질을 평가하는 일련의 활동이고, 이러한 활동은 SDLC에 따라 달라진다.

테스팅이 Verification에만 집중한다고 오해할 수 있으나 Validation도 포함된다.

테스팅은 동적 또는 정적으로 수행할 수 있다.

1.1.1 테스트 목적

  • 요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가
  • 장애 유발 및 결함 식별
  • 테스트 대상에 대해 요구된 커버리지 보장
  • SW 품질 부족으로 인한 리스크 수준의 완화
  • Verification과 Validation
  • 테스트 대상의 품질에 대한 자신감 획득

테스트 목적의 항목은 고정된 것이 아닌 정황에 따라 유동적으로 바뀔 수 있다.

1.1.2 테스팅과 디버깅

  • 테스팅: SW 결함으로 인한 장애를 유발(동적)하거나 테스트 대상에 있는 결함을 직접 찾아낸다(정적).
  • 디버깅: 장애의 원인(결함)을 찾고 그 원인을 분석하고 제거한다.
    • 디버깅 프로세스: 장애 재현 → 분석(결함 찾기) → 결함 수정

이후 확인 테스팅(confirmation testing) 으로 문제가 제대로 수정되었는지 확인한다.

※ 확인 테스팅은 처음 테스트를 수행한 사람이 다시 수행하는 것이 바람직하다.

  • 리그레션 테스팅(regression testing): 수정 사항이 테스트 대상의 다른 부분에 장애를 일으키지 않는지 확인

※ 정적 테스팅은 장애를 유발하지 않고 직접 결함을 식별하기 때문에 장애를 재현하고 분석할 필요는 없다.

1.2 테스팅이 왜 필요한가?

모든 이해관계자는 자신이 가진 테스트 기술을 활용해 프로젝트 성공에 기여할 수 있다. 또한 개발 산출물을 대상으로 테스팅은 SW 결함을 식별하는 데 도움이 된다.

1.2.1 테스팅이 성공에 기여하는 방법

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

※ 디버깅은 품질 향상에 직접적으로 영향을 끼치는 활동이고, 테스팅은 간접적으로 기여하는 활동이다.

테스팅은 SDLC 단계에서 테스트 대상의 품질을 직접 평가할 수 있는 방법을 제공한다. 평가 결과는 SDLC 다음 단계로 넘어갈지 릴리스를 하는 것이 적합한지 판단하는 결정 등에 기여한다.

1.2.2 테스팅과 QA

테스팅과 품질 보증(QA, Quality Assurance) 은 같지 않다.

  • 테스팅: 제품 지향적이고 적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 교정 접근법이다. 테스팅은 품질 제어의 주요 활동이며, 정형 기법, 시뮬레이션, 프로토타이핑도 품질 제어에 속한다.
  • QA: 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법이다. 좋은 프로세스를 올바르게 준수하면 좋은 제품이 만들어진다는 가정을 기반으로 한다. 개발 및 테스팅 프로세스 모두에 적용되며 프로젝트에 참여하는 모두의 책임이다.

테스트 결과는 테스팅과 품질 보증 모두에 사용된다.

  • 테스팅에서는 결함을 수정하는 데 사용
  • QA에서는 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용

1.2.3 오류, 결함, 장애, 근본 원인

사람은 오류(실수) 를 저지르며 이에 따라 결함이 발생하고, 이는 결국 장애로 이어질 수 있다.

결함은 산출물 곳곳에서 발생할 수 있으며, 초기 산출물의 결함이 후반 산출물의 결함으로 이어질 수 있다. 결함으로 인해 작업을 수행하지 못하거나 올바르지 않은 작업이 수행될 경우 장애를 일으킬 수 있다.

※ 특정 상황에서 장애를 일으키거나 장애로 이어지지 않는 결함도 존재할 수 있으며, 원인이 꼭 결함만 있는 것도 아니다. 방사선이나 전자기장이 펌웨어에 문제가 생기게 하는 경우처럼 환경 조건으로 발생하는 것도 있다.

근본 원인은 문제 발생의 근본적인 이유를 말한다. 근본 원인은 근본 원인 분석을 통해 찾게 되며, 보통 장애가 발생하거나 결함을 식별한 경우 수행한다.

1.3 테스팅의 원리

CTFL 실러버스에서는 여러 테스팅의 원리 중에서 7가지를 소개한다.

  1. 테스팅은 결함의 존재를 밝히는 활동이지 결함이 없음을 증명하지 않는다.
  2. 완벽한 테스팅은 불가능하다.
  3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.
  4. 결함은 집중된다. (예: 전체 결과의 80%가 전체 원인의 20%에서 발생한다는 파레토 원리)
  5. 테스트 효과는 줄어든다. (그러나 자동 리그레션 테스팅처럼 같은 테스트를 반복하는 것이 유익한 경우도 있다.)
  6. 테스팅은 정황에 의존적이다. (모든 상황에 적용할 수 있는 하나의 테스팅 접근법은 없다.)
  7. 결함-부재는 궤변이다. (SW Verification이 시스템의 성공을 보장할 것이라고 기대하는 것은 잘못되었다. Validation도 같이 수행해야 한다.)

1.4 테스트 활동, 테스트웨어, 테스트 역할

테스트 목적을 달성하기 위해 필요한 보편적인 테스트 활동들이 있다. 이런 테스트 활동이 테스트 프로세스를 구성하게 된다.

1.4.1 테스트 활동과 업무

테스트 프로세스를 구성하는 주요 활동은 보통 다음과 같다. 이러한 활동 중 대부분은 순차적으로 수행되는 것처럼 보일 수 있으나, 실제로는 반복적 또는 병렬로 구현되는 경우가 많다.

  • 테스트 계획: 테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법을 선택하는 과정이다.
  • 테스트 모니터링과 제어: 테스트 모니터링은 지속적으로 모든 테스트 활동을 점검하고 실제 진행 상황을 계획과 비교하는 활동이다. 테스트 제어는 테스트 목적을 달성하는 데 필요한 조치를 하는 활동이다.
  • 테스트 분석: 테스트 베이시스를 분석해 테스트 가능한 기능을 식별한다. "무엇을 테스트할 것인가?"라는 질문에 측정 가능한 커버리지 조건으로 답을 제공한다.
  • 테스트 설계: 테스트 컨디션을 테스트 케이스와 기타 테스트웨어로 구체화하는 작업을 포함한다. "어떻게 테스트할 것인가?"라는 질문에 답을 제공한다.
  • 테스트 구현: 테스트 실행에 필요한 테스트웨어(예: 테스트 데이터)를 만들거나 획득하는 작업을 포함한다. 테스트 케이스는 테스트 절차로 묶을 수 있으며 테스트 스위트로 조합하는 경우도 많다.
  • 테스트 실행: 테스트 실행 일정에 따라 테스트를 수행(테스트 런)하는 것을 포함한다.
  • 테스트 완료: 일반적으로 프로젝트 마일스톤(예: 릴리스, 반복 주기 완료, 테스트 레벨 완료)에서 수행된다. 해결되지 않은 결함에 대해서는 변경 요청서 또는 제품 백로그 항목을 만든다.

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

테스팅은 단독으로 수행되지 않는다. 테스팅 수행 방식은 다음과 같은 여러 정황 요소에 따라 달라진다.

  • 이해관계자
  • 팀원
  • 비즈니스 도메인
  • 기술적 요인
  • 프로젝트 제약 조건
  • 조직적 요인
  • SDLC
  • 도구

1.4.3 테스트웨어

테스트웨어는 1.4.1의 테스트 활동의 결과물로 만들어진다. 조직마다 테스트웨어를 관리하는 방식에 상당한 차이가 있다. 적절한 형상 관리는 작업 산출물의 일관성과 무결성을 보장한다.

다음은 각 활동에 대한 작업 산출물이다.

  • 테스트 계획 작업: 테스트 계획, 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건
  • 테스트 모니터링과 제어 작업: 테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보
  • 테스트 분석 작업: (우선순위가 지정된) 테스트 컨디션(예: 인수 기준), (바로 수정하지 않았다면) 테스트 베이시스의 결함에 관한 결함 보고서
  • 테스트 설계 작업: (우선순위가 지정된) 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항
  • 테스트 구현 작업: 테스트 절차, 수동 및 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정, 테스트 환경 요소(예: 스텁, 드라이버, 시뮬레이터, 서비스 가상화 등)
  • 테스트 실행 작업: 테스트 로그, 결함 보고서
  • 테스트 완료 작업: 테스트 완료 보고서, 향후 프로젝트 또는 반복 주기 때 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서(예: 제품 백로그 항목)

1.4.4 테스트 베이시스와 테스트웨어 간의 추적성

효과적인 테스트 모니터링과 제어를 구현하려면 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소, 관련 테스트웨어, 테스트 결과, 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.

정확한 추적성은 커버리지 평가를 지원하며, 측정 가능한 커버리지 조건이 테스트 베이시스에 정의되어 있다면 매우 유용할 수 있다.

1.4.5 테스팅에서의 역할

  • 테스트 관리 역할: 테스트 프로세스, 테스트 팀 그리고 테스트 활동 리더십에 대한 전반적인 책임을 진다. 주로 테스트 계획, 테스트 모니터링, 테스트 제어, 테스트 완료 활동에 중점을 둔다.
  • 테스팅 역할: 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다. 주로 테스트 분석, 설계, 구현, 실행 활동에 초점을 둔다.

1.5 테스팅의 필수 기술 및 모범 사례

우수한 테스터는 업무를 잘 수행하기 위한 몇 가지 필수적인 기술을 갖추어야 한다.

1.5.1 테스팅에 보편적으로 필요한 기술

테스터에게 의사소통 기술은 매우 중요하다. 테스트 결과의 전달을 제품이나 작성자에 대한 비판으로 오해할 소지가 있으며, 확증 편향은 현재 가지고 있는 믿음과 맞지 않는 정보를 받아들이기 어렵게 만든다.

1.5.2 전체 팀 접근법

테스터에게 중요한 기술 중 하나는 팀 환경에서 효과적으로 일하고 팀 목표에 긍정적으로 기여하는 능력이다.

익스트림 프로그래밍(XP) 에서 시작된 전체 팀 접근법은 이런 능력을 기반으로 한다.

전체 팀 접근법에서는 필요 지식과 기술을 갖춘 팀원이라면 누구나 어떤 작업이라도 수행할 수 있으며, 모든 팀원이 품질에 대한 책임을 진다.

※ 정황에 따라 전체 팀 접근법이 적절하지 않을 수도 있다. 예를 들어 안전이 치명적인 경우에는 높은 수준의 테스트 독립성이 필요할 수 있다.

1.5.3 테스팅의 독립성

일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로 테스터가 결함을 더 효과적으로 식별할 수 있다. 그러나 독립성이 친숙함을 대체하는 것은 아니다. 예를 들어 개발자는 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

대부분의 프로젝트는 여러 수준의 독립성으로 테스팅을 수행하는 것이 가장 좋다.

독립적인 테스팅의 주요 이점은 독립적인 테스터는 배경, 기술적 관점, 편향이 다르기 때문에 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다는 점이다.

참고

ISTQB 공식 Syllabus