타스크: 테스트 구현
이 타스크는 독립형 또는 협업 테스트의 개발 방법을 설명합니다.
목적

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

  • 실제 실행을 통해 소프트웨어 제품의 유효성 검증을 가능하게 하는 하나 이상의 테스트 중간 산출물을 구현합니다.
  • 더 큰 테스트 하부 구조의 일부로서 다른 테스트와 결합하여 실행될 수 있는 테스트를 개발합니다.
관계
단계
적합한 구현 기법 선택
목적:  테스트를 구현하기에 적합한 기법 파악 

테스트를 구현하기에 가장 적합한 기법을 선택합니다. 수행할 각각의 테스트에 대해 최소한 하나의 테스트 스크립트를 구현할 것을 고려하십시오. 어떤 경우에는 지정된 테스트 구현을 통해 다중 테스트 스크립트로 확장할 수 있습니다. 하나의 테스트 스크립트가 여러 테스트의 구현을 제공하는 경우도 있습니다.

테스트를 구현하는 일반적인 방법으로는 뒤따르는 스크립트 양식으로 텍스트 설명을 작성하는 것(수동 테스트의 경우), 그리고 스크립트 기반 프로그래밍 언어를 프로그래밍하거나, 캡처하여 기록하거나, 생성하는 것(자동화된 테스트의 경우) 등이 있습니다. 각각의 방법에 대해 다음 섹션에서 논의할 것입니다.

대부분의 접근 방식에서와 마찬가지로, 다음 기법을 혼합해서 사용하면 더욱 유용한 결과를 얻을 수 있습니다. 모든 기법을 다 사용할 필요는 없지만 하나의 기법에 얽매여서는 안됩니다.

하위 주제:

수동 테스트 스크립트 구현 기법 선택

많은 테스트를 수동으로 수행할 수 있으며 부적절하게 테스트를 자동화하는 실수를 범하지 말아야 합니다. 사용성 테스트는 대부분의 경우 수동 테스트가 자동 테스트보다 더 적절한 솔루션이 되는 테스트 영역입니다. 또한 소프트웨어 시스템의 실제 산출물의 정확성 및 품질에 대한 유효성 검증을 요구하는 테스트의 경우 일반적으로 수동 유효성 검증이 필요합니다. 일반적인 경험에 따르면 특정 대상 테스트 항목을 처음 테스트할 때는 수동 구현을 사용하는 것이 좋습니다. 이러한 접근 방식을 통해 테스터는 대상 항목에 대한 지식을 얻고 예상치 못한 동작에 적응할 수 있으며 자신의 판단에 따라 다음에 취할 적절한 조치를 결정할 수 있습니다.

때로는 수동으로 이루어진 테스트를 자동화하여 회귀 테스트 전략의 일부로 재사용하게 됩니다. 그러나 수동으로 수행한 모든 테스트를 자동화하는 것은 필요하지 않을 뿐 아니라 바람직하거나 가능하지도 않습니다. 자동화는 테스트 실행 속도 및 정확성, 상세한 테스트 결과의 가시성 및 대조, 복잡한 테스트의 작성 및 관리의 효율성이라는 측면에서 일정 정도 이득이 되지만, 유용한 도구가 다 그렇듯이 모든 요구사항에 대한 솔루션이 될 수는 없습니다.

자동화의 단점은 기본적으로 테스트 실행 중에 인간의 판단이나 추론이 개입될 수 없다는 점입니다. 현재 사용 가능한 자동화 솔루션은 인간의 인지 능력을 갖추고 있지 못하며 앞으로도 그럴 것으로 보입니다. 수동 테스트 구현 과정에서는 자극에 대한 시스템의 반응에 인간의 추론을 적용할 수 있습니다. 현재의 자동화된 테스트 기법 및 이 기법에서 지원하는 도구는 일반적으로 특정 시스템 동작의 의미를 파악하는 제한적인 기능 및 연역 추론을 통해 가능한 문제점을 추론하는 최소한의 기능만을 갖추고 있습니다.

프로그래밍된 테스트 스크립트 구현 기법 선택

테스트 자동화를 사용하는 대부분의 테스터는 이 방법을 선택할 것입니다. 가장 순수하게 수행될 경우 이 방법은 소프트웨어 프로그래밍과 동일한 방식 및 동일한 원칙을 사용하여 수행됩니다. 따라서 소프트웨어 프로그래밍에 사용된 대부분의 방법 및 도구가 테스트 자동화 프로그래밍에 유용하며 적용 가능합니다.

