타스크: 테스트 접근 방식 정의
이 타스크는 사용될 테스트 전략과 특정 기법을 정의하는 방법을 설명하고 자동화 아키텍처를 간략히 설명합니다.
원칙: 테스트
목적

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

  • 원하는 테스트를 가능하게 하기 위해 사용될 각 특정 기법 식별
  • 지원하는 테스트 유형을 포함하여 각 기법의 작업을 간략히 설명
  • 테스트 자동화 시스템의 후보 아키텍처를 정의
관계
단계
테스트 동기 부여 요인 및 테스트 항목 점검
목적:  미션, 테스트 동기 부여 요인 및 테스트 항목이 앞으로의 테스트 노력을 위한 접근 방식에 미치는 영향 고려 

평가 미션을 컨텍스트로 사용하여 반복 테스트 계획을 점검하고 앞으로의 테스트 노력을 위해 식별된 테스트 동기 부여 요인을 연구하십시오. 동기 부여 요인 소스를 추가로 조사해야 할 수도 있습니다(대개 반복 계획은 추가 정보를 찾는 수단을 제공).

각 동기 부여 요인의 경우, 각 동기 부여 요인을 처리하려면 어떤 접근 방식 및 연관된 기법이 필요할지 고려하십시오. 또한 반복 테스트 계획을 점검하고 테스트 항목을 연구하십시오. 각 동기 부여 요인, 적절히 확장된 접근 방식 및 기법과 관련지어 각 테스트 대상 항목을 고려해야 합니다. 많은 세부사항을 찾을 수 없거나 테스트 항목에 익숙하지 않은 경우, 개발 인력과(보통 소프트웨어 설계자나 개발 팀 리드와 우선적으로) 대상 항목을 논의하는 것이 유용할 수 있습니다.

평가 미션과 동기 부여 요인을 만족스럽게 처리하는 데 필요한 최소 기법 세트를 식별하는 데 초점을 맞추십시오. 하나의 기법을 사용하여 두 개 이상의 필수 테스트 측면을 처리할 수 있는 기회를 찾으십시오. 다른 잠재적 기법을 탐색하는 것도 좋지만 이는 필수가 아니라 추가적임에 유의하십시오.

소프트웨어 아키텍처 점검
목적:  소프트웨어 아키텍처가 테스트 접근 방식에 미치는 영향 고려 

주요 요소(메커니즘, 기본 보기 등)를 이해할 수 있도록 소프트웨어 아키텍처를 연구하십시오. 일반적으로 소프트웨어 아키텍처 문서는 테스트 접근 방식을 고려할 때 사용할 올바른 세부사항 레벨에 초점을 맞춘 좋은 정보를 제공합니다. 정보를 명확히 하거나 문서가 없을 경우에는 개발 인력(보통 소프트웨어 설계자와 직접 의논) 또는 개발 팀 리더 중 한 사람과 아키텍처를 논의하는 것이 유용합니다.

주요 메커니즘을 식별 및 논의하고 이런 시스템 측면을 잘 이해하는 데 초점을 맞추십시오. 아키텍처의 각 메커니즘과 주요 기능은 테스트 노력에 대한 제한조건이나 당면 과제를 제공할 가능성이 있습니다. 예를 들어, 분산 아키텍처의 경우 테스트 팀을 하위 팀으로 구성하고 각 팀은 아키텍처 계층을 대상으로 해야 합니다.

테스트 구현 및 실행 전략을 수립하기 위한 창의적인 방법을 사용하여 종종 이런 당면 과제를 극복할 수 있긴 하지만 타스크: 테스트 용이성 요소 정의에 설명된 대로 테스트를 가능하게 하려면 개발 팀이 소프트웨어를 수정하도록 해야 할 수도 있습니다.

테스트 접근 방식의 적절한 넓이과 깊이를 고려
목적:  넓이와 깊이 모든 면에서 테스트 접근 방식의 완전성을 고려 

