ISTQB CTFL Syllabus 정리 - 1편

1. 테스팅의 기초

1.1 테스팅이란 무엇인가?

• 소프트웨어 테스팅
  • 결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동
  • SW 테스팅은 다양한 활동을 포함하며, 소프트웨어 개발수명주기(SDLC, Software Development LifeCycle)에 따라 달라진다.
• 테스트 대상 (Test Object)
  • 테스트의 대상이 되는 산출물
• Verification & Validation
  • Verification
    • 시스템이 주어진 요구사항을 충족하는지 확인하는 작업
  • Validation
    • 시스템이 운영 환경에서 사용자 또는 기타 이해관계자가 필요한 바를 만족하는지 확인하는 작업
  • 테스팅은 베리피케이션과 밸리데이션을 모두 수행
• 동적 테스팅 & 정적 테스팅
  • 동적 테스팅
    • 소프트웨어를 실행한다.
  • 정적 테스팅
    • 리뷰와 정적 분석을 포함한다.
    • 소프트웨어를 실행하지 않는다.

1.1.1. 테스트 목적

• 일반적인 테스트 목적
  • 작업 산출물 평가
  • 장애 유발 및 결함 식별
  • 테스트 대상에 대해 요구된 커버리지 보장
  • SW 품질 부족으로 인한 리스크 수준의 완화
  • 베리피케이션
  • 이해관계자에게 필요 정보 제공
  • 품질에 대한 자신감 획득
  • 밸리데이션
• 테스팅의 목적은 정황(Context)에 따라 달라질 수 있다.
  • 테스트 대상, 작업 산출물, 테스트 레벨, 리스크, SDLC, 기업 구조, 경쟁사 구도, 시장 출시 시기 등

1.1.2. 테스팅과 디버깅

• 테스팅과 디버깅
  • 테스팅과 디버깅은 별개의 활동
  • 테스팅
    • SW 결함으로 인한 장애를 유발하거나(동적 테스팅) 테스트 대상에 있는 결함을 직접 찾아낸다(정적 테스팅).
  • 디버깅
    • 장애의 원인(결함)을 찾고, 그 원인을 분석하고 제거한다.
    • 일반적인 디버깅 프로세스
      • 장애 재현
      • 분석(결함 찾기)
      • 결함 수정
      • 확인 테스팅(Confirmation Testing)
  • 테스팅은 결함 식별이 핵심
    • 테스팅으로 결함을 식별한 경우 디버깅은 결함을 제거하는 데 중점을 둔다.
• 확인 테스팅 & 리그레션 테스팅
  • 확인 테스팅(Confirmation Testing)
    • 문제가 제대로 수정됐는지 확인하는 테스팅
    • 처음 테스트를 수행한 사람이 다시 수행하는 것이 바람직하다.
  • 리그레션 테스팅(Regression Testing)
    • 수정 사항이 테스트 대상의 다른 부분에 장애를 일으키지 않았는지 확인하기 위해 추가로 수행하는 테스팅

1.2. 테스팅이 왜 필요한가?

• 품질 제어 활동의 일환으로 테스팅은 정해진 범위, 시간, 품질, 제한된 예산 내에서 합의된 테스트 목표를 달성하는 데 도움을 준다.

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

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

1.2.2. 테스팅과 품질 보증(QA)

• 품질 보증(QA, Quality Assurance)과 테스팅이라는 용어를 혼용해서 사용하는 경우가 많지만, 품질 보증과 테스팅은 다르다.
• 테스팅
  • 제품 지향적이고, 적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 교정 접근법
  • 테스팅은 품질 제어의 주요 활동이며, 정형 기법, 시뮬레이션, 프로토타이핑도 품질 제어에 속한다.
• 품질 보증
  • 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법
  • 좋은 프로세스를 올바르게 준수하면 좋은 제품이 만들어진다는 가정을 기반으로 한다.
  • 품질 보증은 개발 및 테스팅 프로세스 모두에 적용되며, 프로젝트에 참여하는 모두의 책임이다.
• 테스트 결과는 품질 보증과 테스팅 모두에 사용된다.
  • 테스팅에서 테스팅 결과는 결함을 수정하는 데 사용하며, 품질 보증에서는 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용한다.

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