Microsoft Visual Studio나 IBM Visual Age와 같은 표준 소프트웨어 개발 환경, 또는 Rational Robot과 함께 제공된 IDE 등의 특수한 테스트 자동화 개발 환경을 사용하여 테스터는 자유롭게 개발 환경의 파워 및 기능을 최대한 활용할 수 있습니다.

자동화된 테스트를 프로그래밍할 경우의 단점은 일반적인 기법으로서의 프로그래밍 자체의 단점과 관련이 있습니다. 효율적인 프로그래밍이 되려면 적절한 디자인을 위해 몇 가지 고려해야 할 사항이 있습니다. 이러한 사항을 고려하지 않을 경우 구현에 실패할 수 있습니다. 일반적으로 발생하는 일이지만, 개발된 소프트웨어가 나중에 다른 사람에 의해 수정될 수 있는 경우 프로그램 개발에 사용될 공통적인 스타일과 양식을 채택하여 올바르게 사용될 수 있도록 몇 가지 사항을 고려해야 합니다. 이러한 기법의 잘못된 사용과 관련된 중요한 관심사항은 다음 두 가지일 것입니다.

먼저, 테스터는 프로그래밍 환경의 기능에 현혹되어 문제에 대해 단순한 방법으로 구현 가능한 솔루션 대신 복잡하고 정교한 솔루션을 만들기 위해 많은 시간을 허비할 수 있습니다. 이로 인해 테스터는 대상 테스트 항목을 실제로 테스트하고 평가하는 데 사용해야 할 소중한 시간을 프로그래밍 작업에 낭비하게 됩니다. 이러한 함정에 빠지지 않으려면 원칙과 경험이 필요합니다.

두 번째는 테스트 구현에 사용된 프로그램 코드에는 인간의 실수나 태만으로 인해 버그가 있을 수 있다는 점입니다. 이들 버그 중 일부는 자동화된 테스트를 구현하는 일반적인 과정에서 쉽게 디버그하여 정정할 수 있지만 일부는 그렇지 못합니다. 대상 테스트 항목에서 오류를 발견하기 어려운 것처럼 테스트 자동화 소프트웨어에서 오류를 발견하기도 힘듭니다. 또한, 자동화된 테스트 구현에 사용된 알고리즘이 소프트웨어 구현 자체에 사용된 오류가 있는 알고리즘에 기반한 경우 오류가 발생할 수 있습니다. 이로 인해 자동화된 테스트의 오류를 발견하지 못하므로 테스트가 성공적으로 실행되는 것처럼 보입니다. 가능한 경우 자동화된 테스트에서는 다른 알고리즘을 사용하여 이러한 위험성을 줄이십시오.

기록되거나 캡처된 테스트 스크립트 구현 기법 선택

사람과 소프트웨어 응용프로그램 사이의 상호작용을 기록하거나 캡처하는 기능을 제공하고 기본 테스트 스크립트를 생성하는 다양한 테스트 자동화 도구들이 있습니다. 이에 대한 서로 다른 수 많은 도구 솔루션들이 있습니다. 대부분의 도구는 편집 가능한, 고급 프로그래밍 언어로 구현된 테스트 스크립트를 생성합니다. 가장 일반적인 디자인은 다음 중 하나의 방식으로 작동합니다.

  • 클라이어트 운영 체제에 연결된 마우스, 키보드 등의 클라이언트 하드웨어 주변 입력 장치에서 보낸 입력을 가로채는 방법을 사용하는 응용프로그램의 클라이언트 UI와의 상호작용 캡처. 일부 솔루션에서는 의미있는 방식으로 상호작용을 서술하는 장치 드라이버와 운영 체제 사이에 교환된 상위 레벨 메시지를 가로채는 방법으로 이를 수행합니다. 마우스 좌표 또는 키-업 및 키-다운 이벤트의 시간에 따른 움직임의 정도에 기반한 하위 레벨 메시지를 캡처하는 솔루션도 있습니다.
  • 클라이언트 응용프로그램과 하나 이상의 서버 응용프로그램 사이에서 네트워크를 통해 송수신된 메시지 가로채기. 이러한 메시지를 올바르게 해석하려면 HTTP, SQL 등과 같은 일반적으로 알려진 표준 메시지 전달 프로토콜을 사용해야 합니다. 일부 도구에서는 TCP/IP와 같은 "기본" 통신 프로토콜을 캡처할 수 있습니다. 하지만 이러한 특성을 갖는 테스크 스크립트를 사용하려면 작업이 다소 복잡해질 수 있습니다.

