타스크: 테스트 용이성 확약 얻기
이 타스크는 테스트 용이성 요구 및 이점을 정의하고, 우선순위를 결정하고 승격시키는 방법에 초점을 맞춥니다.
목적

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

  • 테스트 노력의 필요성을 지원하는 테스트 가능한 소프트웨어의 작성 승격
  • 적절한 자동화 기법 및 도구 사용의 지원 및 승격
관계
단계
테스트 용이성 요구 조사
목적:  소프트웨어 전달 프로세스 또는 소프트웨어 아키텍처 및 디자인에서 요구하는 테스트 구현 및 평가 요구에 대한 충분한 이해 

테스트 자동화 아키텍처 및 테스트 인터페이스 스펙을 검토하여 테스트 구현 및 평가 요구를 충분히 이해하십시오. 특히, 이러한 요구로 인한 소프트웨어 전달 프로세스 또는 소프트웨어 아키텍처 및 디자인의 제한사항을 파악하십시오.

영향 평가 및 우선순위 결정
목적:  테스트 노력에서 가장 중요한 테스트 용이성 요구를 식별하고 더 적은 요구에 대한 해결책 주장  

테스트 용이성 요구를 검토하고 충족된 요구가 없는 테스트 노력에 미치는 영향 측면에서 기본적인 영향 분석을 수행하십시오. 또한 요구에 대한 솔루션을 조사 및 제공하기 위해 필요한 개발 팀의 잠재적인 노력에 대한 기본적인 분석도 고려하십시오. 각각의 요구에 대해 개발 팀에게 더 적은 영향을 주는, 가능한 대체 솔루션을 식별하십시오.

이 정보를 사용하여 아직 대체 솔루션이 없는 상태에서 충족되지 않을 경우 테스트 노력에 미치는 영향이 큰 순서로 요구의 우선순위 목록을 만드십시오. 이 작업을 수행하는 이유는 필요성이 적은 테스트 용이성 요구에 소중한 개발 자원을 낭비하지 않고 정말로 중요한 요구에 자원을 사용하기 위해서입니다.

테스트 용이성의 이점 정의
목적:  기본적인 비용/이익 측면에서 테스트 용이성 요구의 가치를 이해 당사자에게 판매 가능  

개발 팀에서 구체적인 테스트 노력을 통해 소프트웨어를 개발하도록 요청함으로써 개발 노력에 요구사항 및 제한조건을 추가하게 됩니다. 이를 위해서는 개발 팀의 추가 작업과 위험 및 복잡도가 요구됩니다. 테스트 용이성에 대한 설계를 자신의 책임 밖의 일로 보는 개발 팀도 있습니다. 어떤 경우에는 테스트 용이성 요구로 인해 일반적으로 우선순위가 더 높은 고객 요구사항에 사용해야 할 개발 자원이 낭비될 수 있습니다. 이런 경우에는 테스트 용이성 요구의 이점을 프로젝트 관리자, 소프트웨어 설계자 및 기타 개발 팀의 이해 당사자들에게 "팔아야" 합니다.

확약을 얻으려는 테스트 용이성 요구의 이점을 분석하는 것을 공식화하십시오. 테스트 용이성 요구의 가치를 지지하는 논문, 기사 및 사례를 조사하고 ROI 통계가 제공되는 경우에는 이를 활용하십시오. 개발 팀에게 제공되는 가치라는 측면에서 이점을 고려하십시오. 즉, 다음과 같은 질문을 해 보십시오. 이 요구가 충족되어야만 개발 팀에게 제공할 수 있는 유용한 평가 정보는 무엇입니까? 이 요구를 통해 각각의 빌드 사이클에서 적절한 시기에 정확한, 깊이 있는, 또는 유용한 피드백을 개발 팀에게 더욱 쉽게 또는 더욱 효율적으로 제공하는 방법은 무엇입니까? 이 요구는 개발 팀의 자체 테스트 노력이나 향후의 소프트웨어 실패 진단에서 사용할 수 있는 유용한 기능을 개발 팀에게 제공합니까? 고객 요구와 상충되는 경우, 테스트 용이성 요구를 더 빨리 제공하면 후속 빌드 사이클에서 지원될 고객 요구사항에 대해 또 다른 기회를 제공할 수 있음을 보여줄 수 있는 방법을 고려하십시오.

테스트 용이성 챔피언 식별 및 참여
목적:  테스트 가능한 소프트웨어 빌드를 지지하고 이 점에 대한 테스트 팀의 요구를 지원할 중요한 이해 당사자들의 협조 얻어내기  

개발 팀의 잠재적인 추가 업무나 위험성이 노출된 경우, 테스트 용이성에 대한 지원을 승인하거나 위임할 수 있는 영향력 있는 이해 당사자들을 식별하고 끌어들여야 합니다. 지원이 필요한 테스트 용이성 요구를 승격하기 전에 가능한 빨리 이러한 일을 수행해야 합니다.

가장 중요한 세 명의 이해 당사자는 소프트웨어 설계자, 프로젝트 관리자, 그리고 고객 대표입니다. 시간을 할애하여 소프트웨어 설계자와 논의하면서 테스트 용이성을 지원하는 소프트웨어 아키텍처의 가치를 설명하십시오. 테스트 팀의 생산성 및 평가 정보의 신속한 전환이라는 측면에서 테스트 용이성의 이점을 프로젝트 관리자에게 설명하십시오. 고객에게는 전달되는 제품의 품질에 가치를 둘 것을 주장하십시오.

테스트 용이성 요구 및 이점 승격
목적:  관련 이해 당사자들에게 테스트 노력의 중요한 테스트 용이성 요구를 알리고 테스트 용이성에 대한 지원 얻기  

