타스크: 테스트 노력 평가 및 개선
이 타스크는 효율성 증대를 위해 테스트 노력을 시기 적절하게 변경하는 데 초점을 맞추고 있습니다.
목적

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

  • 테스트 노력의 생산성, 효율성 및 완전성 평가
  • 효율성 증대를 위한 테스트 노력(전술적 및 전략적) 조정
관계
단계
작업 상태 캡처
목적:  목표 달성을 위해 테스트 작업의 일반적인 상태를 계획과 비교해 가며 객관적이면서 최신 상태로 이해합니다. 

이 단계를 접근하는 방법에는 여러 가지가 있는데, 이들 대부분은 프로젝트 문화에 따라 달라집니다. 가능한 경우 개별 팀 구성원이나 하위 팀에서 준비한 진행상태 보고서를 수집하고 조합하십시오. 프로젝트 작업시간 현황표 역시 고려해야 할 요소입니다. Microsoft Project와 같은 프로젝트 스케줄링 시스템을 적극적으로 사용하여 실제 진행상태로 갱신하는 경우 이 시스템은 또 다른 유용한 정보 출처를 제공합니다. 사용 가능하며 적극적으로 사용되는 경우, 형상 및 변경 관리 시스템에서 객관적인 상태나 진행상태 메트릭을 도출할 수도 있습니다.

이 단계와 정보를 수집하고 테스트 노력을 평가하는 후속 단계의 경우, 객관적 척도와 주관적 척도를 둘 다 통합하는 균형 잡힌 시각을 확보하십시오. 객관적 숫자는 그림의 일부만 제공하므로 현재의 프로젝트 "환경"에 맞는 내용으로 설명되고 뒷받침되어야 합니다. 반대로, 테스트 노력에 대한 평판과 주관적 추측에 전적으로 의존하지 말고 이를 뒷받침하는 객관적 증거를 찾도록 하십시오. 팀의 리더 또는 가능한 경우 개별 팀 구성원과의 논의를 통해 주관적 평가를 수집하고 객관적 데이터에 어느 정도의 신뢰를 불어 넣을 수 있는지 가늠하여 객관적 데이터를 보충하는 것이 좋습니다.

테스트 노력 생산성 및 효율성 메트릭 수집
목적:  테스트 팀에서 수행한 테스트를 평가할 수 있는 객관적인 데이터를 수집하고 검사합니다. 

테스트의 식별, 정의, 디자인 및 실행에 얼마나 많은 노력을 기울였는지 조사하십시오. 테스트 노력의 다른 측면은 고려하지 않고 한 가지 측면에만 과도하게 노력을 기울인 징후가 있는지 감시하십시오. 또한 노력이 비생산적이거나 소요된 노력 레벨에 비해 충분한 이점을 나타내지 않는 영역이 있는지도 감시하십시오.

또한 테스트 효율성의 측면에서도 살펴 보십시오. 효율성 초기 관찰을 지원하는 데이터를 찾으십시오. 결함 발견 비율, 결함 심각도 계수, 중복된 결함 통계 및 테스트 이스케이프로 발견된 결함과 같은 측면을 고려하십시오.

변경 요청 분포, 상태동향 및 추이 메트릭 수집
목적:  테스트 팀에서 로깅한 문제와 결함을 평가할 수 있는 객관적인 데이터를 수집하고 검사합니다. 

변경 요청 데이터에서 중요한 상태동향을 분명히 식별하십시오. 일반적으로 이 타스크에서는 데이터 볼륨을 분석하는 데 시간을 소모하는 것보다 관련 데이터의 동향이 나타내는 바를 식별하는 것이 더 중요합니다. 긍정적인 신호(예: 안정적이면서 지속적인 결함 발견율 또는 시간 경과에 따라 발견율이 지속적으로 증가 또는 감소)를 찾으십시오. 테스트 팀의 생산성을 감소시키는 프로세스, 환경적, 정치적 또는 기타 문제점을 나타내는 발견율의 정점과 저점을 주시하십시오.