자동화된 테스트에 대한 하나의 접근 방식으로 이러한 기법을 사용하는 것은 일반적으로 유용하지만 일부 종사자들은 이러한 기법이 제한적이라고 생각합니다. 일반적으로 우려되는 사항 중 하나는 일부 도구는 단순히 응용프로그램 상호작용을 캡처하기만 할 뿐 그 외의 작업은 수행하지 않는다는 점입니다. 이후의 스크립트 실행 과정에서 시스템 상태를 캡처하고 비교하는 관찰 지점이 추가되지 않는다면 기본 테스트 스크립트만으로는 완벽한 테스트라고 보기 힙듭니다. 따라서 초기 기록을 지속적으로 보강하고 사용자 정의 프로그램 코드를 추가하여 테스크 스크립트 내에 관찰 지점을 구현해야 합니다.

이 주제 및 테스트 자동화 기법으로서 테스트 프로시저 기록 또는 캡처와 관련된 기타 항목들에 대해 다양한 저자들이 책 및 기사를 발표하였습니다. 이러한 주제들을 더 깊이 이해하려면 James Bach, Cem Kaner, Brian Marick and Bret Pettichord 등의 저자가 발표한 자료를 인터넷에서 참조하거나 Lessons Learned in Software Testing [KAN01]의 관련 내용을 참조하십시오.

생성된 테스트 구현 기법 선택

더욱 복잡한 일부 테스트 자동화 소프트웨어를 사용하여 테스트의 다양한 측면을 실제로 생성할 수 있습니다. 즉, 생성 알고리즘에 기반하여 테스트 스크립트의 테스트 데이터 측면 또는 프로시저 측면을 생성할 수 있습니다. 이러한 유형의 자동화는 테스트 과정에서 유용한 역할을 하지만 그 자체만으로 충분한 접근 방식으로 고려해서는 안됩니다. Rational TestFactory 도구 및 Rational TestManager 데이터 풀 생성 기능은 이러한 유형의 기술이 구현된 예입니다.

테스트 환경 전제 조건 설정
목적:  올바른 시작 상태로 환경 준비 

하드웨어, 소프트웨어, 도구 및 데이터를 비롯한 테스트 환경을 설정합니다. 모든 컴포넌트가 올바르게 작동하는지 확인하십시오. 일반적으로, 프린터 용지 공급과 같은 타스크 외에도 몇 가지 기본 환경 재설정(예: Windows 레지스트리 및 기타 구성 파일 재설정), 알려진 상태로 기본 데이터베이스 복원 등의 작업이 여기에 해당됩니다. 일부 타스크는 자동으로 수행될 수 있지만 일부 측면은 사람이 관여해야 합니다.

하위 주제:

(선택사항) 테스트를 수동으로 둘러보기 설정

특히 자동화된 테스트 스크립트에 해당되는 사항이지만, 예상한 전제조건이 있는지 확인하기 위해 처음에는 테스트를 수동으로 둘러보는 것이 좋습니다. 둘러보는 과정에서 환경, 소프트웨어 및 테스트 디자인의 무결성을 확인해야 합니다. 이러한 둘러보기는 대화식 기록 기법을 사용하는 경우 가장 유용하며, 테스트 스크립트를 프로그래밍한 경우에는 그다지 유용하지 않습니다. 이러한 둘러보기의 목적은 테스트를 성공적으로 구현하는 데 필요한 모든 요소가 존재하는지 확인하는 것입니다.

소프트웨어가 충분히 안정적이고 완벽한 경우 수동 둘러보기가 별 효과가 없는 부분에서 발생하는 문제의 위험성이 상대적으로 낮다고 판단하여 이 단계를 건너뛸 수도 있습니다.

테스트 오라클의 적합성 식별 및 확인 설정

사용할 계획인 테스트 오라클이 적절한지 확인하십시오. 아직 테스크 오라클을 식별하지 않은 경우 지금이 적기입니다.