• 사람은 오류(실수)를 저지르며 이에 따라 결함(결점, 버그)이 발생하고, 이는 결국 장애로 이어질 수 있다.
• 결함은 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 빌드 파일과 같은 지원 산출물에서 나올 수 있다.
• 소프트웨어 개발수명주기 초기에 만든 산출물의 결함을 발견하지 못할 경우, 이는 종종 수명주기 후반의 산출물의 결함으로 이어지는 경우가 많다.
• 소스 코드에 있는 결함이 실행되면 시스템이 수행해야 할 작업을 수행하지 못하거나, 수행하지 않아야 할 작업을 수행해 장애를 일으킬 수 있다.
  • 실행될 경우 항상 장애를 일으키는 결함도 있지만, 특정 상황에서만 장애를 일으키거나 장애로 이어지지 않는 결함도 있다.
• 장애의 원인이 오류와 결함만 있는 것은 아니다. 환경 조건으로 발생하는 경우도 있다.
• 근본 원인
  • 근본 원인은 문제 발생의 근본적인 이유를 말한다.
  • 근본 원인은 근본 원인 분석을 통해 찾게 된다.
  • 근본 원인 분석은 보통 장애가 발생하거나, 결함을 식별한 경우 수행한다. 
  • 근본 원인을 처리하면 유사한 장애와 결함을 예방하거나, 그 빈도를 줄일 수 있다.

1.3. 테스팅의 원리

• 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.
  • 결함이 발견되지 않았다고 하더라도 그 소프트웨어가 완벽하다는 뜻은 아니다.
• 완벽한 테스팅은 불가능하다.
  • 모든 것을 테스트한다는 것은 매우 간단한 소프트웨어를 제외하고는 불가능하다.
  • 중요한 부분에 테스트 노력을 집중해야 한다.
• 초기 테스팅으로 시간과 비용을 절약할 수 있다.
• 결함은 집중된다.
• 테스트 효과는 줄어든다. (살충제 패러독스)
  • 만일 같은 테스트를 계속해서 반복하면, 결국 해당 테스트의 신규 결함 식별 효과는 점점 줄어들게 된다.
  • 이런 현상을 극복하기 위해 기존 테스트 케이스 및 테스트 데이터의 수정과 새로운 테스트의 작성이 필요할 수 있다.
• 테스팅은 정황에 의존적이다.
• 결함-부재는 궤변이다.
  • 베리피케이션과 함께 밸리데이션도 수행해야 한다.

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

1.4.1. 테스트 활동과 업무

• 테스트 계획
  • 테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법을 선택하는 과정
• 테스트 모니터링과 제어
  • 테스트 모니터링
    • 지속적으로 모든 테스트 활동을 점검하고, 실제 진행 상황을 계획과 비교하는 활동
  • 테스트 제어
    • 테스트 목적을 달성하는 데 필요한 조치를 하는 활동
• 테스트 분석
  • 테스트 베이시스를 분석해 테스트 가능한 기능을 식별하는 활동
  • 관련된 테스트 컨디션은 연관된 리스크와 리스크 수준을 고려해 정의하고, 우선순위를 매긴다.
  • 테스트 분석은 "무엇을 테스트할 것인가?"라는 질문에 측정 가능한 커버리지 조건으로 답을 제공한다.
• 테스트 설계
  • 테스트 컨디션을 테스트 케이스와 기타 테스트웨어(e.g. 테스트 차터)로 구체화하는 작업을 포함한다.
  • 이 활동은 테스트 케이스 입력값을 구체화하는 데 도움이 되는 커버리지 항목의 식별을 포함하는 경우가 많다.
  • 테스트 설계는 "어떻게 테스트할 것인가?"라는 질문에 답을 제공한다.
• 테스트 구현
  • 테스트 실행에 필요한 테스트웨어(e.g. 테스트 데이터)를 만들거나 획득하는 작업을 포함한다.
  • 테스트 케이스는 테스트 절차로 묶을 수 있으며, 테스트 스위트로 조합하는 경우가 많다.
  • 수동 및 자동 테스트 스크립트도 만들게 된다.
  • 효율적인 테스트 실행을 위해 우선순위를 반영한 테스트 실행 일정으로 테스트 절차를 정리한다.
  • 테스트 환경을 구축하고 올바르게 설정되었는지 확인한다.
• 테스트 실행
  • 테스트 실행 일정에 따라 테스트를 수행하는 것을 포함한다.
  • 테스트는 수동이나 자동으로 실행할 수 있다.
  • 테스트 실행은 지속적 테스팅, 페어 테스팅 세션 등 다양한 형태로 이루어질 수 있다.
  • 실제 테스트 결과는 기대 결과와 비교하며, 기록된다.
  • 이상 사항을 분석해 가능한 원인을 파악한다. 이런 분석을 통해 관찰한 장애를 기반으로 이상 사항을 보고할 수 있다. 