결함 종결 동향을 검토하십시오. 개발 팀에 의해 "재생 불가능"으로 종결된 결함이 현저히 증가하는지 확인하십시오. 테스트 팀에 의해 불충분한 실패 분석이 수행된 결과인 경우를 식별하고 이 문제점의 범위를 정량화하십시오. 개발 팀에 의해 "디자인한 대로 작동함"으로 종결된 결함의 동향을 검토하십시오. 테스트 팀에 의해 불충분한 스펙 분석이 수행된 결과인 경우를 식별하고 이 문제점의 범위를 정량화하십시오. 너무 많은 작업을 수행한 개발자가 자신의 워크로드를 분류하도록 하는 대신 이러한 징후가 잘못된 것이 아니고 정당한 것임을 주의해서 확인하십시오. 이후 빌드에서 결함 수정사항이 테스트 팀에 릴리스되었으므로 결함 검증 동향에 대한 몇 가지 분석도 수행해야 합니다. 테스트 팀의 검증을 기다리고 있는 결함이 쇠퇴하고 있거나 관리 불가능한 숫자로 증가하고 있는지 확인하십시오.

문제점을 나타내는 다른 동향을 찾으십시오. 테스트 팀이 결함과 다른 변경 요청을 기록하거나 관리하는 방식을 살펴 보십시오. 애매하고 불충분한 변경 요청 정보로는 개발자가 조치를 취하기 어렵고 실패하게 됩니다. 팀에서는 결함에 대해 기록된 정보의 품질이 상대적으로 평균 이상인지 신중하게 모니터해야 합니다. 연관된 변경 요청의 명료성을 개선하여 모호성과 정서적 언어 및 추론을 없애십시오. 이러한 중간 산출물을 작성한 개인과 협력하여 문제점의 본질이 명확하게 기술되었는지 확인하고 문제를 논의하는 사실적이고 정확한 방법을 찾으십시오.

또한 여러 차원에서 결함 분포의 불균형이 있는지도 찾으십시오. 결함 수가 적은 응용프로그램이나 스펙의 기능 영역을 찾으십시오. 이는 해당 기능 영역에서 충분하지 않은 테스트가 수행되었음을 나타내는 것일 수 있습니다. 또한 테스트 팀 구성원별 분포도 확인하십시오. 개별 팀 구성원이 너무 많은 작업을 수행했거나 생산성이 떨어지고 있음을 나타내는 징후가 있을 수 있습니다.

추적성, 적용 범위 및 종속성 메트릭 수집
목적:  자산 추적성을 평가할 수 있는 객관적인 데이터를 수집하고 검사합니다.  

테스트 자산-테스트 아이디어, 테스트 케이스, 테스트 스크립트, 테스트 스위트, 변경 요청-관련된 업스트림 및 다운스트림 자산 간의 추적성 관계 상태를 분석하고, 테스트 노력이 올바른 영역과 유용한 동기 부여 세트에 초점을 맞춰졌음을 나타내는 징후를 찾으십시오. 또한 테스트의 특정 측면이 누락되었거나 더 이상 중요하지 않음을 나타내는 부정적 징후도 찾으십시오. 요구사항이나 개발 팀이 현재 테스트 노력에 의해 표시되지 않은 영역에서 작업하고 있을 경우 이러한 징후가 문제점을 나타낼 수 있습니다.

메트릭 평가 및 초기 평가 공식화
목적:  메트릭 데이터를 평가하고 계획에 대한 테스트 노력의 효율성에 대한 초기 평가를 공식화합니다.  

수집한 모든 정보를 조합한 후 이를 수집한 내용의 전부로 평가하십시오. 수집한 각 데이터 조각은 전체 평가의 한 측면만 해결하므로 모든 데이터에 대한 균형이 잡히고 숙고된 보기를 기반으로 테스트 노력 평가를 공식화해야 합니다.

이해 당사자가 의견이나 피드백을 제공하기에 적합한 형식으로 초기 평가를 기록하십시오.

결과 기록
목적:  프로젝트 관리 보고서에 포함될 요약 결과를 문서화하고 초기 평가와 비교하여 이후 상태 평가에 대한 분석을 가능하게 합니다.  

