테스트 관련 강좌

CSTS 일반등급 자격증, 이 글 하나로 완벽 정복! (테스트 개요부터 자동화, 실무 팁까지 총정리)

프리스케이터 2025. 9. 10. 10:00

 

0. 오리엔테이션: 과정 소개

여러분, 테스트 아웃소싱 환경에서 일하는 내부 테스터로서 ‘CSTS 일반등급’ 지식은 실전 품질 경쟁력을 높여줍니다.

 

 

오늘 이 글을 통해 테스트의 기본 개념부터 프로세스, 설계 기법, 그리고 자동화와 관리에 이르기까지 모든 것을 순차적으로 살펴보겠습니다.

 

각 장마다 실무 사례와 팁을 담았으니, 실제 업무에 적용한다는 생각으로 끝까지 함께해 주세요!

 

1. 테스트 개요

1.1. 테스트의 목적 – 3대 축

 

 

테스트의 근본 목적은 결함 검출, 품질 평가, 프로세스 개선 세 가지입니다. 단순히 버그를 찾는 것을 넘어, 결함을 찾아 제거하고, 결과 지표로 의사결정을 지원하며, 결함 분포를 분석해 개발 프로세스 자체를 고도화하는 것이죠.

 

즉, 테스트는 조직의 품질 문화를 성장시키는 핵심 활동입니다.

1.2. 오류(Error) vs. 결함(Defect) vs. 장애(Failure)

  • 오류(Error): 개발자의 실수, 잘못된 이해, 오타 등 사람의 행위 차원입니다.
  • 결함(Defect): 오류의 결과로 코드나 설계 안에 잠복한 문제 요소를 말합니다.
  • 장애(Failure): 결함이 실행될 때, 요구사항과 실제 동작이 어긋나 관찰 가능한 현상입니다.
    ⇒ 테스트는 ‘장애’를 단서로 ‘결함’을 추정해 내고, 개발자는 근본 원인인 ‘오류’를 교정합니다.

1.3. 결함 유형 3가지: 누락·부정확·비관련

  • 누락(Omission): 구현되지 않은 요구사항 (예: 허근 처리 로직 누락)
  • 부정확(Incorrect): 잘못 구현된 요구사항 (예: 근의 공식 판별식 오타)
  • 비관련(Extraneous): 요구사항과 무관한 불필요한 기능 (예: 쓸모없는 파일 I/O)
    이 분류는 리뷰나 테스트 설계 시 결함을 예측하는 중요한 기준이 됩니다.

1.4. 개발 단계별 결함 분포 & 수정 비용: “늦게 잡을수록 비싸다!”

통계적으로 결함의 35%가 코딩 단계, 25%가 설계, 20%가 요구분석에서 비롯됩니다.

 

하지만 수정 비용은 정반대입니다.

 

요구사항 단계에서 발견했다면 1의 비용으로 수정할 것을, 유지보수 단계에서는 무려 20배의 비용이 듭니다.

 

조기 테스트와 리뷰가 중요한 이유입니다.

 

1.5. 테스팅·디버깅·재테스팅의 역할

  • 테스팅: 결함의 존재 여부를 보여주는 활동입니다. "어딘가 문제가 있다!"
  • 디버깅: 결함의 위치를 파악하고 코드를 수정하는 활동입니다. "왜? 어디서?"
  • 재테스팅: 동일한 테스트 케이스로 수정이 잘 되었는지 검증하는 활동입니다. "정말 고쳐졌나?"

현장 Tip: 테스트 로그에 재현 절차를 상세히 남기면 개발자의 디버깅 시간을 크게 줄일 수 있습니다.

1.6. 완벽한 테스트의 불가능성과 대응: “테스트는 낚시다”

모든 입력 값의 조합을 테스트하는 것은 실질적으로 불가능합니다.

 

낚시로 저수지에 물고기가 없음을 증명할 수 없듯, 테스트로 ‘버그 없음’을 증명할 수는 없습니다.

 

따라서 위험 기반 테스트, 동등 분할, 경곗값 분석, 조합 테스트 등 효율적인 기법을 활용해 최소한의 노력으로 최대의 효과를 내야 합니다.

