QA & Quality Assurance

1. Overview

QA 및 품질 보증(QA & Quality Assurance, TQA)은 소프트웨어가 '우리가 계획한 대로 만들어졌는지(Verification)'와 '고객이 진짜로 원하는 가치를 충족하는지(Validation)'를 수학적, 물리적으로 증명해 내는 엔지니어링의 최후 방어선을 다룹니다.

과거의 테스트는 개발이 다 끝난 뒤 화면을 무작정 클릭해보는 수작업에 불과했습니다. 학습자는 코드 단위의 결함을 잡는 단위 테스트(Unit Test)부터 컴포넌트 간의 결합을 검증하는 통합 테스트(Integration Test), 그리고 TDD(테스트 주도 개발)의 철학을 배웁니다. 나아가 화이트박스/블랙박스 기법으로 수천 개의 케이스를 효율적으로 줄이는 경계값 분석(Boundary Value)을 익히고, 인간의 기억력에 의존하지 않고 CI/CD 환경에서 기계가 수만 번의 회귀 테스트(Regression Test)를 자동으로 수행하게 만드는 품질 자동화 시스템을 구축합니다.

2. Scope & Boundaries

In-Scope

• 테스트 레벨 (Testing Levels): V-모델 기반의 단위(Unit), 통합(Integration), 시스템(System), 인수(Acceptance) 테스트 물리.
• 테스트 설계 기법 (Test Design): 블랙박스(경계값 분석, 동등 분할) vs 화이트박스(구문/결정/조건 커버리지).
• 자동화 및 패러다임 (Automation & Paradigm): TDD(Test-Driven Development), BDD(Behavior-Driven Development), Mock/Stub 객체 활용, UI/E2E 테스트 자동화.
• 품질 관리 및 지표 (Quality Metrics): 결함 밀도(Defect Density), 코드 커버리지(Code Coverage), 회귀 테스트(Regression Test) 전략.

Out-of-Scope

• 프로그래밍 언어의 기본 문법 체계: JUnit, PyTest 등의 어노테이션 사용법을 위한 언어 기초 $\rightarrow$ 05. FPL 영역으로 위임.
• 도커/쿠버네티스를 이용한 배포 파이프라인: 테스트가 끝난 코드를 프로덕션 서버로 밀어넣는 인프라 관점의 작업 $\rightarrow$ 09-05. DevOps & Reliability 영역으로 위임.

Boundaries

• TQA vs. Requirements (09-02): REQ(09-02)가 '법전(명세서)'을 작성하는 입법부라면, TQA(09-04)는 그 법전에 근거하여 소프트웨어가 범죄(버그)를 저질렀는지 심판하고 검증하는 사법부입니다. 요구사항이 없으면 테스터는 무엇이 결함인지 판정할 수 없습니다.

3. Counterexample

• 100% 커버리지 맹신 (Coverage Fallacy): "우리 코드는 구문 커버리지(Statement Coverage)가 100%니까 버그가 없어!"라고 주장하는 행위. 100% 커버리지는 '모든 코드가 최소 한 번 실행되었다'는 뜻일 뿐, '모든 비즈니스 로직과 엣지 케이스가 검증되었다'는 뜻이 절대 아닙니다. 예외 처리 로직이 누락되어 있거나, 요구사항 자체를 잘못 구현한 논리적 오류는 커버리지 수치에 잡히지 않습니다.
• 맹목적인 E2E 테스트 도배 (Ice-Cream Cone Anti-pattern): 불안하다는 이유로 브라우저를 띄워 화면을 클릭하는 무거운 E2E(End-to-End) 테스트만 수천 개 짜놓은 상황. 이 테스트들은 실행하는 데 3시간이 걸리며 네트워크 오류로 시도 때도 없이 실패(Flaky)합니다. 현대 테스팅의 물리적 정석은 아주 빠르고 고립된 단위 테스트(Unit)를 수만 개 깔아두고, 느린 E2E는 핵심 결제 시나리오 등에만 극소수로 배치하는 테스트 피라미드(Test Pyramid) 구조입니다.

4. Prerequisites