선택한 테스트 오라클이 정확하고 신뢰할 수 있는 결과를 제공한다고 확신할 수 있도록 다른 방법을 강구해야 합니다. 예를 들어 데이터베이스 갱신이 발생했음을 나타내는, 응용프로그램의 UI를 통해 표시되는 필드를 사용하여 테스트 결과의 유효성을 검증하려고 계획한 경우 데이터베이스의 해당 레코드 상태를 확인하기 위해 별도로 백엔드 데이터베이스를 조회할 것을 고려하십시오. 또는 갱신 확인 대화 상자에 표시된 결과를 무시하고 다른 프론트 엔드 기능이나 오퍼레이션을 통해 레코드를 조회하여 갱신을 확인할 수 있습니다.

테스크 환경 및 도구 재설정 설정

수행할 다음 작업은 지원 도구를 포함한 환경을 원래 상태로 복원하는 것입니다. 앞의 단계에서 설명한 것처럼 일반적으로 여기에는 프린터 용지 공급과 같은 타스크 외에 몇 가지 기본 운영 환경 재설정, 알려진 상태로 기본 데이터베이스 복원 등이 포함됩니다. 일부 재설정 타스크는 자동으로 수행될 수 있지만 일부 측면에서는 대개 사람이 관여해야 합니다.

테스트 지원 도구의 구현 옵션을 설정하십시오. 이 옵션은 도구의 복잡한 정도에 따라 달라집니다. 가능하면 하나 이상의 미리 결정된 프로파일을 기반으로 쉽게 다시 로드할 수 있도록 각 도구의 옵션 설정을 저장할 것을 고려해야 합니다. 수동 테스트의 경우, 테스트 결과를 기록하기 위해 지원 시스템에 새 항목을 파티션하거나 문제 및 변경 요청 로깅 시스템에 서명하는 등의 타스크가 포함됩니다.

자동화된 테스트 구현 도구의 경우 고려해야 하는 서로 다른 여러 가지 설정이 있을 수 있습니다. 이들 옵션을 적절하게 설정하지 못하면 테스트 자산 결과의 유용성 및 가치가 떨어질 수 있습니다.

테스트 구현
목적:  재사용가능한 하나 이상의 테스트 구현 자산 구현 

테스트 아이디어 목록, 또는 선택한 하나 이상의 테스트 케이스 아티팩트를 사용하여 테스트 구현을 시작합니다. 테스트에 아직 이름이 지정되지 않은 경우 고유한 이름을 지정하고 테스트의 특정 단계를 기록할 수 있도록 IDE, 캡처 도구, 스프레드시트 또는 문서를 준비하십시오. 테스트 구현에 필요한 만큼 충분히 다음 서브섹션을 둘러보십시오.

일부 특정 테스트나 테스트 유형의 경우 테스트를 수행하는 데 필요한 명시적 단계를 문서화하기에는 값이 부족할 수 있습니다. 테스트에서 특정 스타일의 탐색 테스트 반복은 예상되는 인도물이 아닙니다. 아주 간단한 테스트에서는 대부분의 경우 테스트의 목적을 간단히 기술하는 것만으로도 나중에 재생하는 데 충분한 도움이 됩니다.

하위 주제:

탐색 조치 구현 페이지 맨 위로

필수 탐색 조치를 프로그래밍, 기록 또는 생성하십시오. 먼저 원하는 적절한 탐색 방법을 선택하십시오. 현재 대부분의 시스템에서는 "마우스" 또는 기타 포인팅 장치가 선호되는 기본 탐색 매체입니다. 예를 들면, PDA(Personal Digital Assistants)에서 사용되는 포인팅 및 필기 장치는 개념적으로 마우스와 동일합니다.

보조 탐색 수단은 대개 키보드 상호작용입니다. 대부분의 경우 탐색은 마우스 구동 및 키보드 구동 조치의 조합으로 구성됩니다.

어떤 경우에는 음성 작동, 빛, 시각 및 기타 인지 방식도 고려해야 합니다. 이로 인해 테스트 자동화가 곤란해질 수 있으며 청각적 및 시각적 요소를 동적으로 캡처하지 않고 파일에서 로드하여 처리하도록 응용프로그램에 특별한 테스트 인터페이스를 추가해야 할 수도 있습니다.

여러 가지 탐색 방법을 사용하여 동일한 테스트를 수행해야 하는 경우도 있습니다. 이를 수행하기 위해 여러 가지 접근 방식을 사용할 수 있습니다. 예를 들면, 한 가지 방식으로 모든 테스트를 자동화하고 다른 방법을 사용하여 테스트의 모든 또는 일부 서브세트를 수동으로 수행하십시오. 또는 테스트의 탐색 측면을 특정 테스트의 특성을 결정하는 테스트 데이터에서 분리하여 테스트 실행 방법을 선택하는 논리적인 탐색 인터페이스를 빌드 및 제공하십시오. 탐색 방법을 단순히 조합해서 사용할 수도 있습니다.

