타스크: 테스트 세부사항 정의
이 타스크는 대상 테스트 항목에 의해 구동되는 특정 컨텍스트 내에서 테스트 아이디어를 자세히 기술하는 방법에 대해 설명합니다.
원칙: 테스트
목적

이 타스크의 목적은 다음과 같습니다.

  • 특정 컨텍스트에서 테스트 아이디어를 실현하는 데 필요한 개별 조건 정의
  • 관련 테스트 항목에 대한 잠재적인 관찰 및 제어 시점 식별
  • 관찰 시점 촉진을 위한 잠재적인 오라클 식별
  • 테스트를 지원하는 소비 가능한 자원 제공
관계
단계
대상 테스트 항목 및 관련 테스트 아이디어 목록 검사
목적:  가능한 테스트 아이디어를 토대로 대상 테스트 항목에 대해 보다 심도있게 이해합니다.  

테스트 아이디어 목록을 컨텍스트로 사용하여 사용 가능한 대상 테스트 항목 정보를 검사하십시오. 보충 스펙, 비즈니스 규칙, 디자인 중간 산출물 이외에 유스 케이스 및 관련 중간 산출물(예: 유스 케이스 실현(realization), 유스 케이스 스토리보드, 유스 케이스 시나리오)이 일반적으로 시작하기 좋은 소스입니다.

한정된 정보를 사용할 수 있는 경우에는 개발 담당자와 직접 대상 테스트 항목을 논의해야 합니다.

자세히 기술할 테스트 아이디어 서브세트 선택
목적:  현재 컨텍스트에서 가장 많은 이점을 제공하는 관리 가능한 테스트 서브세트를 결정하여 정의합니다.  

테스트 아이디어 목록을 검토하고 자세한 테스트를 디자인할 여러 개의 테스트 아이디어를 선택하십시오. 대부분의 경우 시간 제한조건, 현재 테스트 주기에 대한 테스트 아이디어의 관련성, 대상 테스트 항목의 완전성을 토대로, 테스트 아이디어의 서브세트를 선택합니다. 사용자가 처해 있는 상황의 특정 컨텍스트에 따라, 현재 테스트 주기의 디자인에 적용할 테스트 아이디어의 실제 개수는 경우마다 달라집니다.

지정된 테스트 아이디어 목록에서 처음으로 디자인한 테스트 아이디어를 모두 디자인하지 않는 것이 좋습니다. 대신 점진적이고 반복적인 접근 방식을 통해 테스트 아이디어 목록에 대해 작업함으로써, 지정된 테스트 주기 동안 유용한 평가 정보를 생성할 가능성이 가장 높다고 여겨지는 소수의 아이디어에만 초점을 맞추십시오. 이 방법은 다른 항목은 무시하고 한 개의 대상 테스트 항목에만 너무 많은 시간을 소비하는 위험성을 완화시켜주면서, 나중에 별로 중요하지 않은 것으로 판명될 수 있는 테스트 아이디어에 대한 디자인에 노력을 기울이는 위험성을 최소화합니다.

각 테스트 아이디어에 대한 테스트 디자인
목적:  테스트 아이디어 목록에서 파생될 각 테스트의 주요 특성을 정의합니다.  

지금까지 수집한 정보를 이용하여 테스트를 실현하는 데 필요한 주요 특성을 식별하고 정의함으로써 테스트를 정의하십시오. 결과 테스트 디자인은 다음과 같은 여러 가지 방법으로 캡처할 수 있습니다.
  • 기본적으로 테스트 디자인은 중간 산출물: 테스트 케이스로 캡처되었습니다.
  • 중간 산출물: 워크로드 분석 모델은 개념적으로 보다 복잡한 형태의 전문화된 테스트 케이스로서, 특히 시스템 성능 테스트와 관련이 있습니다.
  • 테스트와 프로젝트 문화의 복잡도에 따라 테스트를 직접 중간 산출물: 테스트 스크립트로 실현하는 것이 적합할 수 있습니다. 이 접근 방식은 테스트 케이스 아티팩트를 작성하지 않는 것이 바람직한 경우에 고려해야 하는 방식입니다. 이 접근 방식을 채택한 경우 해당 테스트가 유용한 이유를 설명하는 유용한 정보를 테스트 스크립트에 주석으로 추가하십시오. 이러한 주석은 비정규 인라인 테스트 케이스로 사용하십시오.

수집한 정보를 이용하여 테스트의 다음과 같은 측면을 각각 고려하십시오.

입력, 출력 및 실행 조건 식별

"블랙 박스" 관점에서 테스트를 고려하여 테스트를 정의하는 중요한 가시적인 외부 특성을 식별하십시오. 테스트 시뮬레이션에 필요한 입력과 예상되는 결과 출력을 식별하십시오. 또한 주요 실행 조건을 열거하십시오. 이 단계의 경우 실행 조건의 "방법"을 설명하거나 이해하지 않아도 됩니다.

입력과 예상 출력은 간단한 테스트 유형 값(예: "A", "1")에서 복잡한 다차원 데이터(예: 사운드 클립, 오브젝트)에 이르는 특정 테스트 범위에 따라 달라집니다. 특정 값을 제공하는 것보다 특정 입력 또는 예상 출력 뒤에 규정자를 정의하는 것이 더 좋습니다. 그럴 경우 나중에 테스트를 구현하거나 실행하는 사람들이 테스트 데이터 이면에 숨은 의미를 이해할 수 있게 되므로, 대체 값을 선택하여 지정된 실행에서 테스트를 다르게 설정할 수 있습니다.