1.7. 테스트 진화 5단계: Debugging → Prevention

단계 키워드 시대 특징
Lv 1 Debugging ~1956 우연히 발견된 결함만 수정
Lv 2 Demonstration 1957~78 “정상 동작 증명” 중심
Lv 3 Destruction 1979~82 결함 발견 자체가 목표
Lv 4 Evaluation 1983~87 개발 전 단계까지 확대
Lv 5 Prevention 1988~ 결함 사전 방지, TDD

1.8. 테스트 원칙 (Myers 7 Principles – 핵심 4선)

  1. 독립성: 개발자와 다른 독립된 팀이 테스트해야 객관성을 확보할 수 있습니다.
  2. 결함 가정: ‘버그가 없을 것’이라는 전제하에 계획을 짜지 않습니다.
  3. 비정상 입력도 테스트: 예상치 못한 사용자의 입력이 진짜 위험을 만듭니다.
  4. 파레토 법칙: 20%의 모듈에 80%의 결함이 집중됩니다. 이 부분에 테스트를 집중해야 합니다.

2. 테스트 분류 & V 모델

2.1. 세 축 분류: 레벨·유형·설계 기법

CSTS 가이드는 테스트를 3D 마인드맵처럼 세 축으로 분류합니다.

  • 레벨: 컴포넌트(단위) / 통합 / 시스템 / 인수
  • 유형: 기능적 / 비기능적 (성능, 보안, 사용성 등)
  • 설계 기법: 정적 / 동적 (명세 기반, 구조 기반, 경험 기반)
    이 세 축을 기준으로 생각하면 어떤 테스트가 누락되었는지 쉽게 파악할 수 있습니다.

2.2. 테스트 레벨: 단위→통합→시스템→인수

  • 단위 테스트: 상세 설계를 기반으로 모듈(함수, 클래스)을 검증합니다.
  • 통합 테스트: 아키텍처 설계를 기반으로 모듈 간 인터페이스를 검증합니다.
  • 시스템 테스트: 요구 명세를 기반으로 전체 시스템이 통합된 환경에서 동작하는지 검증합니다.
  • 인수 테스트: 사용자 시나리오를 기반으로 최종 사용자가 사용할 수 있는지 검증합니다.

2.3. 테스트 유형 (기능 vs. 비기능): ISO 25010 8대 품질 특성

기능 요구사항 외에도 성능 효율성, 보안성, 사용성, 신뢰성 등 비기능적 품질 특성을 반드시 테스트해야 합니다.

 

프로젝트 위험 분석 시, 놓치기 쉬운 비기능적 요구사항부터 체크하는 것이 좋습니다.

2.4. 테스트 설계 기법: 정적 vs. 동적

  • 정적 테스트: 코드를 실행하지 않고 리뷰, 인스펙션, 정적 분석 도구 등을 통해 결함을 탐지합니다.
  • 동적 테스트: 코드를 실행하며 명세 기반, 구조 기반, 경험 기반 기법으로 시스템 동작을 검증합니다.

2.5. V 모델: SDLC & STLC의 대칭

V 모델은 개발 생명주기(SDLC)와 테스트 생명주기(STLC)가 ‘V’ 형태로 대칭을 이룹니다.

 

요구사항 수집 단계에서 인수 테스트 계획이 시작되고, 아키텍처 설계 단계에서 통합 테스트 설계가 시작되는 등, 테스트는 개발과 병행하는 활동임을 보여주는 중요한 모델입니다.

3. 테스트 프로세스 (ISO 29119 Flow)

3.1. 프로세스 개관: Plan → Analysis/Design → Implementation → Execution → Completion

CSTS 표준 프로세스는 크게 관리 프로세스와 동적 테스트 프로세스로 나뉩니다.

  • 관리 프로세스 산출물: 테스트 계획서 → 현황 보고서 → 종료 보고서
  • 동적 프로세스 흐름: 계획 기반 설계/구현(케이스, 절차, 환경, 데이터) → 환경 구축 → 실행 및 결함 관리

3.2. 테스트 계획(Planning)

