1-1. 테스팅이란 무엇인가?

 

  • 테스팅 목적 및 의미 : 소프트웨어 품질을 평가하고 장애 위험을 줄이기 위함. 결함을 식별하고 산출물(test object)의 품질을 평가하는 활동.
  • 오해 :
    • 단순히 실행과 결과 확인만 하는 것 → 실제로는 다양한 활동을 포함(예: SDLC).
    • 베리피케이션(요구사항 확인)만 한다는 것 → 검증(Verification) + 확인(Validation) 모두 포함.
  • 방법:
    • 동적 테스팅: 소프트웨어 실행
    • 정적 테스팅: 실행 없이 리뷰, 정적 분석 등
  • 활동 범위: 기술적 활동뿐 아니라 계획, 관리, 추정, 모니터링, 제어까지 포함.
  • 테스터 역할: 도구 활용 가능하지만, 본질은 비판적·시스템적 사고를 적용한 지적 활동.
  • 표준: ISO/IEC/IEEE 29119-1에 개념이 상세히 정의됨.

 

1-1-1. 테스트 목적

  • 산출물(요구사항, 설계, 코드 등) 평가
  • 결함 및 장애 발견
  • 요구된 커버리지 확보
  • 리스크 완화 (품질 부족으로 인한 위험 줄이기)
  • 요구사항·법률·규제 준수 여부 베리피케이션
  • 이해관계자에게 의사결정에 필요한 정보 제공
  • 소프트웨어 품질에 대한 자신감 확보
  • 완성 여부와 기대 충족 확인하는 밸리데이션

👉 목적은 상황(리스크, SDLC, 비즈니스 환경 등)에 따라 달라진다.

 

1-1-2. 테스팅과 디버깅

 

  • 테스팅: 결함을 드러내거나 발견하는 활동 (장애 유발(동적), 직접 결함 식별(정적))
  • 디버깅: 드러난 결함의 원인 찾기·분석·수정
    • 동적 테스팅 절차: 장애 재현 → 원인 분석 → 결함 수정
  • 확인 테스팅: 수정된 부분이 제대로 고쳐졌는지 확인 (원래 테스터가 다시 수행하는 게 바람직)
  • 리그레션 테스팅: 수정으로 인해 다른 부분에 문제 없는지 확인
  • 정적 테스팅: 장애 발생 없이 결함 직접 발견 → 재현·분석 과정 불필장

 

 

1-2. 테스팅이 왜 필요한가?

 

  • 제한된 범위·시간·비용 내에서 테스트 목표 달성 지원
  • 팀뿐만 아니라 모든 이해관계자가 기여 가능
  • 컴포넌트·시스템·문서 등 대상에서 결함 식별이 도움 가능

 

1-2-1. 테스팅이 성공에 기여하는 방법

  • 비용 효율적인 결함 식별 → 디버깅을 통해 제거 가능 → 품질 향상에 간접 기여
  • SDLC 여러 단계에서 품질 직접 평가 → 결과는 관리 의사결정(예: 릴리스 여부 판단)에 활용
  • 사용자 간접 대변 → 요구사항이 반영되도록 지원 (실제 사용자 참여는 비용·현실적 제약 때문에 어려움)
  • 계약·법적 요구·규제 준수 보장을 위해 필요

 

1-2-2. 테스팅과 품질 보증(QA)

  • 테스팅
    • 제품 지향, 교정적 접근(corrective)
    • 목표: 제품에서 결함을 찾아 품질 수준을 확보
    • 활동: 테스트, 정형 기법, 시뮬레이션, 프로토타이핑 등 품질 제어(QC)의 일부
  • 품질 보증(QA)
    • 프로세스 지향, 예방적 접근(preventive)
    • 가정: 좋은 프로세스를 지키면 좋은 제품이 나온다
    • 개발 + 테스팅 프로세스 전체를 포함, 모두의 책임
  • 테스트 결과 활용
    • 테스팅 → 결함 수정에 활용
    • QA → 프로세스 개선 및 검증에 활용

 

1-2-3. 오류, 결함, 장애, 근본 원인

  • 오류(Error): 사람의 실수 (원인: 시간 압박, 복잡성, 피로, 훈련 부족 등)
  • 결함(Defect, Bug): 오류로 인해 산출물(요구사항, 설계, 코드, 빌드 등)에 생긴 문제
    • 초기 결함을 놓치면 후반 산출물에도 이어짐
  • 장애(Failure): 결함이 실행되어 시스템이 잘못 동작하는 현상
    • 항상 장애로 이어지진 않음 (특정 조건에서만 나타날 수도 있음)
  • 근본 원인(Root Cause): 오류·결함 외에도 외부 요인(환경적 요인 → 방사선, 전자기장 등)으로 발생할 수도 있음

 

 

1-3. 테스팅의 원리

1. 결함이 존재함을 증명할 순 있지만, 무결함을 증명할 순 없음

2. 완벽한 테스팅은 불가능함

3. 조기 테스팅으로 비용 절감 가능

4. 결함은 집중됨(파레토 원리)

5. 같은 테스트를 반복하면 테스트 효과가 감소한다. 

6. 테스팅은 정황에 의존적이므로 정황에 따라 다르게 진행해야 함.

7. 결함 - 부재는 궤변이다.
결함이 없다고해서 성공이 보장되지 않음. 검증(벨리피케이션)뿐 아니라 확인(벨리데이션)이 필요함

 

 

1-4. 테스트 활동, 테스트웨어, 테스트 역할

