개념: 테스트의 라이프사이클
이 가이드라인은 RUP 라이프사이클 내에 테스트 규칙을 맞추는 방법을 설명합니다.
관계
기본 설명

소프트웨어는 RUP 소프트웨어 개발 라이프사이클에서 반복을 통해 정제됩니다. 테스트 라이프사이클은 이 프로세스 환경의 동등한 반복 접근 방식에 따라 도움을 받습니다. 각 반복에서 소프트웨어 개발 팀은 각 빌드가 잠재적 테스트 후보가 되는 하나 이상의 빌드를 작성합니다.

개발 팀의 초점 및 목표는 반복 간에 서로 다릅니다. 따라서 테스트 팀 구성원은 이에 따라 테스트 노력을 구성합니다. 상향식 세부사항 테스트 계획 및 디자인 양을 최소로 유지하고 이 작업을 수행해야 하는 경우에는 이 작업을 사용할 시간에 가능한 가깝게 이 작업을 작성하도록 하는 것이 좋습니다. 또한 미리 하나의 반복을 처리하기 전에 상향식 세부사항 테스트 개발을 처리하지 않는 것이 좋습니다.

각 빌드에 대해 구현되고 실행되는 테스트를 추가, 정제 및 삭제합니다. 이러한 테스트의 일부는 유지되고 테스트 본문에 누적되어 각 향후 테스트 주기에서 사용되는 회귀 테스트 후속 빌드에 사용됩니다. 이 접근 방식은 소프트웨어 자체가 수정되는 것처럼 프로세스 전체에서 테스트를 재생하고 수정합니다. 고정 소프트웨어 스펙 및 고정 테스트는 없습니다. 다음 그림은 시간에 따라 테스트가 전개되는 방식을 보여 줍니다.

반복 및 테스트 컴포넌트 다이어그램

이 반복 접근 방식은 컴포넌트 아키텍처 사용과 결합되어 각 후속 빌드에서 제품 품질의 회귀 테스트를 고려하도록 요청합니다. 반복 X로 개발된 테스트는 반복 X+1, X+2 등에서 회귀 테스트의 잠재적 후보가 됩니다. 동일한 테스트를 여러 번 반복할 수 있는 경우에는 테스트 자동화를 고려할 수 있습니다. 테스트 자동화는 프로그램 사용 시나리오의 반복되는 테스트의 접근 방식을 제공하고 새 기능 영역에서 테스트를 탐색하는 테스트 직원을 자유롭게 합니다.

나머지 프로젝트를 고려하지 않고 테스트 라이프사이클을 살펴보십시오. 다음 그림은 제공된 반복에서 테스트 규칙의 작업 세부사항 분석을 표시합니다.

반복 및 테스트 컴포넌트 다이어그램

이 라이프사이클은 나머지 개발 팀이 따르는 반복 주기에 맞춥니다. 반복은 프로젝트 관리자 및 기타 이해 당사자(stakeholder)와 후속 반복에서 수행할 가장 유용한 테스트 작업에 대해 협상하는 테스트 팀의 조사로 시작합니다. 대부분의 테스트 팀 구성원은 이 작업 노력의 파트 역할을 합니다.

다음 그림과 같이 대개 각 반복에는 하나 이상의 테스트 주기가 포함됩니다. 각 반복에 대해 여러 빌드를 생성하고 테스트 주기를 각 빌드에 맞추는 것이 가장 일반적인 사례입니다. 그러나 일부 경우 특정 빌드는 테스트되지 않습니다.

핵심 테스트 노력이 진행되면서 팀 구성원의 서브세트가 새 테스트 기법을 조사하고 있을 수 있습니다. 이 노력은 팀이 특히 후속 반복에서 기법에 의존할 수 있을 만큼 기법이 동작하는지 증명하려고 합니다.

시간에 따른 반복 다이어그램

테스트 라이프사이클은 소프트웨어 라이프사이클의 파트이며, 두 라이프사이클은 동일한 시간 프레임에서 시작해야 합니다. 테스트의 디자인 및 개발 프로세스는 소프트웨어 제품 자체를 개발하는 프로세스만큼 복잡하고 노력이 필요할 수 있습니다. 첫 번째 실행 파일 소프트웨어 릴리스에 따라 테스트가 시작되지 않으면 테스트 노력은 개발 주기의 후반까지 너무 많은 문제의 검색을 지연시킵니다. 이로 인해 종종 긴 버그 수정 기간이 개발 스케줄의 끝에 추가되어 목적을 달성하지 못하고 반복 개발의 이점을 제거합니다.

초기에 시작된 테스트 계획 및 정의 타스크가 초기 스펙의 중요한 결함 또는 결점을 노출할 수 있지만 미리 수행할 테스트 작업은 주의 깊게 선택하는 것이 좋습니다. 이미 언급한 재작업의 가능성 뿐만 아니라 테스트 팀은 편견 없는 품질 조언자로서 역할을 유지하고 "품질 정책"으로 작동하는 초기 요구사항 및 디자인 타스크를 무효화하지 않도록 주의를 기울여야 합니다. 특성상 문제 및 솔루션 공간을 이해하려는 프로젝트 팀의 초기 시도가 무효화될 수 있습니다. 이 초기 작업의 품질에 대해 불합리한 요구를 하면 나머지 개발 그룹에서 테스트 팀이 제외될 위험성이 있습니다.

반복 동안 찾은 문제는 동일한 반복 내에서 해결되거나 기본적으로 프로젝트 관리자 역할에 달려 있는 다음 결정까지 연기될 수 있습니다. 테스트 팀 및 프로젝트 관리자의 주요 타스크 중 하나는 반복 계획에 요약된 반복 계획이 충족되었는지 확인하여 반복의 완료 정도를 측정하는 것입니다. 반복 간에 계속적 "요구사항 발견"이 있습니다. 이 요구사항을 인식하고 관리할 준비를 해야 합니다.

테스트를 수행하는 방법은 다음 여러 요소에 의존합니다.

  • 응용프로그램 도메인
  • 예산
  • 회사의 정책
  • 위험성 허용치
  • 직원

특정 환경에서 품질을 평가하고 위험성을 허용하는 방법에 따라 테스트에 투자한 정도.