콘텐츠로 바로가기
HY_TECH_BASE

QA & Quality Assurance

소프트웨어 결함을 사전에 탐지하고 품질을 보증하기 위한 테스트 설계 원칙과 수작업/자동화 검증(V&V) 역학을 배웁니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

테스트, QA 및 검증 메커니즘(Testing, QA & Verification Mechanics, TQA)은 소프트웨어가 '제대로' 만들어졌는지, 그리고 '원하는 대로' 동작하는지를 확인하는 물리적 방어선을 다룹니다.

품질은 단순히 버그가 없는 상태가 아니라, 명시된 요구사항을 충족하는 신뢰성을 갖춘 상태입니다. 학습자는 단위 테스트(Unit)부터 통합(Integration), 시스템(System), 인수(Acceptance) 테스트로 정의되는 V-모델의 역학을 배웁니다. 또한, 경계값 분석(Boundary Value)과 같은 정적/동적 기법, 테스트 주도 개발(TDD)의 피드백 루프, 그리고 CI/CD 환경에서의 회귀 테스트(Regression) 자동화 원리를 학습하여 지속 가능한 고품질 소프트웨어를 보장하는 역량을 갖춥니다.

2. Scope & Boundaries

In-Scope

  • Testing Levels: Unit, Integration, System, Acceptance, Performance 테스트 물리
  • Test Design Techniques: 화이트박스(제어 흐름) vs 블랙박스(입출력) 명세 물리
  • QA Standards: ISO/IEC 25010 품질 모델 및 테스트 계획 수립 역학
  • Automated Verification: 유닛 테스트 프레임워크와 E2E 테스트 자동화 흐름

Out-of-Scope

  • 특정 프로그래밍 언어의 라이브러리 문법 교육 (05. FPL 영역으로 위임)
  • 네트워크 보안 패킷 분석 (08. NFS 영역으로 위임)

Boundaries

  • TQA vs. Verification & Validation: Verification은 '설계대로 구현했는가'에, Validation은 '사용자의 요구에 부합하는가'에 집중하며, TQA는 이 두 활동을 수행하는 구체적인 물리적 도구와 기법을 제공합니다.

3. Counterexample

  • 단순히 '코드를 실행해보고 안 깨지면 통과'하는 것은 TQA 학습이 아닙니다. 왜 테스트 케이스에 **최악의 입력(Worst-case input)**이 포함되어야 하는지 그 결함 밀도(Defect Density) 역학을 설명하고, 코드 변경 시마다 전체 기능의 무결성을 보장하기 위해 어떤 기준으로 **회귀 테스트 셋(Regression Set)**을 선별할지 논리적으로 증명할 수 있어야 합니다.

4. Prerequisites

  • 컴퓨터 과학 및 공학 루트 (Basic): 공학적 품질 관리에 대한 기본 인식이 필요합니다. (ROOT)
  • 엔지니어링 라이프사이클 (Recommended): SDLC 각 단계와 연동되는 테스트 주기에 대한 이해가 권장됩니다. (09. ELM)

5. Learning Map

  1. Foundations of Quality: 소프트웨어 테스팅의 7가지 원칙과 심리적 배경을 이해합니다.
  2. Technique Strategy: 무엇을 테스트할지 결정하는 블랙박스/화이트박스 기법의 물리적 차이를 배웁니다.
  3. Execution Pyramids: 작은 코드 조각부터 전체 시스템 흐름까지 단계별로 검증하는 전술을 익힙니다.
  4. Maintenance Automation: 사람이 일일이 기억할 수 없는 수많은 테스트를 기계가 대신 수행하게 하는 자동화 역학을 탐구합니다.

6. Learning Topics

Basic

Core: 소프트웨어 테스팅의 기초와 원칙 (Testing Basics)

  • Why to Learn: 체계적인 접근 없이 주먹구구식으로 테스트할 때 발생하는 비용과 위험을 줄이기 위함입니다.
  • What to Learn:
    • 테스팅의 7대 원칙 (살충제 패러독스, 오류 부재의 궤변 등)
    • Verification(검증) vs Validation(확인)의 물리적 선결 조건 차이
    • 결함(Defect), 에러(Error), 실패(Failure)의 공학적 정의
  • How to Learn:
    • 과거에 겪었던 소프트웨어 오류 사례를 분석하고 위 3가지 정의 중 어디에 해당했는지 레이블링 실습
    • '살충제 패러독스'를 방지하기 위해 테스트 케이스를 어떻게 갱신해야 하는지 토론
  • Implement: 테스팅의 기초 용어와 원칙을 정리한 품질 기초 학습 가이드

Core: 테스트 설계 및 설계 기법 (Test Design Dynamics)

  • Why to Learn: 모든 입력을 대입해 볼 수 없는 물리적 한계 내에서 가장 효율적인 테스트 조합을 찾기 위해서입니다.
  • What to Learn:
    • 블랙박스 기법: 동등 분할, 경계값 분석, 결정 테이블 물리
    • 화이트박스 기법: 구문(Statement), 결정(Decision), 조건(Condition) 커버리지
    • 탐색적 테스팅(Exploratory Testing)의 논리적 절차
  • How to Learn:
    • 회원가입 폼의 '나이(0~120)' 입력란에 대한 경계값 케이스 5가지 도출 실습
    • 간단한 중첩 if문의 소스 코드를 보고 100% 문장 커버리지를 달성하기 위한 입력값 설계
  • Implement: 특정 기능 명세에 대한 최적의 테스트 케이스 설계서