1-4-1. 테스트 활동과 업무

테스트 프로세스는 순차적인 것처럼 보이지만 반복적 또는 병렬적으로 진행됨

1. 테스트 계획 : 목적 정의, 제약 조건을 고려한 접근 방식 수립

2. 테스트 모니터링 및 제어 : 진행 사황 점검 및 계획 대비, 필요 시 조정

3. 테스트 분석 : 테스트 베이시스를 분석해 테스트 컨디션 및 리스크(수준) 식별, 커버리지 조건을 제공

4. 테스트 설계 : 테스트 컨디션을 테스트 케이스와 테스트 차터로 설계, 환경 및 데이터 요구사항 식별 및 정의

5. 테스트 구현 : 테스트웨어(테스트 데이터)를 생성, 테스트 케이스를 테스트 절차로 묶거나, 스크립트 및 테스트 스위트 등으로 구체화 → 우선순위를 반영하여 절차 정리, 테스트 환경 구축

6. 테스트 실행 : 수동 or 자동 방식으로 테스트 런, 결과 비교 및 기록 

7. 테스트 완료 : 마일스톤(예: 릴리스, 반복 주기 완료, 테스트 레벨 완료)에서 수행 →  해결되지 않은 결함 관리(변경 요청서, 제품 백로그 항목), 테스트웨어 보관, 교훈 도출 및 테스트 완료 보고서 작성

 

1-4-2. 정황에 따른 테스트 프로세스

영향을 주는 요소들:

  • 이해관계자(요구사항, 기대 등)
  • 팀 역량(기술 수준, 경험)
  • 비즈니스 도메인(중요도, 법적 규제)
  • 기술적 요인(아키텍처, 기술 스택)
  • 프로젝트 제약(시간, 예산, 자원)
  • 조직적 요인(정책, 프랙티스)
  • 개발 수명주기 모델(SDLC)
  • 사용 가능한 도구 등

정황은 테스트 전략, 기법, 자동화 수준, 커버리지, 보고 방식 등에 직접적인 영향을 줌.

 

1-4-3. 테스트웨어

- 단계별로 나온 작업 산출물

1. 테스트 계획 : 테스트 계획서(테스트일정, 리스크 관리 대장, 시작/완료 조건) 

2. 테스트 모니터링 및 테스트 제어 : 진행 사항 보고서, 제어 지침 문서, 리스크 정보

3. 테스트 분석 : 테스트 컨디션, 테스트 베이시스의 결함에 관한 결함 보고서

4. 테스트 설계 : 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항

5. 테스트 구현 : 테스트 절차, 테스트 스위트, 테스트 스크립트, 테스트 데이터, 테스트 환경 구성요소

6. 테스트 실행 : 테스트 로그, 결함 보고서

7. 테스트 완료 : 테스트 완료 보고서, 개선 항목, 교훈, 변경 요청서

※ 테스트웨어는 형상관리 대상 → 일관성, 무결성 유지 필수

1-4-4. 테스트 베이시스와 테스트웨어 간 추적성

추적성(Traceability)을 구축하는 것이란?

테스트 베이시스(요구사항, 설계 문서 등)와 테스트웨어(컨디션, 케이스, 결과, 결함), 테스트 결과, 결함간의 연결 관계를 명확히 하는 것

 

  • 추적성 목적
    • 커버리지 평가 : 테스트 케이스가 요구사항을 얼마나 커버하는지 확인
    • 리스크 추적 : 테스트 결과와 리스크를 연결하는 잔존 리스크 수준 평가
    • 변경 영향 분석 : 어떤 테스트에 영향을 줄지 빠르게 파악 가능
    • 테스트 감사 지원 : 테스트 활동의 근거와 흐름을 명확하게 제시
    • IT 거버넌스 대응 : 조직의 정책 및 규제 준수 측면에서 중요
    • 보고서 품질 향상 : 테스트 진행/완료 보고서 작성이 쉬워짐
    • 이해관계자 설득 : 기술 내용을 이해하기 쉬운 방식으로 전달 가능
    • 비즈니스 가치 평가 : 제품 품질, 프로세스 능력, 프로젝트 상태 등의 평가에 활용 가능
  • 추적성 예시
    • 요구사항 → 테스트 케이스:
      요구사항이 테스트로 검증되고 있는지 확인
    • 테스트 결과 → 리스크:
      잔존 리스크의 수준 평가

 

1-4-5. 테스팅에서의 역할

주요 테스팅 역할 2가지로, 조직 규모, 프로젝트 성격, 팀 역량에 따라 유연하게 분배되기도 함

 

1. 테스트 관리 역할 : 테스트 관리자는 방향 설정과 리더십 중심

  • 책임 범위 : 테스트 프로세스 및 전체 팀 운영
  • 주요 활동 : 테스트 계획, 모니터링, 제어, 완료
  • 수행 방식은 정황별 조정 됨 : 애자일 팀에서는 일부 업무가 분산될 수 있음
  • 예시 역할 : 테스트 관리자, 팀 리더, 개발 관리자 등

2. 테스팅 역할 : 실제 테스트 작업의 실행자

  • 책임 범위 : 테스트의 기술적/공학적 실행 중심
  • 주요 활동 : 테스트 분석, 설계, 구현, 실행
  • 정황별 조정 : 조직 구조, 프로젝트 성격에 따라 유동적
  • 예시 역할 : 테스트 엔지니어, QA 담당자

 

Rabet
Rabet

티스토리툴바