계획 단계에서는 테스트의 컨텍스트, 범위, 위험, 전략, 완료 기준을 정의합니다. 특히 위험 분석(가능성 L, 영향도 I) 결과를 바탕으로 회피, 완화, 수용, 전가 등의 전략을 수립합니다.

3.3. 테스트 설계 & 구현

계획서의 전략을 구체화하여 테스트 케이스, 절차, 환경, 데이터 명세서를 작성합니다.

 

이때 동등 분할, 경곗값 분석 등 구체적인 설계 기법을 적용합니다.

3.4. 테스트 실행 & 결함 관리

테스트 절차를 실행하며 테스트 실행 로그를 기록하고, 발견된 결함은 결함 보고서로 등록하여 추적합니다.

 

수정이 완료되면 재테스트를 통해 해결 여부를 확인하고, 필요 시 리그레션(회귀) 테스트 범위를 확장합니다.

4. 테스트 설계 기법 심화

4.1. 명세 기반(기능 관점)

기법 핵심 아이디어 적용 포인트
동등 분할 입력/출력 영역을 클래스 단위로 나누고 대표값 선택 값 범위 검증
경곗값 분석 경계와 인접 값을 사용 (2-value/3-value 방식) 범위 경계 결함 탐지
조합 테스트 페어와이즈(Pairwise) 등으로 입력 인자 조합 최소화 파라미터 상호작용
상태 전이/시나리오 상태와 흐름에 의존하는 로직 검증 워크플로, UI

4.2. 구조 기반(코드 관점)

코드의 구조를 분석하여 테스트 케이스를 설계하는 기법으로, 문장, 결정(분기), 조건, MCDC(Modified Condition/Decision Coverage) 등의 커버리지 지표를 활용합니다.

 

커버리지 목표는 계획 단계에서 미리 정의하고, 중요도가 높은 모듈에는 더 높은 커버리지를 설정해야 합니다.

4.3. 경험 기반

  • 오류 추정: 테스터의 경험과 직관으로 결함이 많을 것으로 예상되는 영역을 집중적으로 테스트합니다.
  • 탐색적 테스트: 테스트 설계, 실행, 학습을 동시에 진행하며 정형화되지 않은 영역의 불확실성을 줄이는 데 효과적입니다.

5. 위험 기반 테스트(RBT)

위험 점수 = 가능성 × 영향도 공식을 활용하여 제품 위험(기능 오류)과 프로젝트 위험(일정 지연, 예산 초과)을 식별하고 관리합니다.

 

고위험 기능에 대해서는 ▲테스트 레벨 조기화 ▲강도 높은 설계 기법 적용 ▲엄격한 완료 기준 설정 등 차별화된 전략을 적용합니다.

6. 자동화 & 모의 객체

6.1. FIRST 원칙

좋은 단위 테스트 자동화 코드는 다음 5가지 원칙을 따라야 합니다.

  • Fast (빠르게)
  • Isolated (독립적으로)
  • Repeatable (반복 가능하게)
  • Self-Validating (자체 검증)
  • Timely (시기적절하게)
    Mock, Stub, Spy, Fake와 같은 모의 객체를 사용하면 외부 의존성을 격리하여 FIRST 원칙을 달성하는 데 도움이 됩니다.

6.2. 크로스 브라우징 & CI

Selenium Grid와 같은 도구를 사용하면 허브-노드 구조를 통해 다양한 OS와 브라우저 조합을 병렬로 실행할 수 있습니다.

 

이를 통해 실행 시간을 단축하고 환경 커버리지를 효과적으로 확대할 수 있습니다.

7. 품질 측정 & 리포팅

결함 트렌드, 테스트 진행률, 커버리지 등의 지표를 대시보드로 시각화하여 지속적으로 공유함으로써, 이해관계자들이 데이터에 기반한 의사결정을 내릴 수 있도록 지원해야 합니다.

10. 정적 테스트

10.1. 리뷰 5종

  • 관리 리뷰: 일정, 범위 등 프로젝트 관리 측면을 통제합니다.
  • 기술 리뷰: 명세서의 기술적 적합성을 검토합니다.
  • 인스펙션: 공식적인 절차에 따라 결함을 식별하고 해결을 검증합니다.
  • 워크쓰루: 저자가 주도하여 대안을 토의하고 지식을 공유합니다.
  • 감사: 독립적인 팀이 표준 및 규정 준수 여부를 평가합니다.

