[CTFL] 2장. 소프트웨어 개발수명주기와 테스팅

#ISTQB

ISTQB-CTFL 실라버스 2장 정리하기

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

용어

인수 테스팅: 사용자의 요구사항과 비즈니스 프로세스를 충족하는지 검증하는 테스트
블랙박스 테스팅: 내부 구조를 고려하지 않고 명세를 기반으로 테스트를 설계하는 기법
화이트박스 테스팅: 내부 구조와 구현 정보를 기반으로 테스트를 설계하는 기법
컴포넌트 통합 테스팅: 개별 컴포넌트 간 인터페이스와 상호작용을 검증하는 테스트
컴포넌트 테스팅: 개별 컴포넌트를 독립적으로 검증하는 테스트
확인 테스팅: 수정된 결함이 정상적으로 해결되었는지 확인하는 테스트
기능 테스팅: 시스템이 요구된 기능을 올바르게 수행하는지 평가하는 테스트
통합 테스팅: 여러 컴포넌트 또는 시스템 간의 상호작용을 검증하는 테스트
유지보수 테스팅: 변경 또는 수정 이후 시스템이 정상 동작하는지 검증하는 테스트
비기능 테스팅: 성능, 보안, 사용성 등 기능 외 품질 특성을 평가하는 테스트
리그레션 테스팅: 변경으로 인해 기존 기능에 부정적 영향이 발생하지 않았는지 확인하는 테스트
시프트 레프트: 테스트 활동을 SDLC 초기에 수행하여 결함을 조기에 발견하는 접근법
시스템 통합 테스팅: 시스템과 외부 시스템 간 인터페이스를 검증하는 테스트
시스템 테스팅: 통합된 전체 시스템이 요구사항을 만족하는지 검증하는 테스트
테스트 레벨: 공통된 테스트 목적과 특성을 가진 테스트 활동의 집합
테스트 대상: 테스트를 수행하는 컴포넌트 또는 시스템
테스트 유형: 특정 품질 특성에 초점을 맞춘 테스트 활동의 분류
핫픽스: 운영 중인 시스템의 긴급 결함을 신속하게 수정하여 배포하는 패치

2.1 SDLC에서의 테스팅

SDLC 모델은 상위 수준에서 소프트웨어 개발 프로세스를 추상적으로 표현한 것이다. SDLC 모델은 개발 프로세스의 여러 단계와 활동 유형이 논리적, 시간상으로 서로 어떻게 연관되는지 정의한다. SDLC 모델의 예로 순차적 개발 모델(예: 폭포수 모델, V-모델), 반복적 개발 모델(예: 나선형 모델, 프로토타이핑), 점진적 개발 모델(예: 통합 프로세스) 등이 있다.

소프트웨어 개발 프로세스 내 일부 활동을 구체적인 소프트웨어 개발 방법과 애자일 프랙티스로 설명하기도 한다.

2.1.1 SDLC가 테스팅에 미치는 영향

테스팅의 성공을 위해 소프트웨어 개발수명주기에 맞는 조정이 필요하다. SDLC 모델의 선택은 다음에 영향을 미친다.

  • 테스트 활동 범위 및 시기
  • 테스트 문서 상세화 수준
  • 테스트 기법 및 테스트 접근법 선택
  • 테스트 자동화 범위
  • 테스터의 역할과 책임

일반적으로 순차적 개발 모델에서 테스터는 초기 단계에서 요구사항 리뷰, 테스트 분석과 설계에 참여한다. 실행 가능한 코드는 보통 개발 후반에 생성되므로 동적 테스팅은 SDLC 초기에 수행하기 어려운 경우가 많다.

일부 반복적 개발 모델과 점진적 개발 모델에서는 각 반복 주기마다 동작하는 프로토타입이나 제품 증분이 만들어진다고 가정한다. 이는 반복 주기마다 모든 테스트 레벨에서 정적 테스팅과 동적 테스팅을 수행할 수 있음을 의미한다. 증분을 자주 전달하려면 빠른 피드백과 광범위한 리그레션 테스팅이 필요하다.

애자일 프로젝트는 리그레션 테스팅을 수월하게 하는 가벼운 작업 산출물과 테스트 자동화를 선호하게 된다. 또한 수동 테스팅도 사전 테스트 분석과 설계가 필요하지 않은 경험 기반 테스트 기법으로 진행하는 경향이 있다.

2.1.2 SDLC와 좋은 테스팅 프랙티스

선택한 SDLC 모델에 상관없이 다음과 같은 좋은 테스팅 프랙티스가 있다.

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

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

테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다. 이런 각 접근법은 코드 작성 전에 테스트를 정의하므로 조기 테스팅 원리와 시프트 레프트 접근법을 따르게 한다. 반복적 개발 모델을 지원하며 다음과 같은 특징을 가진다.

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

위의 모든 접근법에서 테스트는 향후 구현/리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지할 수 있다.

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

데브옵스는 개발(테스팅 포함)과 운영이 협력해 공통된 목표를 달성하기 위한 시너지 창출을 목표로 하는 조직 차원의 접근법이다. 데브옵스는 개발과 운영이 가진 생각의 차이를 줄임과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 하는 조직문화의 변화가 필요하다. 팀은 데브옵스 배포 파이프라인을 통해 높은 품질의 코드를 더 빠르게 빌드/테스트/릴리스 할 수 있다.

