목적:
|
관련 이해 당사자들에게 테스트 노력의 중요한 테스트 용이성 요구를 알리고 테스트 용이성에 대한 지원 얻기
|
올바른 방법으로 테스트 용이성 요구를 승격시키는 것이 중요합니다. 프로젝트 관리자, 개발 팀 및 고객 이해 당사자 모두 사회적 위치와 문화가 다르므로 테스트 용이성 요구의 승격 시기를 민감하게 고려하는 것이
중요합니다. 일반적인 경험에 의하면 상대적으로 느긋한 비정규 팀인 경우에는 정규 테스트 용이성 "캠페인"을 실시하지 말고, 의식 레벨이 높은 프로젝트인 경우에는 비정규 접근 방식을 사용하지 마십시오.
어떤 경우에는 협력적인 "브레인스토밍" 세션이 유용한 프리젠테이션 형식이 될 수 있습니다. 이 경우 요구는 개발 팀에 대한 도전으로 제시되고 테스트 용이성 요구를 충족시킬 수 있는 창의적인 솔루션을 제안하도록
분위기가 고조됩니다. 이러한 분위기를 통해 솔루션에 대한 주도권을 높이고 파트너 간의 친선을 도모할 수 있습니다.
이 단계에서는 타이밍도 중요합니다. 일반적으로 가장 중요한 테스트 용이성 문제를 가능한 한 빨리, 일반적으로 정제(Elaboration) 과정, 그리고 가능하면 도입/인식(Inception) 단계에서 식별하고
승격시켜야 합니다. 이처럼 프로젝트의 초기 단계에서 테스트 용이성 문제가 제기되면 일반적으로 팀이 아직 소규모이기 때문에 변경하기에 더 용이합니다. 이러한 요구를 변화하는 디자인에 포함시키는 것이 일반적으로
재작업이 최소한으로 요구되기 때문에 더 간편합니다.
테스트 용이성 요구를 식별하고 긍정적으로, 그리고 덜 "공식적인" 방식으로 제시하기에 좋은 방법은 개념 검증 활동을 평가하고 개발 노력에서 사용할 써드파티 컴포넌트 선택을 평가할 때 테스트 팀이 서비스를 제공하도록
하는 것입니다. 특히, 데이터베이스 컴포넌트 선택, UI 제어 또는 컴포넌트 선택, 미들웨어 컴포넌트 등의 과정에서 테스트 팀이 관련된다는 것은 테스트 용이성 문제가 컴포넌트 선택 기준의 한 측면으로 사용될 수
있다는 것을 나타냅니다. 예를 들면, 많은 경우에 개발 팀은 사용할 UI 위지트 라이브러리에 대해 거의 상관하지 않습니다. 한 라이브러리가 다른 라이브러리보다 더 테스트하기 용이하다면 개발 팀은 테스트하기 쉬운
위지트 라이브러리를 선택하면 만족하기 때문입니다.
테스트 용이성 챔피온을 식별하거나 끌어들이는 데 문제가 있는 경우 잠재적으로 덜 위험하고 더 적은 노력으로 바꿀 수 있는 변경사항을 끄집어내는 접근 방식을 고려하거나 가장 중요한 테스트 용이성 요구를 심각한
프로젝트 문제로 제기할 수 있습니다. 심각한 프로젝트 문제란 해결될 때까지는 테스트 노력이 성공했다고 할 수 없는 문제를 말합니다. 후자의 경우 이러한 조치를 취하기 전에 모든 옵션을 신중하게 검토해 볼 것을
권장합니다.
|