[ISTQB] PART 02. 소프트웨어 수명주기와 테스팅

1. 소프트웨어 개발 모델

• 테스팅은 소프트웨어 개발 활동과 독립적으로 존재하지 않고 밀접하게 연계되어 있음
• 개발 수명주기 모델에 기반하여 테스트 접근법을 다르게 적용해야 함

1.1 V-모델(순차적 개발 모델)

• 테스팅에서 V-모델의 역할은 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화 하여 보여주는 것
• 실제 업무에 적용할 때에는 개발하는 소프트웨어 또는 시스템의 특성과 개발 및 테스트 조직의 성격에 맞게 변형하여 사용해야 함

V-모델에서 제시하는 테스트 레벨

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

 

테스트 레벨의 의미

• 개발 단계와 대응하는 컴포넌트(단위) 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅을 의미
• 각각의 테스트 레벨은 서로 독립적
  • 각각 다른 테스트 계획과 전략을 필요로 함
  • 일반적으로 수행하는 주체가 다름
  • 적용하는 테스트 기법의 종류와 형태가 다름
  • 별도의 보고를 필요로 함
  • 각 레벨은 종속성을 지니기 때문에 테스트 레벨에서 다른 테스트 레벨로 옮겨가기 위한 종료 및 시작 조건을 갖추는 것이 바람직

 

개발 초기 단계에서 테스팅을 수행 한다는 것의 의미

• 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미
• 정적 테스팅 동안 테스터는 테스팅 관점에서 테스트 케이스를 만들면서 결함을 발견하여 리뷰에 기여
• 이때 발견한 결함은 동적 테스팅에서 발견할 수 있는 결함과 다른 종류의 결함

 

결함 예방 차원에서의 테스팅이 의미하는 바

• 개발 후반부에서 발생할 테스팅 비용을 줄일 수 있음
• 개발 초기에 발견한 결함은 수정하는 비용도 저렴
• 개발 초기에 테스트 베이시스가 되는 개발 산출물을 리뷰하거나 조기에 테스트를 설계함으로써 소프트웨어의 결함을 사전에 예방하는 효과를 얻게 됨

 

V&V(Verification and Validation)의 의미

• Verification and Validation은 소프트웨어 개발 수명주기의 전 단계에서 수행될 수 있음
• 베리피케이션(Verification)
  • 개발 단계의 산출물이 그 단계의 초기 설정된 조건을 만족하는지 여부를 검증하는 프로세스
  • 주로 리뷰 활동을 통해서 검증하지만, 테스트 레벨의 목적에 맞는 동적 테스팅을 통해서도 검증
• 벨리데이션(Validation)
  • 개발 중에 또는 개발단계 말에 명시된 또는 명시되지 않았지만 사용자의 관점에서 요구사항이 만족하는지를 평가하는 프로세스
  • 정적 테스팅, 동적 테스팅 모두에서 검증 가능

 

1.2 반복적-점증적(Iterative-incremental) 개발 모델

• 짧게 연속적으로 반복하는 활동으로 이루어짐
• 초기 반복 단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발하고 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할 수 있는 기회를 확보
• 개발 리스크를 조기에 감소시킬 수 있음

반복적 개발 모델 예

• 애자일 개발 모델
• RUP(Rational Unified Process)
• RAD(Rapid Application Development)
• 이해관계자 중심의 소프트웨어 개발
• 프로토타이핑

애자일 테스팅 특징

• 테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에 적극 참여할 수 있다.(개발자, 사용자, 테스터)
• 애자일 테스팅은 결함을 최대한 빨리 발견하도록 해준다. 요구사항을 개발함과 동시에 결함을 발견할 수 있다.
• 애자일 테스팅은 문서를 최소화한다.
• 개발완료는 테스트 완료를 의미한다. 즉 개발과 테스트가 같이 시작되고 때로는 테스트가 먼저 시작된다.

 

1.3 개발 수명주기(Life cycle) 모델에서의 테스팅

성공적인 테스팅을 위해서는, 개발 수명주기 모델에 관계없이 다음과 같은 요건들이 필요

• 모든 개발 활동은 이에 상응하는 테스팅 활동을 동반한다.
• 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다.
• 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작되어야 한다.
• 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다.

 

2. 테스트 레벨

