타스크: 테스트 용이성 메커니즘 식별
이 타스크는 간편한 테스트 접근 방식에 필요한 기술적 솔루션의 일반적인 메커니즘을 식별하는 방법과 해당 메커니즘의 일반적인 범위 및 주요 특성을 요약하는 방법을 설명합니다.
관계
단계
소프트웨어 아키텍처 및 대상 환경을 조사합니다.
목적:  소프트웨어 아키텍처 및 대상 배치 환경과의 관계 이해 

적절한 컨텍스트에서 이 타스크를 수행하려면 개발 중인 소프트웨어, 이 소프트웨어의 아키텍처 및 이 소프트웨어가 지원할 핵심 메커니즘 및 기능을 잘 알아야 합니다. 소프트웨어 아키텍처에 대해 제공된 문서를 조사하여 기초적인 개념을 파악하고 필요한 경우 소프트웨어 설계자와 인터뷰하거나 논의하여 보충 정보를 확보하십시오. 각각의 대상 배치 환경이 이 정보에 미치는 영향을 고려하고 테스트와 관련이 있을 것으로 보이는 중요한 항목은 기록하십시오.

테스트 메커니즘 후보 식별
목적:  테스트 접근 방식에서 요구하는 잠재적인 테스트 메커니즘 식별 

소프트웨어 아키텍처 및 대상 환경에 대한 지식을 토대로 테스트 접근 방식에 제공된 정보를 조사하십시오. 접근방식의 핵심적인 기술 측면을 고려하고 이를 지원하는 데 필요한 메커니즘 후보 목록을 작성하십시오. 지속성, 동시성, 분포, 통신, 보안, 트랜잭션 관리, 복구, 오류 발견 처리 및 보고, 프로세스 제어 및 동기화 등과 같은 일반 메커니즘을 후보로서 고려해야 합니다.

이러한 메커니즘은 수동 및 자동 테스트 모두에 적용될 수 있습니다. 하지만 특정 메커니즘은 수동 또는 자동 테스트 중 한 쪽과 더 많이 관련됩니다. 또한 수동 또는 자동 테스트에서 동일한 메커니즘이 요구된다고 해도 구현된 솔루션의 특성은 일반적으로 다릅니다.

기존 테스트 메커니즘 인벤토리
목적:  후보 메커니즘의 기존 구현의 재사용 여부 식별 및 개발이 필요한 추가 구현 식별 

사용 가능한 테스트 도구 및 기존 테스트 구현을 조사하고 하나 이상의 기존 솔루션이 존재하는 메커니즘의 인벤토리를 작성하십시오. 이 과정은 명확히 자동 테스트와 더 관련이 깊지만 수동 테스트를 위해 고려해야 하는 항목도 있습니다.

하위 주제:

자동화 메커니즘 테스트 페이지 맨 위로

먼저, 구매할 계획이거나 제공되는 도구의 목록을 컴파일하십시오. 자동화 도구의 형태는 다양하며 일반적으로 이 도구 목록에는 자동화된 테스트 구현 및 실행 도구 이상의 도구가 포함되게 됩니다. 각 도구에 대해 도구가 제공하는 메커니즘을 조사하십시오. 예를 들면, 사용하려는 스크립팅 도구는 자체의 데이터 지속성 메커니즘을 제공합니까? 제공한다면, 이 메커니즘이 요구사항을 충족시킵니까, 아니면 그 이상이 필요합니까? '실행 도구를 사용하여 여러 호스트 클라이언트 시스템에서 테스트 스크립트를 동시에 실행할 수 있습니까?' 또는 '실행 도구를 사용하여 중앙 마스터 시스템에서 여러 호스트 클라이언트 시스템으로 스크립트를 분배할 수 있습니까?' 등과 같은 질문을 제기할 수 있습니다.

기존 테스트 자동화 구현이 제공되는 경우 인벤토리에 대한 추가 메커니즘이 존재합니다. 이러한 구현의 일부 측면을 통해 도구의 유용성을 위해 해당 도구에서 제공하는 기본 메커니즘을 확장하거나 보충할 수 있습니다. 다른 측면을 통해 기본 도구에서 제공하지 않는 추가 메커니즘을 구현할 수 있습니다.

수동 테스트 메커니즘 페이지 맨 위로

기본적으로, 이 메커니즘은 테스트 구현 및 실행을 위해 존재하는 테스트 가이드라인을 검토하는 작업과 관련됩니다. 동시성 및 분배와 같은 문제에 대한 기존 프로세스 솔루션을 찾아야 합니다. 즉, 테스터 간에 데이터 세트를 공유하는 방법, 특히 서로에게 나쁜 영향을 주지 않고 기존 데이터 베드를 공유하는 방법, 그리고 테스트 팀이 분산된 경우 분리된 테스트를 조정하기 위해 사용 가능한 솔루션을 말합니다.

사용할 테스트 메커니즘 정의
목적:  필수 테스트 메커니즘에 대한 결정 커뮤니케이션 

필수 테스트 메커니즘을 결정했으면 이제 테스트 팀 및 기타 테스트 이해 당사자들과 선택사항에 대해 의견을 교환해야 합니다. 테스트 자동화 아키텍처 문서화 과정의 일부로 자동화에 요구되는 테스트 메커니즘에 대한 결정사항을 문서화하고 테스트 가이드라인의 일부로 수동 테스트와 관련된 결정사항을 문서화하는 것이 좋습니다.

정규 문서 대신 단지 이 정보를 비정규 아키텍처 및 프로세스 노트의 세트로 기록하고, 주로 화이트보드에 기록되는 설명 다이어그램을 추가할 수 있습니다. 테스트 구현 및 실행 과정에서 테스터는 이 정보를 활용하여 적절한 결정을 내립니다.

개발 중인 소프트웨어에 빌드해야 할 특별한 테스트 인터페이스 요구사항에 대한 식별이 끝나면 하나 이상의 요약된 테스트 인터페이스 스펙을 작성하여 이 요구사항을 기록하는 것이 좋습니다. 이러한 요약을 통해 기본 테스트 인터페이스 요구사항 또는 기능을 열거하고 간단히 설명하며 이에 대해 이름을 제공해야 합니다. 이러한 요약 작업에 너무 많은 시간을 들이지는 마십시오. 요구사항 및 기능 목록에 대해서는 뒤에 나오는 타스크: 테스트 용이성 요소 정의에서 설명할 것입니다.

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

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

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

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



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