• 테스트 완료
  • 일반적으로 프로젝트 마일스톤(e.g. 릴리즈, 반복 주기 완료, 테스트 레벨 완료)에서 수행된다.
  • 해결되지 않은 결함에 대해서는 변경 요청서 또는 제품 백로그 항목을 만든다.
  • 테스트 활동을 분석해 향후 반복 주기, 릴리즈, 프로젝트를 위한 교훈과 개선 사항을 파악한다.
  • 테스트 완료 보고서를 작성해 이해관계자에게 전달한다.

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

• 테스팅의 최종 목표는 이해관계자의 비즈니스 목표 달성을 지원하는 것이다.
• 따라서 테스팅 수행 방식은 여러 정황 요소에 따라 달라진다.
  • 여러 정황 요소는 테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트웨어의 상세화 수준, 테스트 보고 등 많은 테스트 관련 문제에 영향을 미친다.

1.4.3. 테스트웨어

• 테스트웨어는 테스트 활동의 결과물로 만들어진다.
• 조직마다 테스트웨어를 생성/구체화/명명/구성/관리하는 방식에 상당한 차이가 있다.
• 적절한 형상관리는 작업 산출물의 일관성과 무결성을 보장한다.
• 작업 산출물의 일부 목록
  • 테스트 계획 작업 산출물
    • 테스트 계획, 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건
      • 리스크 관리 대장은 리스크 발생 가능성, 리스크 영향도, 리스크 완화 정보가 들어있는 리스크 목록
      • 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건은 종종 테스트 계획서에 포함된다.
  • 테스트 모니터링과 테스트 제어 작업 산출물
    • 테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보
  • 테스트 분석 작업 산출물
    • (우선순위가 지정된) 테스트 컨디션(e.g. 인수 기준)
    • 테스트 베이시스의 결함에 관한 보고서
  • 테스트 설계 작업 산출물
    • (우선순위가 지정된) 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항
  • 테스트 구현 작업 산출물
    • 테스트 절차, 수동 및 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정, 테스트 환경 요소
      • 테스트 환경 요소의 예: 스텁, 드라이버, 시뮬레이터, 서비스 가상화
  • 테스트 실행 작업 산출물
    • 테스트 로그, 결함 보고서
  • 테스트 완료 작업 산출물
    • 테스트 완료 보고서, 향후 프로젝트 또는 반복 주기 때 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서(e.g. 제품 백로그 항목)

1.4.4. 테스팅에서의 역할

• 테스트 관리 역할
  • 테스트 프로세스, 테스트팀, 테스트 활동 리더십에 대한 전반적인 책임을 진다.
  • 주요 관심 영역
    • 테스트 계획, 테스트 모니터링, 테스트 제어, 테스트 완료 활동
  • 수행 방식은 정황에 따라 달라진다.
• 테스팅 역할
  • 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다.
  • 주요 관심 영역
    • 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동
• 상황에 따라 역할을 수행하는 사람이 달라질 수 있다.
• 한 사람이 테스팅과 테스트 관리 역할을 동시에 수행하는 경우도 있다.

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

2.1. 소프트웨어 개발수명주기(SDLC)에서의 테스팅

2.1.1. 소프트웨어 개발수명주기(SDLC)와 좋은 테스팅 프랙티스

• 선택한 SDLC 모델과 무관하게 좋은 테스팅 프랙티스가 있다.
  • 모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어, 모든 개발 활동이 품질 제어의 대상이 되게 한다.
  • 테스트 레벨마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절하면서 포괄적인 테스팅이 가능하게 한다.
  • 특정 테스트 레벨을 위한 테스트 분석과 설계를 SDLC의 상응하는 각 개발 단계에서 시작해 조기 테스팅 원칙을 준수할 수 있게 한다.
  • 테스터가 이들 산출물의 문서 초안이 가용한 즉시 작업 산출물 리뷰에 참여하도록 해서 이 조기 테스팅과 결함 발견이 시프트 레프트 전략을 지원할 수 있도록 한다.

2.1.2. 소프트웨어 개발 주도를 위한 테스팅

• 테스트 주도 개발(TDD)
  • 광범위한 SW 설계 대신 테스트 케이스를 통해 코딩 주도
  • 테스트를 먼저 작성하고 이를 충족하도록 코드를 작성한 다음, 테스트와 코드를 리팩토링
• 인수 테스트 주도 개발(ATDD)
  • 시스템 설계 프로세스 중 인수 조건에서 테스트 도출
  • 테스트는 해당 테스트를 만족해야 할 애플리케이션 영역을 개발하기 전에 작성