테스트 목표, 테스트 베이시스, 테스트 대상, 주로 발견되는 장애와 결함의 종류, 테스트 수행 주체 등과 같은 항목은 각 테스트 레벨의 특징에 맞게 다르게 정의 되고 식별 되어야 함

 

테스트 레벨에 따라 독립적으로 정의 할 수 있는 사항

• 테스트 레벨의 일반적인 목표(목적)
• 테스트 케이스를 도출해 내는데 참조되는 개발 산출물(테스트 베이시스)
• 테스트 대상
• 발견된 정형적인 결함과 장애
• 테스트 하네스(드라이버/스텁) 필요 여부와 툴 지원의 필요성
• 상세한 테스트 접근법
• 테스트 수행 주체 또는 조직

 

2.1 컴포넌트 테스팅

• 테스트가 가능한 (최소)단위로 나누어진 소프트웨어 내에서 결함을 찾고 그 기능을 검증하는 것
• 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른 부분에서 격리하여 독립적으로 수행해야 함
• 스텁, 드라이버, 시뮬레이터 등이 필요할 수 있음
• 구조적인 테스팅, 비기능 테스팅을 포함
• 프로그램 소스 코드를 활용하여 테스트를 설계하며 주된 테스팅 방법은 구조 기반 테스팅

컴포넌트 테스팅의 일반적인 목적

• 기본 경로를 확인
• 모든 오류 처리 경로를 확인
• 컴포넌트 내의 인터페이스 확인
• 로컬 데이터 확인, 경계값 확인

 

2.2 통합 테스팅

• 컴포넌트간의 인터페이스를 테스트하는 것은 물론, OS, 파일 시스템, 하드웨어 또는 시스템간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트
• 하나 이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있음
  • 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트 하며 컴포넌트 테스팅 이후에 수행
  • 시스템 통합 테스팅은 시스템 사이의 상호작용을 테스트하며 시스템 테스팅 이후에 수행
• 통합하는 범위가 크면 클수록 장애나 결함의 위치를 찾아 격리하기 쉽지 않아 개발의 리스크를 증가시키기도 함
• 따라서 상향식, 하향식, 백본 통합과 같은 순차적이고 체계적인 통합 전략이 한 번에 통합하는 빅뱅 전략보다 리스크를 줄이는데 효과적

 

통합 테스트 레벨의 통합 접근법

	백본	빅뱅	상향식	하향식
수행 방법	가장 중요하고 리스크가 높은 모듈로 초기 통합 형성	모든 테스트 모듈을 동시에 통합	가장 하부의 모듈부터 통합해가면서	가장 상부의 모듈부터 통합해가면서
드라이버/ 스텁	드라이버/스텁을 필요에 따라 만들어 사용	드라이버/스텁 없이 실제 모듈로 테스트	테스트 드라이버 필요 점차 개발되고 테스트된 상부 모듈로 대치	테스트 스텁이 필요 점차 개발되고 테스트된 하부 모듈로 대치
장점	결함 격리 쉬움 리스크가 높은 결함을 초기에 발견	단시간 테스트	결함 격리 쉬움 하위 모듈을 충분히 테스트	결함 격리 쉬움 설계상의 결함을 빨리 발견
단점	테스트 시간이 오래 걸릴 수 있음	결함 격리 어려움	수정이 어려운 중요한 결함(설계상 결함)을 상부 구조에서 발견 가능 비지니스 로직 반영 어려움	수정이 어려운(중요한) 결함을 하부에서 발견 가능

 

2.3 시스템 테스팅

• 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트 하는 것
• 테스팅에서 발견하지 못해 발생할 수 있는 환경특성 장애 리스크를 최소화하기 위해서 가능한 범위에서 실제 최종 사용 환경 또는 이와 유사한 환경에서 수행해야 함
• 기능 및 비기능 요구사항을 모두 검증
  • 기능적 요구 사항의 시스템 테스팅 : 테스트 대상의 특성을 가장 상세하게 명세한 문서를 기반으로 테스트를 설계하는 명세기반 기법을 수행
  • 비기능적 요구 사항의 시스템 테스팅 : 소프트웨어의 기능적 품질특성 외의 나머지 부분에 대한 요구사항 검증 수행

 

2.4 인수 테스팅

• 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 경우가 대부분, 다른 이해관계자도 참여할 수 있음
• 시스템이나 시스템의 일부 또는 특정한 기능적인 특성에 대해 확신을 얻는 것
• 결함을 찾는 것은 주된 관심사가 아님
• 시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가

 