관찰 지점 구현 페이지 맨 위로

관찰해야 하는 테스트 스크립트의 각 지점에서 적절한 테스트 오라클을 사용하여 원하는 정보를 캡처하십시오. 많은 경우 관찰 지점에서 얻은 정보를 기록하여 이후의 제어점에서 참조할 수 있도록 보관해야 합니다.

자동화된 테스트인 경우 테스트 스크립트에서 관찰된 정보를 보고하는 방법을 결정하십시오. 대부분의 경우 테스트 스크립트 시작 시간에서 델타 시간만큼 떨어진 상대적인 위치에서 중앙 테스트 로그에 관찰을 기록하는 것만으로 충분합니다. 보다 복잡한 용도로 사용할 수 있도록 특정 관찰을 별도의 스프레드시트나 데이터 파일로 출력할 수도 있습니다.

제어점 구현 페이지 맨 위로

제어 결정을 내려야 하는 테스트 스크립트의 각 지점에서 후속 제어 플로우의 올바른 분기를 결정할 수 있도록 적절한 정보를 얻어 평가합니다. 이전 관찰 지점에서 검색한 데이터는 일반적으로 제어점의 입력입니다.

제어점이 있고 제어 플로우의 다음 조치에 대한 결정이 이루어지는 위치에서 제어점의 입력 값 및 테스트 로그에서 선택된 결과 플로우를 기록하는 것이 좋습니다.

테스트 구현 오류 해결 페이지 맨 위로

테스트 구현 중에 테스트 구현 자체와 관련된 오류가 발생할 수 있습니다. 이러한 오류는 테스트 구현에서 누락된 항목으로 인한 것일 수도 있고 테스트 환경에서 고려하지 못한 항목과 관련이 있을 수도 있습니다. 이러한 오류는 테스트를 완전하게 구현하기 전에 해결되어야 합니다. 발생하는 각각의 오류를 식별하고 이를 해결하십시오.

프로그래밍 언어를 사용하는 테스트 자동화의 경우 여기에는 변수 및 함수 선언 누락, 함수의 잘못된 사용 등으로 인한 컴파일 오류가 포함될 수 있습니다. 테스트 스크립트에 구문 및 기타 기본 구현 오류가 없어질 때까지 컴파일러에 표시된 오류 메시지 또는 기타 다른 출처에서 보낸 오류 메시지를 해결하십시오.

이후의 테스트 실행 과정에서 테스트 구현의 다른 오류들이 발견될 수도 있습니다. 처음에는 이러한 오류들이 대상 테스트 항목의 실패로 보일 수도 있습니다. 테스트 실패 원인을 분석할 때는 실패의 원인이 테스트 구현의 일부 측면에 있지 않고 대상 테스트 항목 자체에 있다는 것을 확인할 때까지 철저히 분석해야 합니다.

외부 데이터 세트 설정
목적:  실행 중에 테스트에서 사용하는, 테스트 스크립트 외부에 저장된 데이터의 작성 및 유지보수  

많은 경우 테스트 스크립트 외부에 테스트 데이터를 보관하는 것이 더욱 적절합니다. 이를 통해 테스트 스크립트 및 테스트 데이터 유지보수 시에 융통성, 단순성 및 보안을 확보할 수 있습니다. 외부 데이터 세트는 다음과 같은 방법으로 테스트에 값을 제공합니다.

  • 테스트 데이터는 테스트 스크립트 외부에 존재하므로 테스트 스크립트의 하드 코딩된 참조를 제거합니다.
  • 외부 테스트 데이터는 일반적으로 테스트 스크립트에 크게 영향을 주지 않고 쉽게 수정할 수 있습니다.
  • 테스트 스크립트를 약간 수정하거나 수정하지 않고도 테스트 데이터로 추가적인 테스트 케이스를 쉽게 지원할 수 있습니다.
  • 외부 테스트 데이터를 많은 테스트 스크립트와 공유할 수 있습니다.
  • 테스트 스크립트 내부의 조건부 분기 논리를 제어하기 위해 외부 테스트 데이터를 사용하여 테스트 스크립트를 개발할 수 있습니다.