올바른 방법으로 테스트 용이성 요구를 승격시키는 것이 중요합니다. 프로젝트 관리자, 개발 팀 및 고객 이해 당사자 모두 사회적 위치와 문화가 다르므로 테스트 용이성 요구의 승격 시기를 민감하게 고려하는 것이 중요합니다. 일반적인 경험에 의하면 상대적으로 느긋한 비정규 팀인 경우에는 정규 테스트 용이성 "캠페인"을 실시하지 말고, 의식 레벨이 높은 프로젝트인 경우에는 비정규 접근 방식을 사용하지 마십시오.

어떤 경우에는 협력적인 "브레인스토밍" 세션이 유용한 프리젠테이션 형식이 될 수 있습니다. 이 경우 요구는 개발 팀에 대한 도전으로 제시되고 테스트 용이성 요구를 충족시킬 수 있는 창의적인 솔루션을 제안하도록 분위기가 고조됩니다. 이러한 분위기를 통해 솔루션에 대한 주도권을 높이고 파트너 간의 친선을 도모할 수 있습니다.

이 단계에서는 타이밍도 중요합니다. 일반적으로 가장 중요한 테스트 용이성 문제를 가능한 한 빨리, 일반적으로 정제(Elaboration) 과정, 그리고 가능하면 도입/인식(Inception) 단계에서 식별하고 승격시켜야 합니다. 이처럼 프로젝트의 초기 단계에서 테스트 용이성 문제가 제기되면 일반적으로 팀이 아직 소규모이기 때문에 변경하기에 더 용이합니다. 이러한 요구를 변화하는 디자인에 포함시키는 것이 일반적으로 재작업이 최소한으로 요구되기 때문에 더 간편합니다.

테스트 용이성 요구를 식별하고 긍정적으로, 그리고 덜 "공식적인" 방식으로 제시하기에 좋은 방법은 개념 검증 활동을 평가하고 개발 노력에서 사용할 써드파티 컴포넌트 선택을 평가할 때 테스트 팀이 서비스를 제공하도록 하는 것입니다. 특히, 데이터베이스 컴포넌트 선택, UI 제어 또는 컴포넌트 선택, 미들웨어 컴포넌트 등의 과정에서 테스트 팀이 관련된다는 것은 테스트 용이성 문제가 컴포넌트 선택 기준의 한 측면으로 사용될 수 있다는 것을 나타냅니다. 예를 들면, 많은 경우에 개발 팀은 사용할 UI 위지트 라이브러리에 대해 거의 상관하지 않습니다. 한 라이브러리가 다른 라이브러리보다 더 테스트하기 용이하다면 개발 팀은 테스트하기 쉬운 위지트 라이브러리를 선택하면 만족하기 때문입니다.

테스트 용이성 챔피온을 식별하거나 끌어들이는 데 문제가 있는 경우 잠재적으로 덜 위험하고 더 적은 노력으로 바꿀 수 있는 변경사항을 끄집어내는 접근 방식을 고려하거나 가장 중요한 테스트 용이성 요구를 심각한 프로젝트 문제로 제기할 수 있습니다. 심각한 프로젝트 문제란 해결될 때까지는 테스트 노력이 성공했다고 할 수 없는 문제를 말합니다. 후자의 경우 이러한 조치를 취하기 전에 모든 옵션을 신중하게 검토해 볼 것을 권장합니다.

지원에 대한 확약 얻기 및 테스트 용이성 유지보수
목적:  개발 팀이 테스트 용이성 기능을 지속적으로 지원하고 유지보수할 것이라는 동의 얻기 

테스트 용이성 요구는 개발 노력에 대한 기타 다른 요구사항이나 제한조건과 같은 방식으로 간주되어야 합니다. 현재 제공되는 테스트 용이성 기능이 향후에 포기되지 않을 것이라는 약속을 얻어야 합니다.

이러한 확약을 얻으려고 하다가 개발 팀에서 테스트 용이성 요구를 개발하거나 지원하기를 거절하는 수가 있습니다. 이는 무척 실망스러울 수 있으므로 이러한 상황에 대해 알아두고 가능한 빨리 이러한 현실에 대처해야 합니다. 개발 팀에서 지원을 포기한 테스트 구현을 개발하기 위해 엄청난 시간과 노력을 낭비하는 것은 더욱 바람직하지 않습니다.

테스트 용이성 문제의 해결책 주장
목적:  테스트 용이성 문제의 해결책 모니터 및 지지 

개발 팀에서 테스트 노력의 테스트 용이성 요구에 필요한 지원을 제공하는 데 동의한 경우 이러한 작업의 디자인, 구현 및 완료에 적극적인 관심을 보일 필요가 있습니다. 개발 팀이 테스트 용이성 요구에 부응하기로 동의하고 솔루션을 찾기 위해 작업을 시작했다고 해서 관심을 줄이지 마십시오. 적절한 솔루션이 적절한 시기에 개발되는지 확인해야 합니다.

테스트 팀 인력 모두 개발 팀의 질문에 기꺼이 응답하고 프로토타입이 빌드되는 즉시 평가하도록 하십시오. 건설적인 피드백을 제공하고 요구를 맞추기 위해 개발 팀이 들인 노력에 관심을 보이십시오. 더 복잡한 테스트 용이성 요구에 필요한 디자인 워크샵에 핵심 인력을 참석시켜 도와주되 개발자의 디자인 프로세스에 너무 관여하거나 통제하지 않도록 주의시키십시오.

문제가 제기되었지만 별로 주목받지 못한다거나 즉시 처리되지 않는다고 생각되는 경우에는 소프트웨어 설계자와 프로젝트 관리자에게 얘기하십시오. 프로젝트 문제 목록의 문제를 프로젝트 관리자에게 기록하도록 하십시오.

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

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

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

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



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