인수 테스팅의 형태

• 사용자 인수 테스팅
  • 일반적으로 비지니스 사용자가 시스템 사용의 적절성을 확인
• 운영상의(인수) 테스팅
  • 시스템 관리자에 의한 테스트 활동
• 계약 인수 테스팅과 규정 인수 테스팅
  • 계약 인수 테스팅 : 맞춤식 - 개발 소프트웨어가 계약상의 인수 통과 조건을 준수하는지 확인하는 테스팅, 인수 통과 조건은 계약이 체결될 때 정의됨
  • 규정 인수 테스팅 : 정부 지침, 법률 또는 안전 규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅
• 알파 테스팅과 베타 테스팅
  • 알파 테스팅 : 개발 조직 내에서 고객에 의해 수행됨
  • 베타 테스팅 : 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행됨

 

3. 테스트 유형

테스팅하는 목적 및 품질 특성을 염두에 두고, 소프트웨어 시스템을 검증하는, 일련의 테스트 활동

 

테스트 목적

• 소프트웨어가 수행하는 기능에 대한 테스팅
• 호환성, 신뢰성, 사용성과 같은 비기능적인 품질 특성 테스팅
• 소프트웨어나 시스템의 구조나 아키텍처에 대한 테스팅
• 변경 내용에 관련된 테스팅. 예를 들어, 결함에 대한 수정이 이루어 졌는 지에 대한 확인 테스팅과 의도하지 않은 변경을 찾는 리그레션 테스팅

 

3.1 기능 테스팅

• 시스템이 수행하는 "무엇"을 의미
• 기능 테스팅은 문서화 되어 있거나 테스터가 알고 있는 기능과 특징, 그것들과 특별한 시스템과의 상호 운영성을 고려하여 수행
• 모든 테스트 레벨에서 수행될 수 있음
• 명세 기반 기법을 이용해 소프트웨어나 시스템의 기능에서 테스트 조건과 테스트 케이스를 도출
• 소프트웨어의 외부적인 행동을 고려
• ISO/IEC 9126 기능성 - 적합성, 정확성, 준수성, 상호운용성, 보안성 등의 부특성 포함

 

3.2 비기능 테스팅

• 시스템이 "어떻게" 동작하는가를 테스팅
• 성능 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅, 이동성 테스팅 등을 포함하는 개념
• 모든 테스트 레벨에서 수행될 수 있음
• ISO/IEC 9126 신뢰성, 사용성, 효율성, 유지보수성, 이식성

 

3.3 구조적 테스팅

• 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이 목적
• 모든 테스트 레벨에서 수행될 수 있음
• 특히 컴포넌트, 컴포넌트 통합 테스트 레벨에서 프로그램 코드의 수행 커버리지를 높이는 목적으로 적용
• 시스템, 시스템 통합 또는 인수 테스팅의 테스트 레벨에서 비지니스 모델이나 메뉴 구조도를 활용하여 수행 가능

 

3.4 확인(재)/리그레션 테스팅

• 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트 되어야 함
• 리그레션 테스팅
  • 이미 테스트된 프로그램의 테스팅을 반복하는 것
  • 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 것
  • 소프트웨어 뿐만 아니라 그 환경이 변경되어도 수행 되어야 함
  • 모든 테스트 레벨에서 수행할 수 있음
  • 리그레션 테스트 수트는 여러 번 반복 수행되며 대개는 서서히 변경되기 때문에 자동화 대상으로 고려 가능

* 결함의 원인을 찾거나 결함을 수정하기 위한 디버깅은 개발 활동이며 테스팅 활동으로 보지 않음

 

4. 유지보수 테스팅

• 이미 운영되고 있는 시스템에서 수행됨
• 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션될 때 발생
• 변경된 부분에 대한 테스팅 이외에도 변경되지 않은 시스템 요소에 대한 방대한 리그레션 테스팅도 고려
• 모든 테스트 유형에 대해 모든 테스트 레벨에서 수행할 수 있음
• 영향도 분석 : 변경으로 인해 기존 시스템이 얼마나 영향을 받는지 결정하는 것, 얼마나 많은 리그레션 테스팅을 수행할지 결정하늗네 이용됨

 

---

📚 참고 문헌 : 개발자도 알아야할 소프트웨어 실무