승인 테스트는 소프트웨어 전개 이전의 마지막 테스트 조치입니다. 승인 테스트의 목적은 소프트웨어가 준비되어 일반 사용자가 소프트웨어에 빌드된 해당 기능 및 타스크를 수행할 수 있는지 확인하는 것입니다. 승인 테스트 구현에는 세 가지 일반 전략이 있습니다. 다음과 같습니다.

선택하는 전략은 종종 계약 요구사항, 조직 및 회사 표준, 어플리케이션 영역을 기초로 합니다.

공식 승인 테스트 페이지 맨 위

공식 승인 테스트는 고도로 관리되는 프로세스이며 종종 시스템 테스트를 확장한 것입니다. 테스트는 주의깊게 계획 및 설계되며 시스템 테스트와 동일한 세부사항을 갖습니다. 선택된 테스트 케이스는 시스템 테스트에서 수행된 것의 서브세트여야 합니다. 선택된 테스트 케이스로부터 벗어나지 않는 것이 중요합니다. 많은 조직에서 공식 승인 테스트는 완전히 자동화되어 있습니다.

활동 및 결과물은 시스템 테스트와 동일합니다. 일부 조직에서는 개발 조직(또는 독립 테스트 그룹)이 일반 사용자 조직 대표와 함께 승인 테스트를 수행합니다. 다른 조직에서는 일반 사용자 조직 또는 일반 사용자 조직이 선택한 객관적인 개인 그룹에 의해 승인 테스트가 완전히 수행됩니다.

이러한 테스트 유형의 장점은 다음과 같습니다.

  • 테스트할 기능 및 사양이 알려져 있습니다.
  • 테스트의 세부사항이 알려져 있고 측정 가능합니다.
  • 테스트를 자동화할 수 있고 회귀 테스트가 허용됩니다.
  • 테스트 진행 상태를 측정 및 모니터할 수 있습니다.
  • 승인 기준이 알려져 있습니다.

단점은 다음과 같습니다.

  • 상당한 자원 및 계획이 필요합니다.
  • 테스트가 시스템 테스트의 재구현일 수 있습니다.
  • 테스트에서는 예상되는 결함만 찾기 때문에 소프트웨어의 주관적인 결함을 찾을 수 없습니다.

비공식 승인 테스트 페이지 맨 위

비공식 승인 테스트에서 테스트를 수행하는 테스트 프로시저는 공식 승인 테스트에서처럼 엄격하게 정의되어 있지 않습니다. 탐구하는 기능 및 비즈니스 타스크가 식별 및 문서화되어 있지만 따라야 하는 특정 테스트 케이스가 없습니다. 각 테스터가 무엇을 수행할지 결정합니다. 이 승인 테스트 방법은 공식 테스트만큼 제어되지 않고 공식 테스트보다 주관적입니다.

비공식 승인 테스트는 일반 사용자 조직에서 가장 많이 수행합니다.

이러한 테스트 유형의 장점은 다음과 같습니다.

  • 테스트할 기능 및 사양이 알려져 있습니다.
  • 테스트 진행 상태를 측정 및 모니터할 수 있습니다.
  • 승인 기준이 알려져 있습니다.
  • 공식 승인 테스트보다 더 많은 주관적인 결함을 발견하게 됩니다.

단점은 다음과 같습니다.

  • 자원, 계획 및 관리 자원이 필요합니다.
  • 테스트 케이스를 사용하는 사항에 대해서는 제어권이 없습니다.
  • 일반 사용자가 결함을 보지 못하고 시스템 작동 방식을 따르기만 할 수 있습니다.
  • 일반 사용자가 결함을 찾기 보다는 새 시스템과 레거시 시스템의 비교에만 중점을 둘 수 있습니다.
  • 승인 테스트 자원이 프로젝트 제어 하에 있지 않으므로 제한적일 수 있습니다.

베타 테스트 페이지 맨 위

베타 테스트는 세 가지 승인 테스트 전략 중 최소한으로 제어됩니다. 베타 테스트에서 사용되는 방법, 데이터 및 세부사항의 양은 전적으로 개별 테스터에게 달려 있습니다. 각 테스터가 환경을 작성하고 데이터를 선택하여 탐구할 기능, 사양 및 타스크를 결정할 책임을 집니다. 각 테스터는 현재 상태의 시스템을 승인할지 여부에 대한 자신만의 기준을 가지고 있어야 합니다.

베타 테스트는 종종 개발(또는 다른 비 일반 사용자) 조직의 관리를 거의 받지 않은 상태에서 일반 사용자에 의해 구현됩니다. 베타 테스트는 모든 승인 테스트 전략 중 가장 주관적입니다.

이러한 테스트 유형의 장점은 다음과 같습니다.

  • 테스트는 일반 사용자에 의해 구현됩니다.
  • 대량의 잠재적 테스트 자원이 있습니다.
  • 참여자에 대한 고객 만족도가 증가합니다.
  • 공식 또는 비공식 승인 테스트보다 더 많은 주관적인 결함을 발견하게 됩니다.

단점은 다음과 같습니다.

  • 모든 기능 또는 사양을 테스트할 수 없습니다.
  • 테스트 진행을 측정하기 어렵습니다.
  • 일반 사용자가 결함을 보거나 보고하지 못하고 시스템 작동 방식만을 따를 수 있습니다.
  • 일반 사용자가 결함을 찾기 보다는 새 시스템과 레거시 시스템의 비교에만 중점을 둘 수 있습니다.
  • 승인 테스트 자원이 프로젝트 제어 하에 있지 않으므로 제한적일 수 있습니다.
  • 승인 기준이 알려져 있지 않습니다.
  • 베타 테스터를 관리하려면 지원 자원을 증가해야 합니다.


Rational Unified Process   2003.06.15