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

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

• 소프트웨어 개발수명주기(SDLC) 모델은 상위 수준에서 소프트웨어 개발 프로세스를 추상화해서 표현한 것이다.
• 소프트웨어 개발수명주기(SDLC) 모델의 예
  • 순차적 개발 모델(ex. 폭포수 모델, V-모델)
  • 반복적 개발 모델(ex. 나선형 모델, 프로토타이핑)
  • 점진적 개발 모델(ex. 통합 프로세스)
• 소프트웨어 개발 프로세스 내 일부 활동을 구체적인 소프트웨어 개발 방법과 애자일 실천법으로 설명하기도 한다.
  • 인수 테스트 주도 개발(ATDD)
  • 행위 주도 개발(BDD)
  • 도메인 주도 설계(DDD)
  • 익스트림 프로그래밍(XP)
  • 기능 주도 개발(FDD)
  • 칸반(Kanban)
  • 린(lean) IT
  • 스크럼(Scrum)
  • 테스트 주도 개발(TDD)

2.1.1. 소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향

• 소프트웨어 개발수명주기(SDLC) 모델의 선택은 다음에 영향을 미친다.
  • 테스트 활동 범위 및 시기(ex. 테스트 레벨 및 테스트 유형)
  • 테스트 문서 상세화 수준
  • 테스트 기법 및 테스트 접근법 선택
  • 테스트 자동화 범위
  • 테스터의 역할과 책임

2.1.2 소프트웨어 개발수명주기(SDLC)와 우수한 테스팅 프랙티스

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

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

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

2.1.4 데브옵스(DevOps)와 테스팅

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

2.1.5. 시프트-레프트 접근법

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

2.1.6. 회고 및 프로세스 개선

• 회고는 프로젝트나 반복 주기가 끝날 때, 릴리스 마일스톤에서, 또는 필요시 진행할 수 있다.
• 회고의 시기와 구성은 사용 중인 소프트웨어 개발수명주기(SDLC) 모델에 따라 달라진다.
• 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어 지는 것이 중요하다.

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

• 테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.

2.2.1. 테스트 레벨

• 다섯 가지 테스트 레벨
  • 컴포넌트 테스팅
  • 컴포넌트 통합 테스팅
  • 시스템 테스팅
  • 시스템 통합 테스팅
  • 인수 테스팅
• 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다음과 같은 다양한 속성을 고려해 구분한다:
  • 테스트 대상
  • 테스트 목적
  • 테스트 베이시스
  • 결함과 장애
  • 접근법과 역할

2.2.2. 테스트 유형

• 기능 테스팅
• 비기능 테스팅
• 블랙박스 테스팅
• 화이트박스 테스팅

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

• 일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수 정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다

2.3. 유지보수 테스팅

• 유지보수 테스팅의 범위는 일반적으로 다음에 따라 달라진다
  • 변경의 리스크 수준
  • 기존 시스템의 크기
  • 변경사항의 크기