[ISTQB_FL] 2장 - 소프트웨어 개발수명주기(SDLC)와 테스팅

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

---

 

• 소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향
  • 테스트 활동 범위 및 시기(예: 테스트 레벨 및 테스트 유형) , 테스트 문서 상세화 수준 , 테스트 기법 및 테스트 접근법 선택 , 테스트 자동화 범위 , 테스터의 역할과 책임
• 소프트웨어 개발수명주기(SDLC) 모델의 예
  • 순차적 개발 모델(예: 폭포수 모델, V-모델)에서는 초기에 동적 테스팅을 수행하기 어렵다. (개발 후에 코드 실행이 가능하므로)
  • 반복적 점진적 개발 모델(예: 나선형 모델)에서는 반복 주기마다 모든 테스트 레벨에서 정적 테스팅과 동적 테스팅을 수행할 수 있다.
  • 애자일 소프트웨어 개발에서는 리그레션 테스팅을 수월하게 하는 테스트 자동화, 경험 기반 테스트를 선호한다. 

[CSTS 요약 정리] 1. 테스트 개요

[CSTS 요약 정리] 1. 테스트 개요

---

• 모든 소프트웨어 개발수명주기(SDLC)에 적용되는 좋은 테스팅 사례
  • 모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어, 모든 개발 활동이 품질 제어의 대상이 되게 한다.
  • 테스트 레벨마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절하면서 포괄적인 테스팅이 가능하게 한다.
  • 특정 테스트 레벨을 위한 테스트 분석과 설계를 소프트웨어 개발수명주기(SDLC)에 각 개발 단계에서 시작 (조기 테스팅)
  • 테스터가 문서 초안이 제공되는 즉시 작업 산출물을 리뷰 (조기 테스팅)

---

• 소프트웨어 개발 주도를 위한 테스팅
  • 테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 코드 작성 전에 테스트를 정의하여, 시프트-레프트 접근법(조기 테스팅 원리)을 따른다.

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

---

• 테스팅 관점에서 데브옵스(DevOps) 의 이점
  • 데브 옵스 배포 파이프라인(pipeline)을 통해 높은 품질의 코드를 더 빠르게 빌드/테스트/릴리스할 수 있다.
  • 코드 품질, 그리고 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.
  • 지속적 통합은 개발자가 컴포넌트 테스트 및 정적분석과 함께 높은 품질의 코드를 제출하도록 한다. (시프트-레프트 접근법)
  • 안정적인 테스트 환경 구축을 촉진하는 지속적 통합(CI)/지속적 배포(CD)와 같은 자동화 프로세스를 장려한다. 
  • 비기능 품질 특성(예: 성능, 신뢰성)의 가시성을 높여준다.
  • 데브 옵스 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다.
  • 자동화된 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.
• 데브옵스(DevOps) 의 리스크
  • 데브옵스 배포 파이프라인을 정의하고 설정해야 한다
  • 지속적 통합/지속적 배포 도구를 도입하고 유지보수해야 한다.
  • 테스트 자동화를 위한 추가 자원이 필요하며, 이를 설정 및 유지보수해야 한다.

---

• 시프트-레프트 접근법 : 테스트를 소프트웨어 개발수명주기(SDLC) 초기에 수행하도록 하는 접근법 ( 테스트 우선 접근법 )

다음은 일부 예시이다.

• 테스팅 관점에서 명세를 리뷰한다. 

• 코드를 작성하기 전에 테스트 케이스를 작성

• 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 지속적인 통합, 가능하다면 지속적인 배포까지 적용한다.

• 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적분석을 완료한다.

• 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다.  

 

---

테스트 레벨과 테스트 유형

 

---

 

• 테스트 레벨
  • 컴포넌트 테스팅(단위 테스팅) : 컴포넌트를 개별적으로 테스트. 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많다. 일반적으로 개발자가 자신의 개발 환경에서 수행한다.
  • 컴포넌트 통합 테스팅(단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트. 컴포넌트 통합 테스팅은 상향식, 하향식, 빅뱅 등 통합 방식에 따라 달라진다.
  • 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능을 테스트. 엔드투엔드 (end-to-end) 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅(예: 사용성, 보안성)을 포함하는 경우가 많다. 서브-시스템에 대한 시뮬레이션을 사용하기도 한다. 시스템 테스팅은 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있다.
  • 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점을 둔다.  
  • 인수 테스팅 : 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인. (실제 사용자가 테스팅하는 것이 이상적)

---

• 테스트 유형
  • 기능 테스팅 : 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가
    • 기능 테스팅의 주요 목적: 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성) 확인
  • 비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가
    • 비기능 테스팅의 주요 목적: 비기능 소프트웨어 품질 특성(수행 효율성, 호환성, 유용성, 신뢰도, 보안, 유지 가능성(유지 관리성), 이동성) 을 확인 
  • 블랙박스 테스팅 : 명세 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출. 
  • 화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조(예: 코드, 아키텍처, 워크플로우, 데이터 플로우)에서 테스트를 도출

---

• 확인 테스팅과 리그레션 테스팅
  • 확인 테스팅 : 결함이 성공적으로 수정됐는지 확인 (ex. 실패했던 모든 테스트 케이스를 실행)
  • 리그레션 테스팅 :  변경으로 인해 부정적인 영향이 없는지 확인

 

---