• 행위 주도 개발(BDD)
  • 애플리케이션의 기대 동작을 이해관계자가 이해하기 쉽도록, 간단한 자연어로 작성해 테스트 케이스로 표현
    • 일반적으로 Given/When/Then 형태를 사용
  • 이후 테스트 케이스는 자동으로 실행 가능한 테스트로 변환
• 위 모든 접근법에서 테스트는 향후 구현/리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지할 수 있다.

2.1.3. 데브옵스(DevOps)와 테스팅

• 데브옵스는 개발과 운영이 협력해 공통된 목표를 달성하기 위한 시너지 창출을 목표로 하는 조직 차원이 접근법
• 데브옵스는 팀의 자율성, 빠른 피드백, 통합된 도구 체인, 지속적 통합(CI)과 지속적 배포(CD)와 같은 기술 프랙티스를 장려한다.
• 팀은 데브옵스 배포 파이프라인을 통해 높은 품질의 코드를 더 빠르게 빌드/테스트/릴리즈할 수 있다.
• 테스팅 관점에서 데브옵스의 이점
  • 코드 품질, 그리고 변경 사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.
  • 지속적 통합은 개발자가 컴포넌트 테스트 및 정적 분석과 함께 높은 품질의 코드를 제출하도록 장려함으로써 시프트 레프트 테스팅 접근법을 장려한다.
  • 안정적인 테스트 환경 구축을 촉진하는 CI/CD와 같은 자동화 프로세스를 장려한다.
  • 비기능 품질 특성(e.g. 성능 효율성, 신뢰성)에 대한 가시성이 향상된다.
  • 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다.
  • 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다. 
• 데브옵스의 리스크와 어려움
  • 데브옵스 배포 파이프라인을 정의하고 설정해야 한다.
  • CI/CD 도구를 도입하고 유지보수해야 한다.
  • 테스트 자동화를 위한 추가 자원이 필요하며, 그것을 설정 및 유지보수하기가 어려울 수 있다.
• 데브옵스는 높은 수준의 테스팅 자동화를 동반하지만, 수동 테스팅 또한 (특히 사용자 관점에서) 여전히 필요하다.

2.1.4. 시프트 레프트 접근법 (Shift Left)

• 조기 테스팅 원리는 테스틀 SDLC 초기에 수행하도록 하는 접근법이기 때문에 시프트 레프트라고 지칭하기도 한다.
• 시프트 레프트는 기본적으로 테스트를 더 일찍 수행해야 한다는 것을 의미하지만, 그렇다고 SDLC 후반의 테스트를 무시해도 된다는 의미는 아니다.
• 테스팅에서 시프트 레프트를 달성하는 좋은 프랙티스
  • 테스트 관점에서 명세를 리뷰한다. 이런 명세 리뷰 활동을 통해 모호성, 불완전성, 불일치 등 잠재적 결함을 발견하는 경우가 많다.
  • 코드를 작성하기 전에 테스트 케이스를 작성하고, 코드 구현 중 코드를 테스트 하네스에서 실행한다.
  • 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 지속적인 통합, 가능하다면 지속적인 배포까지 적용한다.
  • 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적 분석을 완료한다.
  • 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다. 비기능 테스트는 완성 시스템과 실제 환경을 대변하는 테스트 환경이 가용한 SDLC 후반에 수행하는 경향이 있으므로 이는 일종의 시프트 레프트가 된다.
• 시프트 레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비용의 절감을 기대할 수 있다.
• 시프트 레프트 접근법을 위해서는 이해관계자들이 개념을 이해하고 받아들이는 것이 중요하다.

2.1.5. 회고 및 프로세스 개선

• 회고는 프로젝트나 반복 주기가 끝날 때, 릴리즈 마일스톤에서, 또는 필요시 진행할 수 있다.
• 회고의 시기와 구성은 사용 중인 SDLC 모델에 따라 달라진다.
• 이 회의에서 참가자는 다음에 대해 논의한다.
  • 무엇이 성공적이었고, 유지해야할 것은 무엇인가?
  • 무엇이 부족했고, 개선할 수 있는 점은 무엇인가?
  • 향후 개선 사항을 도입하고 성공 요소를 유지하려면 어떻게 해야 하는가?
• 결과는 기록해야 하며, 이를 테스트 완료 보고서에 포함하는 경우가 많다.
• 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어지는 것이 중요하다.
• 테스팅 관점에서 일반적인 이점은 다음과 같다.
  • 테스트 효과성/효율성 향상
  • 테스트웨어 품질 향상
  • 팀의 결속 및 학습 향상
  • 테스트 베이시스 품질 개선
  • 개발과 테스팅 간의 협업 개선