이 타스크는 프로젝트 관리자와 관리 팀의 다른 역할에게 중요한 요약 상태 정보를 생성합니다. 이러한 역할은 요약 결과를 통해 프로젝트에 대한 결정을 내립니다.

이후 평가와 비교하면서 이전 평가와 대조할 수 있는 형식으로 결과 테스트 노력 평가의 일부 측면을 기록하는 것이 좋습니다. 그러면 시간 경과에 따른 테스트 노력 개선의 상대적 동향을 분석할 수 있습니다.

평가 프리젠테이션 및 피드백 수집
목적:  이해 당사자를 참여시키고 실제 테스트 노력이 이해 당사자의 요구를 만족하는지 여부에 대한 이들의 피드백을 얻습니다.  

이해 당사자가 의견이나 피드백을 제공할 수 있도록 평가 결과를 프리젠테이션하십시오. 프리젠테이션 형식이나 방법은 프로젝트마다 다릅니다. 경우에 따라 일련의 비정규 좌담으로 진행되거나, 프로젝트 인트라넷 웹 사이트에 간단히 게시하거나, 정규 프리젠테이션이 될 수도 있습니다. 사용자 문화에 적합한 형식을 선택하십시오.

최상의 계획 및 스펙 문서를 사용할 수 있다 하더라도 일반적으로 원래 예상, 이 문서의 의도, 최종 제품 간에는 차이가 있습니다. 이는 소프트웨어 개발 자체에 대한 것이므로 소프트웨어를 테스트 및 평가할 때 적용됩니다. 이 단계의 가치는 이해 당사자의 피드백을 얻고 계획과 문서화를 신중히 했음에도 원래 예상하거나 의도한 바를 얻지 못하는 경우를 식별할 기회를 제공하는 것입니다.

개선 이니셔티브 계획 및 구현
목적:  개선할 영역을 식별하고 이러한 개선을 위한 초기 전략을 공식화합니다.  

분석 내용과 여러 이해 당사자로부터 받은 피드백을 토대로 개선 기회를 식별하고, 보다 효율적이고 생산적이면서 효과적인 테스트가 될 수 있는 방안을 찾으십시오. 여기에는 작업 인력 재지정, 보다 효율적인 작업을 위한 인력의 2인 1조 배치, 전문화된 계약 인력 채용, 생산성 도구를 통한 효율성 향상, 결함 발견의 측면에서 보다 생산적인 대체 접근 방식과 기법 찾기 등이 포함됩니다.

대부분의 경우 테스트 노력이 조금씩 점차적으로 향상되도록 하면서 불안정한 대규모의 변경으로 인해 프로젝트가 궤도에서 이탈할 위험을 방지하는 것이 좋습니다. 하지만 대규모의 변경이 정당하고 유용한 경우도 있습니다. 적절한 개선 접근 방식을 공식화하는 데 있어 최선의 판단을 사용하고 팀이 대규모 변경사항을 채택하도록 확약하기 전에 자신의 아이디어를 다른 관리 직원과 논의하십시오.

개선 이니셔티브 모니터 및 지원
목적:  필요한 개선 이니셔티브가 만족스럽고 시기 적절한 방식으로 달성되도록 합니다.  

개선이 효과적으로 이뤄지게 하려면 성공적인 개선을 관리해야 합니다. 개선 이니셔티브를 모니터(되도록이면 채택할 때 미리 하는 것이 좋음)하여 이들의 효율성을 평가할 수 있는 방법을 식별하십시오. 직접 변경사항 채택 시 진행상태를 적극적으로 모니터하거나 이 작업을 수행할 다른 사람을 지명하십시오.

대부분의 변경사항에는 궁극적인 성공을 위해 극복해야 할 저항과 문제점이 있습니다. 발생한 문제를 신속하게 해결할 수 있도록 준비하고 이니셔티브가 계속 진행되지 않도록 하십시오. 변화를 꺼리는 사람들의 당연한 반응에 민감하게 대처하고 이들의 걱정을 적절히 해결하는 방법을 찾으십시오.

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

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

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

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



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