10.2. 정적 분석

자동화 도구를 사용해 소스 코드를 스캔하여 코딩 표준 위반, 순환 복잡도, 초기화되지 않은 변수 등을 실행 없이 찾아냅니다.

 

개발 초기에 결함을 제거하여 후반부의 막대한 수정 비용을 줄여줍니다.

11. 생명주기 모델별 테스트 전략

  • 폭포수 모델: 개발이 끝난 후 테스트를 하나의 단계로 취급합니다.
  • V 모델: 개발 단계와 테스트 단계를 병행 활동으로 정의합니다.
  • 나선형 모델: 프로토타입 개발 → 테스트/평가 → 위험 분석을 반복하며 점진적으로 제품을 완성합니다. 각 사이클마다 테스트 범위와 기준을 재조정합니다.

Tip: 애자일 스프린트 역시 ‘계획→개발→테스트→리뷰’의 미니 V 모델이 내재된 구조입니다.

12. 테스트 완료 기준 & 품질 지표

12.1. 완료 기준 (Exit Criteria)

테스트를 언제 종료할지 결정하는 객관적인 기준입니다.

 

계획 단계에서 ‘문장 커버리지 ≥ 80%’, ‘심각도 1 결함 0건’, ‘잔존 위험 점수 ≤ 3’과 같이 구체적인 수치로 정의해야 합니다.

12.2. 주요 지표

지표 의미 활용
결함 추세 발견 및 수정 속도 안정화 시점 예측
테스트 진행률 계획 대비 실행률 일정 관리
커버리지 테스트 범위 달성도 완료 기준 판단
리스크 버너다운 잔존 위험 점수 추이 RBT 효과 확인

13. 테스트 자동화 전략

13.1. 범위 선정

빈번하고, 반복적이며, 규칙적인 영역을 우선 자동화 대상으로 선정합니다.

 

특히 리그레션 테스트, 데이터 기반 테스트, 크로스 플랫폼 테스트 시나리오가 자동화에 적합합니다.

13.2. CI/CD 연계

FIRST 원칙을 만족하는 단위 테스트 세트를 빌드 파이프라인에 통합하여, 코드 커밋 시 자동으로 테스트가 수행되게 합니다.

 

테스트 실패 시 빌드를 중단하고 개발자에게 즉시 피드백을 주어 결함이 운영 환경으로 유입되는 것을 방지합니다.

16. 결함 관리 사이클

16.1. 결함 생명 주기 (State Flow)

CSTS 표준은 결함 상태를 Open → Review → Assigned → Resolved → Verified → Closed를 기본 흐름으로 하며, 상황에 따라 Deferred(이월) 또는 Reopen(재발견) 상태를 가집니다.

16.2. 릴리스별 처리 시나리오

  • 이번 릴리스 처리: Open → ... → Closed 사이클을 즉시 완료합니다.
  • 차후 릴리스 처리: 위험도나 비용을 고려하여 Open → Review → Deferred 상태로 이월시킵니다.

17. 결함 보고서 & 추적 보고서

17.1. 결함 보고서 필수 항목

ISO 29119-3은 결함 보고서에 ▲컨텍스트(환경, 재현 절차) ▲설명(실제 vs 예상 결과) ▲심각도/우선순위 ▲위험 분석 ▲현재 상태를 포함할 것을 권장합니다.

 

특히 상세한 재현 절차는 빠른 디버깅의 핵심입니다.

17.2. 결함 추적 보고서

결함이 각 상태를 거치면서 누가, 언제, 어떻게 처리했는지(검토, 해결, 검증)에 대한 이력을 기록하여 추적성을 확보합니다.

19. 결함/케이스 관리 도구 (JIRA + Xray 예시)

19.1. 워크플로 매핑

JIRA와 같은 도구를 사용하여 CSTS 표준 결함 상태를 실제 워크플로에 매핑하여 관리할 수 있습니다. (예: CSTS 'Open' → JIRA 'To Do', CSTS 'Resolved' → JIRA 'Done')