• 객체 지향 프로그래밍 (Basic): 함수와 클래스의 의존성을 분리(DI)할 줄 알아야 Mock 객체를 주입하여 고립된 단위 테스트를 짤 수 있습니다. (05-01. OOP)
• 요구사항 및 명세 (Recommended): 인수 테스트(Acceptance Test)를 설계하려면 잘 쓰인 사용자 스토리와 수락 기준을 이해할 수 있어야 합니다. (09-02. REQ)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 테스팅의 원칙과 V-모델 (Testing Fundamentals)

• Why to Learn: 무턱대고 아무 값이나 입력하며 테스트하는 것은 시간을 낭비하고 진짜 크리티컬한 버그는 놓치는 최악의 접근법이기 때문입니다.
• What to Learn:
  • Concepts: 테스팅의 7대 원칙 (살충제 패러독스, 오류 부재의 궤변 등).
  • Skills: Verification(우리가 제품을 올바르게 만들었나?) vs Validation(우리가 올바른 제품을 만들었나?) 물리 분별, V-모델(요구사항 $\leftrightarrow$ 인수 테스트, 설계 $\leftrightarrow$ 단위/통합 테스트).
  • Tools: 결함 관리 시스템(Jira).
  • Trade-offs: 완벽한 테스트(Exhaustive Testing)를 추구하다가 제품 출시를 못 하고 망하는 비용 vs 적정 수준에서 위험 기반(Risk-based)으로 테스트를 멈출 줄 아는 타협.
• How to Learn:
  • 1단계: 일상적인 소프트웨어 오류 기사를 스크랩하고, 해당 오류가 요구사항 단계(Validation 실패)인지 코딩 단계(Verification 실패)인지 원인을 역추적해 봅니다.
  • 2단계: 과거에 짠 자신의 코드를 리뷰하며 "같은 테스트 케이스만 계속 반복하면 내성이 생겨 새로운 버그를 못 잡는다"는 '살충제 패러독스'가 어떻게 발생하는지 증명합니다.
• Implement: V-모델의 구조를 그리고, 특정 기능 개발 시 단위 설계, 아키텍처 설계, 요구사항 정의 단계에서 각각 어떤 테스트 문서를 미리 준비해야 하는지 정리한 품질 보증 마스터플랜 초안.

Recommended

Core Topic 02: 블랙박스와 화이트박스 설계 기법 (Test Design Techniques)