후보 관찰 시점 식별

관찰 시점이란 테스트 환경에서 상태의 특정 측면을 관찰하고자 하는 테스트 실행 중의 시점입니다. 실행 조건, 입력 및 예상 출력을 알고 있다고 가정할 경우, 테스트 실행 중 관찰할 특정 시점과 관찰할 데이터를 식별하십시오.

후보 제어 시점 식별

제어 시점이란 테스트의 제어 플로우와 관련하여 여러 선택사항 중에서 한 항목을 결정하고자 하는 테스트 실행 중의 시점입니다. 사용 가능한 테스트 시나리오를 조사하고, 각각에 대해 테스트를 여러 번 실행함으로써 제어가 달라질 시점을 고려하십시오. 여러 제어 시점을 조합하고 이들 목록을 현재 테스트 주기에 필요한 목록으로 축소하십시오.

적절한 테스트 오라클 식별

테스트 오라클은 테스트할 예상 출력 값과 이러한 값을 추측할 수 있는 방법을 모두 결합하는 것으로, 지정된 응답이자 응답이 지정되는 방법입니다. 예를 들어, 워드 프로세싱 패키지에 사용된 정확한 글꼴 표시를 확인하려는 경우 글꼴 표시를 확인할 매체로 인쇄 미리보기를 사용할 수 있습니다. 테스트 오라클은 테스트의 실제 결과를 예상 결과와 비교하여 확인할 때 필요한 형식 및 기능의 측면을 식별합니다.

필수 데이터 소스, 값 및 범위 정의
목적:  적절한 테스트 데이터 소스를 비롯하여 필수 테스트 데이터 값을 정의합니다.  

앞에서 설명한 바와 같이 테스트 데이터는 여러 가지 형태와 형식으로 표시될 수 있습니다.

데이터가 복잡하게 상호 종속되어 있을 경우 도메인 전문가를 활용하여 적합한 테스트 데이터 조건을 지정해 보십시오. 일부 테스트 생산성 도구는 테스트 데이터 세트 생성을 간소화하는 기능이나 유틸리티를 제공합니다.

충분한 소비 가능한 테스트 데이터 제공
목적:  테스트를 지원하는 충분한 양의 올바른 테스트 데이터를 제공하고 기록합니다.  

적합한 테스트 데이터의 정확한 생성 또는 조합은 테스트 정의에 있어 가장 어렵고 시간 소모가 많은 타스크입니다. 데이터 집약적인 클래스 시스템의 경우 특히 그렇습니다.

테스트 데이터는 Microsoft® Excel® 또는 표 형식의 데이터 관리 인터페이스를 제공하는 다른 제품(예: Microsoft® Access®)에서 기록하는 것이 좋습니다.

추적성 관계 유지보수
목적:  추적된 항목에 대한 영향 분석 및 평가 보고를 수행할 수 있게 합니다. 

테스트 계획에서 요약되는 추적성 요구사항을 사용하여 필요한 대로 추적성 요구사항을 갱신하십시오.

결과 평가 및 확인
목적:  타스크가 적절히 완료되었는지 및 그에 따른 중간 산출물이 허용 가능한지 확인 

작업을 완료했으므로 작업이 충분한 가치가 있었는지, 방대한 양의 종이만 소비한 것이 아닌지 확인하는 것이 좋습니다. 작업 품질이 적합한지 여부 및 차후에 이를 작업의 입력으로 사용할 해당 팀 구성원에게 유용할 정도로 완전한지를 평가해야 합니다. 가능하면 RUP에 제공된 체크리스트를 사용하여 품질 및 완성도가 "충분"한지 확인하십시오.

다운스트림 타스크 수행 시 해당 작업을 입력으로 사용할 인원들이 중간 작업 검토에 참여하도록 하십시오. 이들의 관심사항을 다루는 조치를 취할 시간 여유가 있으면 이를 수행하십시오. 또한 작업을 주요 입력 중간 산출물과 비교 평가하여 이를 정확하고 충분하게 표시했는지 확인해야 합니다. 입력 중간 산출물 작성자가 이를 기반으로 작업을 검토하도록 하는 것이 유용할 수 있습니다.

RUP는 반복적 프로세스이며 중간 산출물은 시간이 경과하면서 발전하는 경우가 많다는 사실을 기억하십시오. 그러므로 부분적으로만 사용되거나 직후 작업에서 전혀 사용되지 않을 중간 산출물을 완전히 형식화하는 것은 거의 불필요합니다(또한 보통 비생산적임). 이는 중간 산출물이 사용되기 전에 중간 산출물을 둘러싼 상황이 변경되고 중간 산출물이 작성되었을 때의 가정이 잘못되었다고 증명되어 결과적으로 노력이 수포가 되고 비용을 들여 다시 작업해야 하는 가능성이 높기 때문입니다. 또한 프리젠테이션 주기가 너무 많아 컨텐츠 가치가 손상되는 함정에 빠지지 않도록 하십시오. 프리젠테이션이 프로젝트 인도물로서 중요성과 경제적 가치를 지니는 프로젝트 환경에서는 관리 자원을 사용하여 프리젠테이션 타스크를 수행할 수 있습니다.



자세한 정보