테스트 구현 확인
목적:  테스트 스크립트를 실행하여 테스트 스크립트의 올바른 작업 확인 

특히 테스트 자동화의 경우 테스트를 실행할 때 테스트 안정화에 일정 시간을 할애해야 합니다. 테스트 스크립트의 기본 구현이 끝나면 이를 테스트하여 개별 테스트가 적절하게 구현되고 올바르게 실행되는지 확인해야 합니다.

테스트 환경을 알려진 상태로 복구 테스트 구현 확인

테스트 구현이 작동된 후 정리하면서 환경을 다시 원래 상태로 복원해야 합니다. 앞의 단계에서 설명한 것처럼 일반적으로 여기에는 프린터 용지 공급과 같은 타스크 외에 몇 가지 기본 운영 환경 재설정, 알려진 상태로 기본 데이터베이스 복원 등이 포함됩니다. 일부 타스크는 자동으로 수행될 수 있지만 일부 측면은 사람이 관여해야 합니다.

도구 설정 및 테스트 실행 시작 테스트 구현 확인

특히 테스트 자동화의 경우에는 지원 도구 내의 설정이 변경되어야 합니다. 이의 목적은 테스트 스크립트를 실행하여 테스트 스크립트의 올바른 작업을 확인하는 것입니다.

테스트 스크립트 구현에 사용된 소프트웨어의 빌드 버전과 동일한 버전을 사용하여 이 단계를 수행하는 것이 바람직합니다. 이렇게 하면 이후의 빌드에서 발생하는 오류로 인해 문제가 발생할 가능성이 없어집니다.

실행 오류 해결 테스트 구현 확인

테스트를 사용자 개입 없이 실행하려면 구현 과정에서 사용된 접근 방식 및 수행된 작업 중 일부는 어느 정도 조정해야 합니다. 특히 다중 테스트 환경 구성에서 테스트를 실행하는 경우에 그렇습니다.

테스트 자동화의 경우 테스트를 구현된 것으로 선언하기 전에 "허용 범위 내의 기능"을 테스트하고 신뢰할 정도로 작동하도록 조정하는 데 일정 정도의 시간을 할애하도록 준비하십시오. 라이프사이클 후반부(얘: 테스트 스위트 개발 과정)로 이 단계를 미룰 수 있지만 미루지 않는 것이 좋습니다. 그렇지 않으면 해결해야 하는 중요한 실패 백로그가 쌓일 수 있습니다.

테스트 환경을 알려진 상태로 복원
목적:  발견된 상태 그대로 또는 다음 테스트 구현에 필요한 상태로 환경 설정 

이 단계는 사소해 보일 수 있지만 팀 내의 다른 테스터들과의 효율적인 작업 방법을 확립하는 데 중요합니다. 특히, 구현 환경을 공유하는 경우에는 더욱 그렇습니다. 또한 항상 시스템 상태를 부차적인 특성으로 고려하는 것도 중요합니다.

기본적으로 수동 테스트인 경우 환경 복원 문제를 식별하고 수정하는 것은 대체로 간단합니다. 테스트 자동화의 경우에는 환경 상태에서 예상하지 않은 문제가 발생할 경우 이에 대처하기가 쉽지 않다는 점을 기억해 두십시오.

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

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

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

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

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

RUP는 반복적 전달 프로세스이며 중간 산출물은 시간이 경과하면서 발전하는 경우가 많다는 사실을 기억하십시오. 그러므로 부분적으로만 사용되거나 직후 작업에서 전혀 사용되지 않을 중간 산출물을 완전히 형식화하는 것은 대개 필요하지 않습니다(또한 보통 비생산적임). 이는 중간 산출물이 사용되기 전에 중간 산출물을 둘러싼 상황이 변경되고 중간 산출물이 작성되었을 때의 가정이 잘못되었다고 증명되어 결과적으로 노력이 수포가 되고 비용을 들여 다시 작업해야 하는 가능성이 높기 때문입니다.

또한 프리젠테이션 주기가 너무 많아 컨텐츠 가치가 손상되는 함정에 빠지지 않도록 하십시오. 프리젠테이션이 프로젝트 인도물로서 중요성과 경제적 가치를 지니는 프로젝트 환경에서는 중간 산출물에 대한 작업을 수행하여 프리젠테이션을 개선하기 위해 관리 또는 하위 자원을 사용할 것을 고려하십시오.



특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보