테스트 접근 방식에 관한 요구사항에 대해 현재 알려진 모든 세부사항을 고려할 경우 거리를 두고 상위 레벨 측면에서 테스트 접근 방식을 고려하는 것이 유익합니다. 테스트 접근 방식이 반드시 다루어야 할 사항 중 다루지 않는 사항은 무엇입니까? 문서화된 정보에는 나타나지 않지만 탐색해야 하는 관심사항이 있습니까?

경험을 기반으로 테스트 접근 방식 요구사항을 검토하여 프로젝트 라이프사이클의 이 단계에 적절한 넓이와 깊이를 고려하십시오. 보다 완벽한 접근 방식을 제공하는 데 도움이 되는 추가 요구사항을 고려하십시오.

재사용을 위해 기존 테스트 기법 식별
목적:  적절한 경우 기존에 입증된 테스트 기법을 재사용하거나 적응 

자신의 경험이나 액세스할 수 있는 다른 사람의 경험을 기반으로 테스트 접근 방식의 요구사항을 충족하거나 이를 충족하도록 적응시킬 수 있는 기존 기법을 식별하십시오.

추가 기법 식별
목적:  포괄적이고 충분한 테스트 접근 방식을 제공하는 데 필요한 기법을 식별  

"완벽한" 테스트 접근 방식은 그리 유용하지 않습니다. 시간과 자원의 제약만 없다면 시도해 보고 싶은 추가 기법이 항상 있기 마련입니다.

그러나 인식한 품질에 대한 유용한 평가를 수행할 수 있도록 테스트 접근 방식이 완벽하고 포괄적이어야 합니다. 따라서 프로젝트 팀이 인식한 품질을 확신을 갖고 평가할 수 있도록 품질 위험성 또는 품질 차원 측면을 충분히 평가하는 접근 방식이 필요합니다.

기법 정의
목적:  지원하는 테스트 목표를 포함하여 각 기법의 작업 아웃라인 

각 기법의 작업을 간략히 설명하십시오. 지원하는 테스트 유형, 목표와 범위, 구현 방법, 테스트 오라클, 평가 방법 및 기법의 자동화 요구를 다루십시오.

한 프로젝트에서 다음 프로젝트로 기법을 재사용하게 되는 경우가 많습니다. 이런 상황에서는 기법에 대한 공통 정의를 참조하거나 기존 정의를 복사하고 적절하게 개정하기만 하면 됩니다.

각각의 기존 또는 필수 기법의 경우:

목표와 범위 정의 페이지 맨 위로

많은 기법이 두 가지 이상의 테스트 유형을 지원하므로 기법이 지원해야 할 테스트를 신중히 식별하십시오. 이렇게 하면 처음으로 기법을 정의하는 경우 필요한 노력의 범위를 식별하는 데 도움이 됩니다.

이 기법이 나타내는 기본 목표와 가치를 고려하십시오.

구현 방법 설명 페이지 맨 위로

기법 구현 방법을 정의하십시오. 단순히 "시스템 성능 테스트를 수행 중입니다"라고 해서는 안됩니다. 테스트를 수행할 수 있는 방법을 진지하게 고려해야 합니다.

사용하려는 기법이 비경제적인 경우가 있습니다. 어떤 방식으로 접근하여 이 기법을 구현할 것인지 간략히 설명하면 관련된 논리 및 기법 추구의 실용성을 전반적으로 파악할 수 있습니다.

적합한 평가 방법 식별 페이지 맨 위로

이 기법을 사용하여 구현된 각 테스트의 결과를 어떤 방식으로 관찰하고 평가할 것인지 결정하십시오. 사용 가능한 여러 테스트 오라클을 고려하십시오. 오라클이 하나입니까 아니면, 각 테스트 결과를 판별할 수 있는 여러가지 방법이 있습니까?

적용 가능한 자동화 사용 식별 페이지 맨 위로

