개념: 테스트 레벨
이 가이드라인은 테스트 활동을 개발자, 독립, 유닛, 통합, 시스템 및 적합성 테스트로 분류합니다.
관계
관련 요소
기본 설명

테스트는 다른 단계나 다른 작업 노력 레벨에 있는 다른 유형의 대상에 적용됩니다. 이 레벨은 일반적으로 테스트를 디자인하고 수행하기 위한 최상의 스킬을 가지고 있으며 각 레벨에서의 테스트에 가장 적절한 기법을 가지는 역할에 의해 구별됩니다. 이와 같은 서로 다른 작업 노력 사이에서 밸런스를 조절하여 초점을 맞춰야 합니다.

개발자 테스트

개발자 테스트는 개발자 팀이 맡기에 가장 적절할 테스트 디자인 및 구현 측면을 나타냅니다. 이 테스트는 독립 테스트와 대조적입니다. 대부분의 경우, 테스트 실행은 처음에 테스트를 디자인하고 구현한 개발자 테스트 그룹에 대해 발생지만, 실행을 위해 독립 테스트 그룹이 사용할 수 있도록 개발자가 테스트를 작성하기 위한 좋은 사례입니다.

전형적으로, 개발자 테스트는 주로 유닛 테스트 측면에서 고려되었습니다. 일부 개발자는 다양한 레벨의 통합 테스트도 수행하지만, 이는 문화 및 기타 상황에 크게 좌우됩니다. 개발자 테스트는 따로 분리해서 독립적 유닛 테스트 이상으로 더 많은 것을 다룰 것을 권장합니다.

독립 테스트

독립 테스트는 개발자 팀과 독립적인 누군가가 가장 적절하게 수행하는 테스트 디자인 및 구현을 나타냅니다. 이 구별은 독립 검증 및 유효성 검증을 포함하는 수퍼세트로 간주할 수 있습니다. 대부분의 경우, 테스트 실행은 처음에 테스트를 디자인하고 구현한 독립 테스트 그룹에 대해 발생하지만, 실행을 위해 개발자 테스트 그룹이 사용할 수 있도록 독립 테스터가 테스트를 작성해야 합니다. Boris Beizer는 독립 테스트가 개발자 테스트에 비해 가지고 있는 다른 목표에 대해 다음과 같은 설명을 제공합니다.

"독립 테스트의 목적은 다른 관점과 이에 따른 다른 테스트를 제공하여 개발자에게 가능한 것보다 더 풍부한 [...] 환경에서 테스트를 안내하는 것입니다."[BEI95]

독립 이해 당사자(stakeholder) 테스트

독립 테스트의 엇갈린 관점은 이 테스트가 다양한 이해 당사자의 관심사항 및 필요성을 기반으로 하는 테스트를 나타낸다는 것입니다. 따라서 이 테스트를 이해 당사자 테스트라고 합니다. 이는 중요한 구별입니다. 이 이해 당사자 테스트는 전형적으로 고려되었던 것보다 광범위한 이해 당사자 관심사항을 포함시켜서 일반 "고객"을 고객 이외의 기술 지원 인력, 기술 트레이너, 판매 인력과 사용자와 같은 이해 당사자로 확장시키는데 도움이 됩니다.

마지막 설명처럼 고객 테스트XP 개념은 RUP에서의 이 독립 테스트 분류와 관련이 있습니다.

유닛 테스트

유닛 테스트는 소프트웨어의 가장 작은 테스트 가능 요소를 확인하는 데 초점을 맞춥니다. 일반적으로 유닛 테스트는 제어 플로우와 데이터 플로우가 처리되는지, 그리고 이 플로우가 예상대로 작동하는지 확인하기 위해 구현 모델에 표시된 컴포넌트에 적용됩니다. 구현자는 유닛이 개발되는 대로 유닛 테스트를 수행합니다. 유닛 테스트의 세부사항은 구현 원칙에 설명되어 있습니다.

통합 테스트

통합 테스트는 유스 케이스를 실행하기 위해 결합되었을 때 구현 모델의 컴포넌트가 적절하게 작동하는지 확인하기 위해 수행됩니다. 테스트 대상은 구현 모델에 있는 하나의 패키지이거나 패키지 세트입니다. 결합되는 패키지는 종종 다른 개발 조직에서 제공됩니다. 통합 테스트는 패키지의 인터페이스 스펙에 발생하는 불완전성이나 실수를 보여줍니다.

어떤 경우에는 개발자가 독립 테스터와 같은 다른 그룹이 통합 테스트를 수행할 것이라고 가정하기도 합니다. 이 상황에서는 다음과 같은 이유로 인해 소프트웨어 프로젝트와 궁극적으로 소프트웨어 품질에 위험성이 발생합니다.

  • 통합 영역은 소프트웨어 실패의 공통 지점입니다.
  • 독립 테스터가 수행하는 통합 테스트는 일반적으로 블랙 박스 기법을 사용하므로 보통 대규모 소프트웨어 컴포넌트로 처리됩니다.

보다 효과적인 접근 방식은 통합 테스트를 개발자와 독립 테스터 모두의 책임으로 간주하지만 테스트 노력이 두드러지게 겹쳐지지 않도록 각 팀의 전략을 작성하는 것입니다. 겹침의 정확한 속성은 개별 프로젝트의 필요성을 기반으로 합니다. 개발자와 독립 시스템 테스터가 하나의 품질 비전을 공유하는 환경을 만들 것을 권장합니다. 추가 정보는 개념: 개발자 테스트를 참조하십시오.

시스템 테스트

전형적으로, 시스템 테스트는 소프트웨어가 전체적으로 작동할 때 수행됩니다. 반복적 라이프사이클로 인해 시스템 테스트가 훨씬 빨리 발생할 수 있습니다(잘 형성된 유스 케이스 동작 서브세트가 구현되는 즉시). 보통 대상은 시스템의 엔드-투-인드 기능 요소입니다.

적합성 테스트

사용자 적합성 테스트는 소프트웨어를 배치하기 전에 취하는 최종 테스트 조치입니다. 적합성 테스트의 목적은 소프트웨어가 준비 완료 상태여서 사용자들이 소프트웨어가 빌드된 기능 및 타스크를 수행하는 데 사용할 수 있는지 확인하는 것입니다. 추가 정보는  개념: 적합성 테스트를 참조하십시오.

적합성 테스트에 대한 다른 개념도 있습니다. 이 개념은 일반적으로 하나의 그룹 또는 팀에서 다른 그룹 또는 팀으로 이양되는 특징을 가집니다. 예를 들어, 빌드 적합성 테스트는 개발에서 독립 테스트로의 새 소프트웨어 빌드 이양을 승인하기 위해 수행되는 테스트입니다.

테스트 레벨의 순서 및 타이밍에 대한 설명

전형적으로, 유닛 테스트는 테스트의 첫 번째 단계로서 반복 초기에 구현된다고 생각할 수 있습니다. 후속 단계 이전에 전달해야 하는 모든 유닛이 처리됩니다. 그러나 반복 개발 프로세스에서는 이 접근 방식은 일반 규칙으로 부적절합니다. 더 나은 접근 방식은 대부분 찾기 오류 발생 가능성이 있는 유닛, 통합 및 시스템 테스트를 식별한 후 가장 심각한 위험성 및 지원 환경의 조합을 기반으로 구현 및 실행하는 것입니다.