2.2. 테스트 레벨과 테스트 유형

• 테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.
• 각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.
• 단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템일 수도 있다.

2.2.1. 테스트 레벨

• 컴포넌트 테스팅(단위 테스팅)
  • 컴포넌트를 개별적으로 테스트하는 데 중점을 둔다.
  • 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많다.
  • 일반적으로 개발자가 자신의 개발 환경에서 수행한다.
• 컴포넌트 통합 테스팅(단위 통합 테스팅)
  • 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점을 둔다.
  • 상향식, 하향식, 빅뱅 등 통합 전략에 따라 크게 달라진다.
• 시스템 테스팅
  • 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점을 두며, 엔드투엔드 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많다.
  • 실제 환경을 대변하는 테스트 환경에서 완성된 시스템으로 테스트하는 것을 선호하는 비기능 품질 특성도 있다(e.g. 사용성).
  • 서브-시스템에 대한 시뮬레이션을 사용하기도 한다.화
  • 시스템 테스팅은 독립된 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있다.
• 시스템 통합 테스팅
  • 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점을 둔다.
  • 시스템 통합 테스팅은 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용한다.
• 인수 테스팅
  • 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점을 둔다.
  • 인수 테스팅은 실제 사용자가 수행하는 것이 이상적이다. 인수 테스팅의 주요 유형으로는 사용자 인수 테스팅(UAT), 운영 인수 테스팅, 계약 인수 테스팅과 규제 인수 테스팅, 알파 테스팅, 베타 테스팅 등이 있다.
• 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다음과 같은 다양한 속성을 고려해 구분한다.
  • 테스트 대상
  • 테스트 목적
  • 테스트 베이시스
  • 결함과 장애
  • 접근법과 역할

2.2.2. 테스트 유형

• 기능 테스팅
  • 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가한다.
  • 기능은 테스트 대상이 '무엇을' 해야 하는지를 의미한다.
  • 주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것이다.
• 비기능 테스팅
  • 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가한다.
  • 비기능 테스팅은 "시스템이 얼마나 잘 동작하는지" 테스트하는 것이다.
  • 주요 목적은 비기능 품질 특성을 확인하는 것이다.
  • SDLC 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다.
  • 비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.
  • 비기능 테스팅은 매우 특수한 테스트 환경이 필요한 경우도 있다. (e.g. 유용성 테스팅의 유용성 랩)
• 블랙박스 테스팅
  • 명제를 기반으로 하며, 테스트 대상의 내부 구조와 관련 없는 문서로부터 테스트를 도출한다.
  • 주요 목적은 명세와 비교해 시스템의 동작을 확인하는 것이다.
• 화이트박스 테스팅
  • 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출한다.
  • 주요 목적은 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것이다.
• 위에서 언급한 네 가지 테스트 유형은 모든 테스트 레벨에서 사용할 수 있지만, 레벨마다 관심의 대상은 다를 수 있다. 언급한 테스트 유형 모두 테스트 컨디션과 테스트 케이스를 도출하기 위해 다양한 테스트 기법을 사용할 수 있다.

2.2.3. 확인 테스팅 및 리그레션 테스팅

• 확인 테스팅
  • 원래 결함이 성공적으로 수정됐는지 확인한다.
  • 리스크에 따라 다음과 같은 여러 가지 방법으로 수정된 SW 버전을 테스트할 수 있다.
    • 해당 결함으로 인해 이전에 실패했던 모든 테스트 케이스를 실행
    • 해당 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트 케이스 추가
  • 결함을 수정하는 데 시간이나 비용이 부족한 경우, 확인 테스팅은 해당 결함으로 생긴 장애를 재현하기 위한 테스트 절차를 거쳐 장애가 다시 발생하지 않았는지만 확인하는 수준으로 제한될 수 있다.
• 리그레션 테스팅
  • 변경으로 인해 부정적 영향이 없었는지 확인하는 것이다.
  • 리그레션 테스트 스위트는 반복적으로 실행되며, 반복 주기 또는 릴리즈 때마다 리그레션 테스트 케이스 수가 늘어나게 되므로, 리그레션 테스트는 자동화하기 매우 적합한 대상이 된다.
    • 이런 테스트의 자동화는 프로젝트 초기에 시작해야 한다.
  • 데브옵스와 같이 지속적 통합을 사용하는 경우, 자동 리그레션 테스트를 포함하는 것이 좋은 프랙티스이다.
• 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.