자동화는 많은 테스트 기법에서 중요한 역할을 수행할 수 있습니다. 정교함이 떨어지며 수동 테스트 수행을 지원하기만 하는 경우도 있습니다.

기법과 관련한 작업을 가장 효율적으로 구현, 유지보수 및 관리할 수 있는 방법을 고려하십시오. 넓이와 깊이 모두에 대해 개방적 사고를 갖고 가능한 많은 옵션을 고려하십시오.

적용 가능한 도구 식별 페이지 맨 위로

이 테스트 기법에 사용할 적절한 도구를 식별하십시오. 자동화 사용을 식별한 이전 단계의 작업을 사용하십시오.

광범위한 도구 카테고리를 고려하십시오. 후보 도구 목록에는 단순한 테스트 실행 자동화 도구 그 이상이 포함되어야 합니다. 테스트 실행을 자동화하는 도구 이외에 시간과 노력이 많이 드는 반복적 타스크(예: 테스트 데이터 관리, 테스트 결과 분석, 사건(incident) 및 변경 요청 보고 도구 등)를 줄여 테스트 팀의 생산성을 향상시키는 도구를 고려하십시오.

테스트 자동화 아키텍처 아웃라인
목적:  테스트 자동화 시스템의 후보 아키텍처 정의 

유사한 시스템이나 유사한 문제점 도메인에서 확보한 경험을 기반으로 테스트 자동화 시스템의 후보 아키텍처 정의를 시작하십시오.

이 타스크를 수행하기 전에 소프트웨어 아키텍처 개발과 관련된 정보를 검토하는 것이 좋습니다.

테스트 자산 형상 관리 전략 정의
목적:  형상 관리를 위해 테스트가 가져야 할 요구사항 고려 

소프트웨어 개발 프로젝트 중에 생성된 다른 많은 중간 산출물과 마찬가지로 테스트 자산은 형상 관리 및 버전 제어의 후보입니다.

특정 요구사항은 사용 가능한 기본 백업 및 복구 서비스 사용 결정에서부터 응용프로그램의 여러 버전에 대해 다중 사이트에서 자동화된 테스트 스크립트 병렬 개발을 완벽히 지원하는 것에 이르기까지 복잡도 면에서 다양할 수 있습니다.

형상 관리 요구사항을 고려하고 해당 요구사항을 실현하기 위해 가능한 논리적 요구를 간략히 아웃라인하십시오.

재사용가능한 자산의 가용성 조사
목적:  기존에 입증된 자산을 재사용하여 위험성과 노력을 줄임 

처음부터 자산을 빌드하는 것이 적합한 경우도 있고 그렇지 않은 경우도 있습니다. 새로운 중간 산출물 작성 시 완벽한 "자체 작성(roll-you-own)" 철학과 엄격하면서도 관료적인 전체 정책(librarian policy)을 확립하는 것 사이에 밸런스를 잘 유지하십시오.

어떤 접근 방식이 다른 접근 방식보다 훨씬 경우도 있으며, 두 접근 방식의 이점을 충분히 유연하게 활용할 수 있어야 합니다.

찾은 결과 캡처
목적:  테스트 접근 방식에 대한 중요한 결과 기록 

팀 규모, 조직 문화 등 많은 요인에 따라 테스트 접근 방식에 대해 내린 결정을 기록하는 데 더 좋은 방법과 더 나쁜 방법이 있습니다.

일반적으로 두 대상을 고려해야 합니다. 관리 팀은 이 정보를 검토하여 승인을 제공하고 접근 방식의 물류 관련사항을 알고자 하며 테스트 팀은 테스트 접근 방식을 작업 안내로 사용하려고 합니다. 두 팀의 요구를 적절히 충족시킬 수 있는 적절한 수단을 찾도록 하십시오. 프로젝트 인트라넷 웹 사이트를 사용하는 것이 한 방법일 수 있습니다.

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

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

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

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



자세한 정보