19.2. 보고서 & 대시보드

Xray와 같은 테스트 관리 플러그인을 활용하면 결함 밀도, 요구사항 커버리지, 테스트 실행 현황 등을 실시간 대시보드로 시각화할 수 있습니다. 특히 결함 나이(Defect Age) 차트는 장기 미해결 이슈를 조기에 경보하는 데 유용합니다.

20. 보고서 작성 실전

20.1. 테스트 현황 보고서 (주간)

주간 보고서는 계획 대비 진척도와 테스트 방해 요인을 명확히 전달하여 경영진의 의사결정을 지원하는 데 초점을 맞춰야 합니다.

20.2. 테스트 종료 보고서

프로젝트 완료 시 작성하며, 최종 요약, 계획과의 차이, 핵심 메트릭, 잔존 결함 및 위험, 완료 기준 평가, 그리고 교훈(Lessons Learned)이 핵심 항목입니다. 특히 ‘교훈’은 다음 프로젝트를 개선하는 귀중한 자산이 됩니다.

24. 자동화 스크립트 유지보수

24.1. 스크립트 안정화 전략

  • Page Object Pattern (POM): UI 요소 식별자와 테스트 로직을 분리하여 유지보수성을 높입니다.
  • 데이터 분리: 테스트 데이터를 외부 파일(CSV, JSON 등)로 분리하여 스크립트와 데이터의 결합도를 낮춥니다.
  • 모의 객체 활용: 외부 의존성을 격리하여 테스트의 안정성과 속도를 확보합니다.

24.2. 회귀 자동화 파이프라인

Git의 Pull Request(PR) 생성 시 CI 서버(예: GitHub Actions)가 자동으로 리그레션 테스트 스위트를 실행하고, 실패 시 PR을 차단하거나 경고 알림을 보내는 파이프라인을 구축합니다.

25. 재사용 가능한 테스트 자산 관리

테스트 케이스, 데이터, 환경 구성 스크립트, 자동화 스크립트 등은 재사용 가능한 자산입니다.

 

버전 관리, 태그, 메타데이터를 활용해 체계적으로 관리하고 위키(Wiki) 등에 지식 베이스를 구축하면 조직 전체의 테스트 효율성을 높일 수 있습니다.

26. 교훈(Lessons Learned) 워크숍

프로젝트 종료 후 Keep(잘한 점), Problem(문제점), Try(개선 아이디어)의 3가지 관점으로 회고를 진행하면 구체적이고 실행 가능한 개선안을 도출하는 데 효과적입니다.

27. 시험(CSTS 자격) 대비 팁

영역 학습 포인트 예시
프로세스 ISO 29119 흐름, 산출물 명칭 테스트 설계 명세서, 실행 로그
기법 동등 분할, 경곗값, MCDC 공식 2-value BVA 값 계산
관리 위험 계산식, 결함 상태 흐름 Likelihood × Impact, Open→Closed
용어 오류, 결함, 장애의 정확한 정의 Error/Defect/Failure 구분

학습 팁: 공식 용어를 정확히 암기하고, 예제 코드와 그래프를 머릿속에 그리며 개념을 이해하는 것이 중요합니다.

28. 전체 과정 요약

  1. 목적: 결함 검출, 품질 평가, 프로세스 개선
  2. 프로세스: 계획 → 설계/구현 → 환경 → 실행 → 결함 → 완료
  3. 기법: 명세/구조/경험 기반 기법과 RBT로 효율 극대화
  4. 자동화 & CI: FIRST 원칙, Page Object Pattern, Mock 활용
  5. 보고 & 지표: 실행 로그 기반의 다양한 보고서와 결함 나이 등 핵심 지표 활용

29. 마무리

이상으로 ‘소프트웨어 테스트 전문가(CSTS) 일반등급’ 과정의 핵심 내용을 모두 살펴보았습니다.

 

테스트는 단순한 기술이 아니라, 제품의 성공을 이끄는 경영 활동입니다.

 

오늘 정리한 프로세스와 기법들을 실제 프로젝트에 적용하며 여러분의 품질 경쟁력을 한 단계 높여보시길 바랍니다.

 

저작자표시 (새창열림)