테스팅 관점에서 데브옵스의 이점은 다음과 같다.

  • 코드 품질, 그리고 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.
  • 지속적 통합(CI)은 개발자가 컴포넌트 테스트 및 정적 분석과 함께 높은 품질의 코드를 제출하도록 장려함으로써 시프트 레프트 테스팅 접근법을 장려한다.
  • 안정적인 테스트 환경 구축을 촉진하는 CI/CD 같은 자동화 프로세스를 장려한다.
  • 비기능 품질 특성에 대한 가시성이 향상된다.
  • 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다.
  • 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.

데브옵스도 다음과 같은 리스크와 어려움을 가진다.

  • 데브옵스 배포 파이프라인을 정의하고 설정해야 한다.
  • CI/CD 도구를 도입하고 유지보수해야 한다.
  • 테스트 자동화를 위한 추가 자원이 필요하며 그것을 설정 및 유지보수하기가 어려울 수 있다.

데브옵스는 높은 수준의 테스팅 자동화를 동반하지만 수동 테스팅 또한 여전히 필요하다.

2.1.5 시프트 레프트 접근법

조기 테스팅 원리는 테스트를 SDLC 초기에 수행하도록 하는 접근법이기 때문에 시프트 레프트라고 지칭하기도 한다.

시프트 레프트 접근법에서 SDLC 후반의 테스트를 무시하도록 하지는 않는다.

테스팅에서 시프트 레프트를 달성하는 좋은 프랙티스가 있으며 다음은 그중 일부이다.

  • 테스터 관점에서 명세를 리뷰한다.(모호성, 불완전성, 불일치 등 잠재적인 결함을 발견하는 경우가 많다.)
  • 코드를 작성하기 전에 테스트케이스를 작성하고 코드 구현 중 코드를 테스트 하네스에서 실행한다.
  • 빠른 피드백을 제공하고 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함게 제출하도록 하는 CI를 가능하다면 CD까지 적용한다.
  • 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적 분석을 완료한다.
  • 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다.

2.1.6 회고 및 프로세스 개선

회고는 프로젝트나 반복 주기가 끝날 때 릴리스 마일스톤에서 또는 필요시 진행할 수 있다. 회고의 시기와 구성은 SDLC 모델에 따라 달라진다.

결과는 기록해야 하며 이를 테스트 완료 보고서에 포함하는 경우가 많다.

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

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

테스트 레벨은 SDLC 내의 다른 활동과 연관성을 가진다. 순차적 SDLC 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다. 또 이것과는 다른 반복적 모델도 있다. 개발 활동이 여러 테스트 레벨에 걸쳐 진행되고 시간이 지나면서 테스트 레벨이 서로 겹치기도 한다.

테스트 유형은 특정 품질 특성 관련된 테스트 활동의 집합으로 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.

2.2.1 테스트 레벨

CTFL 실러버스는 다음 다섯 가지 테스트 레벨을 설명한다.

  • 컴포넌트 테스팅(단위 테스팅)
  • 컴포넌트 통합 테스팅(단위 통합 테스팅)
  • 시스템 테스팅
  • 시스템 통합 테스팅
  • 인수 테스팅

테스트 레벨은 테스트 활동의 중복을 피하기 위해 다음과 같은 다양한 속성을 고려해 구분한다.

  • 테스트 대상
  • 테스트 목적
  • 테스트 베이시스
  • 결함고 장애
  • 접근법과 역할

2.2.2 테스트 유형

프로젝트에 다양하게 적용할 수 있는 여러 테스트 유형이 있다. 실러버스는 다음 네 가지 테스트 유형을 다룬다.

  • 기능 테스팅: 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가한다. 주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것이다.
  • 비기능 테스팅: 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가한다.
    • 수행 효율성
    • 호환성
    • 유용성(상호작용 능력)
    • 신뢰도
    • 보안
    • 유지 가능성
    • 이동성(유연성)
    • 안전성
  • 블랙박스 테스팅: 명세를 기반으로 하며 테스트 대상의 내부 구조와 관련 없는 문서로부터 테스트를 도출한다. 주요 목적은 명세와 비교해 시스템의 동작을 확인하는 것이다.
  • 화이트박스 테스팅: 구조 기반이며 시스템의 구현 또는 내부 구조에서 테스트를 도출한다.

2.2.3 확인 테스팅과 리그레션 테스팅

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

  • 확인 테스팅: 원래 결함이 성공적으로 수정됐는지 확인한다.
  • 리그레션 테스팅: 변경으로 인해 부정적인 영향이 없었는지 확인하는 것이다.

리그레션 테스트 스위트는 반복적으로 실행되며 반복 주기 또는 릴리스 때마다 리그레션 테스트 케이스의 수가 늘어나게 되므로 리그레션 테스트는 자동화하기 매우 적합한 대상이 된다. 이런 테스트의 자동화는 프로젝트 초기에 시작해야 한다. 데브옵스와 같이 지속적 통합을 사용하는 경우 자동 리그레션 테스트를 포함하는 것이 좋은 프랙티스이다.

2.3 유지보수 테스팅

유지보수에는 여러 범주가 있다. 유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포(핫픽스) 모두와 연관되어 있다.

변경 전에 영향도 분석을 수행해 시스템의 다른 영역에 미칠 잠재적 영향을 변경사항 결정에 참고할 수 있다.

유지보수 테스팅의 범위는 일반적으로 다음에 따라 달라진다.

  • 변경의 리스크 수준
  • 기존 시스템의 크기
  • 변경사항의 크기

참고

ISTQB 공식 Syllabus