• Why to Learn: 무한대에 가까운 모든 입력 조합을 테스트할 수 없으므로, 버그가 서식할 확률이 가장 높은 '경계'와 '분기점'만 핀셋으로 집어내기 위해서입니다.
• What to Learn:
  • Concepts: 블랙박스 테스팅(명세 기반) vs 화이트박스 테스팅(구조 기반).
  • Skills: 동등 분할(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 구문/결정/조건 커버리지(Coverage).
  • Tools: SonarQube, JaCoCo, Coverage.py.
  • Trade-offs: 화이트박스로 if-else 분기를 100% 덮어 코딩 실수를 잡는 것 vs 블랙박스로 요구사항 자체가 누락된 논리적 허점을 잡는 것 간의 상호 보완성.
• How to Learn:
  • 1단계: "비밀번호는 8~15자여야 합니다"라는 명세(블랙박스)에 대해, 무작위로 100개를 테스트하는 대신 [7, 8, 9]와 [14, 15, 16]이라는 정확한 경계값 6개만 도출하여 테스트 케이스를 최적화합니다.
  • 2단계: if (A > 5 && B < 10) 이라는 소스 코드(화이트박스)를 보고, 조건(Condition) 커버리지 100%를 달성하기 위해 A와 B에 들어가야 할 최소한의 입력값 조합 매트릭스를 수학적으로 계산합니다.
• Implement: 로그인, 장바구니 추가, 결제라는 3가지 시나리오에 대해 블랙박스 설계 기법(경계값, 상태 전이)을 적용하여 도출한 15개의 최소/최적 테스트 케이스 명세서.

Practical

Core Topic 03: TDD와 모의 객체, 테스트 피라미드 (Automation & Mocks)

• Why to Learn: 기능 하나 고쳤다고 밤새 시스템 전체를 수동으로 클릭해보는 야근의 굴레를 끊고, 기계가 단 1초 만에 시스템의 무결성을 검증하게 만들기 위함입니다.
• What to Learn:
  • Concepts: TDD(Test-Driven Development)의 Red-Green-Refactor 사이클, 테스트 피라미드(Unit $\rightarrow$ Integration $\rightarrow$ E2E).
  • Skills: 단위 테스트(Unit Test) 작성, 외부 의존성(DB, 외부 API)을 격리하는 Mocking 및 Stubbing 물리.
  • Tools: JUnit/Mockito (Java), PyTest/MagicMock (Python), Jest (JS).
  • Trade-offs: 코딩 속도가 체감상 2배 느려지는 TDD의 엄청난 초기 비용 vs 수정에 대한 두려움을 없애주어 프로젝트 후반부 디버깅 시간을 0으로 수렴시키는 궁극의 유지보수성.
• How to Learn:
  • 1단계: 결제 함수를 짤 때, 외부 PG사(결제 모듈) 서버가 없으면 테스트를 못하는 강결합 상황을 마주합니다. 이를 해결하기 위해 결제 인터페이스를 만들고 무조건 "성공"을 리턴하는 가짜 객체(Mock)를 주입하여 내 비즈니스 로직만 독립적으로 검증하는 쾌감을 느낍니다.
  • 2단계: 코드를 짜기 전에 테스트부터 짜는(Red), 그리고 무조건 통과하게 코딩하는(Green), 마지막으로 지저분한 코드를 정리하는(Refactor) TDD 리듬을 토이 프로젝트에 1시간 동안 강제 적용해 봅니다.
• Implement: 특정 도메인 로직(예: 이자율 계산 로직)에 대해, DB 연결 없이 10ms 이내에 실행되는 100% 고립된 유닛 테스트 코드 세트 및 Mock 객체 설계 구현체.

Advanced

Core Topic 04: 회귀 테스트와 품질 거버넌스 파이프라인 (QA Pipeline & Governance)

• Why to Learn: 내 로컬 컴퓨터에서 통과한 코드가 실제 서버로 올라갔을 때 다른 사람의 코드를 박살 내는 참사를, 배포 1초 전에 자동화 파이프라인이 차단하도록 구축하기 위해서입니다.
• What to Learn:
  • Concepts: 회귀 테스트(Regression Test), 지속적 통합(Continuous Integration) 내의 품질 게이트(Quality Gate).
  • Skills: 결함 밀도(Defect Density) 분석, 정적 코드 분석(Static Analysis), 부하/성능 테스트(Load Testing) 지표(TPS, Latency).
  • Tools: GitHub Actions, SonarQube, JMeter / k6.
  • Trade-offs: "테스트 코드 커버리지 80% 미만이면 배포 취소"라는 강력한 룰(Quality Gate)이 주는 무결성 보장 vs 긴급 핫픽스(Hotfix)를 내보내야 할 때 발목을 잡는 거버넌스의 딜레마.
• How to Learn:
  • 1단계: 코드가 병합(Merge)될 때마다 CI 서버(예: GitHub Actions)가 깨어난 뒤 자동으로 모든 유닛 테스트를 실행하고, 하나라도 실패하면(Red Build) 병합을 강제로 거절하는 물리적 파이프라인을 관찰합니다.
  • 2단계: k6나 JMeter를 사용해 내 API 서버에 "초당 100명의 가상 유저"를 들이부어(Stress Test), 메모리가 터지거나 CPU가 100%를 치며 서버가 죽어버리는 임계점(Bottleneck)을 찾아내고 리포트를 해석합니다.
• Implement: GitHub 저장소에 코드를 Push했을 때 단위 테스트 $\rightarrow$ 정적 코드 분석(SonarQube) $\rightarrow$ 코드 커버리지 리포트를 자동으로 생성하는 CI/QA 자동화 파이프라인(YAML) 설계 및 구현.

7. Terminology

8. References

Primary References

• [P2] SWEBOK v4.0 - Software Testing / Quality — Theoretical foundations.
• [P5] SFIA - Testing / Quality Assurance — Professional competency standards.

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)을 데이터 기반으로 구분하여 원인을 진단 가능한가?