Practical

Core: 테스트 레벨과 자동화 실행 (Execution & Automation)

  • Why to Learn: 대규모 시스템에서 기능 변경 시 기존 기능이 망가지지 않았음을 즉각적으로 확인하기 위함입니다.
  • What to Learn:
    • 단위(Unit), 통합(Integration), 시스템(System) 테스트의 경계와 가짜 객체(Mock/Stub) 활용물리
    • TDD(Test Driven Development)의 Red-Green-Refactor 사이클
    • UI 테스트 자동화 도구(Selenium, Playwright 등)의 셀렉터 역학
  • How to Learn:
    • JUnit이나 Jest 같은 프레임워크를 이용해 간단한 계산기 함수에 대한 단위 테스트 작성
    • Mock API를 구축하여 외부 시스템 의존성 없이 내부 로직을 독립적으로 검증하는 통합 환경 구축
  • Implement: 특정 모듈에 대한 자동화된 유닛 테스트 코드 및 커버리지 보고서

Advanced

Core: 품질 메트릭과 테스트 관리 거버넌스 (QA Governance)

  • Why to Learn: 품질 수준을 정량화하고 전략적인 릴리즈 의사결정을 내리기 위해서입니다.
  • What to Learn:
    • 결함 밀도, 테스트 진행률, 재수행 성공률 등 품질 지표(Metrics) 분석
    • 위험 기반 테스팅(Risk-based Testing): 어떤 기능을 우선적으로 테스트할지 결정 물리
    • 성능 및 부하 테스트(Load/Stress)의 임계점 감지 역학
  • How to Learn:
    • 성능 테스트 도구(JMeter 등)를 사용하여 초당 요청 수(TPS)에 따른 서버 자원 사용량 변화 관측
    • 특정 버전 배포 여부를 결정하기 위해 품질 지표 데이터를 근거로 'Go/No-Go' 판정 시뮬레이션
  • Implement: 프로젝트 종료 시점의 종합 품질 분석 보고서 및 릴리즈 승인서

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
Regression Testing 코드 변경 후 수정되지 않은 기존 영역의 기존 기능이 의도치 않은 오류 없이 그대로 작동하는지 재검토하는 물리입니다. 기본 안정성 확보 Automation Bug fix 단순히 '재시험'으로 오해 P2:SWEBOK core
Code Coverage 테스트 도중 실행되는 화이트박스 테스트 도달 수준을 백분율로 나타낸 메트릭입니다. 추천 정량 지표 Statement/Branch Defect Density 100%면 완벽하다고 오해 P2:SWEBOK. core
TDD (테스트 주도 개발) 구현 코드보다 테스트 코드를 먼저 작성하여 설계의 견고함과 구현의 정확성을 동시에 잡는 개발 물리입니다. 실무 개발 패러다임 Red-Green JUnit 단순히 '코드 먼저'로 오해 Industry TDD core
Mock Object 테스트 대상을 고립시키기 위해 실제 객체의 인터페이스는 유지하되 행위는 프로그래밍한 가짜 물리 객체입니다. 실무 환경 격리 Stub / Spy Unit test 실제 객체와 혼동함 Industry core

8. References

Primary References

Secondary References

  • [The Art of Software Testing] Glenford J. Myers — Deep insight into testing mindset.
  • [Working Effectively with Legacy Code] Michael Feathers — Practical testing strategies for existing code.

Industry References

  • [ISTQB Foundation Level Syllabus] — The global standard for testing certifications.
  • [Google Testing Blog] — Modern practices in large-scale automated verification.

9. Final Checklist

Primary Checklist

  • 블랙박스 테스팅을 설계할 때, 입력 도메인의 유효값과 무효값을 구분하여 경계 조건에서 결함이 발생하는 물리적 이유를 기술할 수 있는가? (P2)
  • V-모델의 각 테스트 단계가 상위 라이프사이클의 어떤 단계 결과물(상세 설계, 명세서 등)과 매핑되는지 설명 가능한가? (P2)

Secondary Checklist

  • 회귀 테스트 셋이 너무 커졌을 때, 위험도와 변경 빈도를 기준으로 실행 우선순위를 논리적으로 재조정할 수 있는가?
  • 테스트 리포트에서 발견된 결함들의 유형을 분석하여 향후 개발 프로세스에서 방지하기 위한 개선안을 도출할 수 있는가?

Industry Checklist

  • CI(지속적 통합) 파이프라인 내에서 자동화 테스트 실패 시 빌드를 즉시 중단시키는 'Fail Fast' 방식의 물리적 이점을 활용하고 있는가? (SFIA)
  • 성능 테스트 결과에서 CPU 병목(Throttling)과 네트워크 병목(Congestion)을 데이터 기반으로 구분하여 원인을 진단 가능한가?

Concepts & Tags

#testing#qa#verification#validation#automation