타스크: 평가 및 추적성 요구 정의
이 타스크는 준수할 평가, 추적성 및 전체 전략에 대한 요구사항을 정의하는 방법에 대해 설명합니다.
원칙: 테스트
관계
단계
평가 및 추적성 요구사항 식별
목적:  소프트웨어 평가 프로세스에 대한 인도물을 이해하고 연관된 요구사항을 식별합니다.  

반복 계획을 검토하고 이 예정된 작업에 대한 특정 평가 요구사항을 식별하십시오. 평가와 추적성의 두 측면에서 필요한 사항에 대해 이해 당사자에게 문의하십시오.

또한 테스트 노력이 진행 중인 동안 또는 테스트 노력이 완료될 때 테스트 노력을 공식적으로 감사할지 여부도 고려하십시오. 정규 감사 요구사항에 따라 충분한 테스트가 수행되었음을 입증하는 증거로 추가 문서와 레코드를 보존해야 할 수도 있습니다.

제한조건 고려
목적:  요구사항 구현 능력(또는 필요성)에 영향을 줄 제한조건을 식별합니다.  

일반적으로 추적성과 평가 전략에 대한 요구사항으로 고려해야 할 "요구사항" 목록은 셀 수 없이 많지만, a) 프로젝트 팀에 필수적인 정보를 제공하고 b) 실제로 추적 및 측정할 수 있는 가장 중요한 "요구사항"에 초점을 맞추는 것이 중요합니다. 반드시 필요한 사항보다 많은 사항을 제공할 정도로 전략에 사용 가능한 자원이 충분한 경우는 거의 없습니다.

하위 주제:

허용 가능한 품질 레벨 페이지 맨 위로

"충분히" 고려할 품질 레벨을 식별하고 적절한 평가 전략을 개발하는 것은 중요합니다. 대개 품질 차원은 프로젝트 라이프사이클 전반에 걸쳐 이해 당사자의 관점에서 중요도 및 품질 레벨의 상승과 하락에 따라 품질 차원이 상승하고 하락합니다.

QA 계획과 소프트웨어 개발 계획을 검토하고 중요한 이해 당사자들을 직접 인터뷰하여 이들이 허용 가능한 품질 레벨이라고 간주하는 사항을 판별하십시오.

프로세스 및 도구 인에이블먼트 페이지 맨 위로

하위 세분성 레벨에서 별 다른 노력이 필요하지 않는 추적성과 평가에 대해 상상할 수 있다 하더라도, 이러한 접근 방식을 구현하는 것은 일반적으로 어려울 뿐 아니라 비경제적입니다. 정교한 도구의 지원을 받더라도 추적성에 대한 하위 레벨 접근 방식을 괸리하는 것은 여전히 어렵고 시간이 많이 소모됩니다. 지원되는 도구가 없으면 이것은 거의 불가능합니다. 소프트웨어 엔지니어링 프로세스 자체에서 추적성에 대한 제한조건을 적용할 수 있습니다. 예를 들어, 테스트 요구사항에서 동기 부여 요구사항까지의 추적성을 원하지만, 요구사항 자체를 주의 깊게 관리하지 않은 경우, 해당 추적성을 구현할 수 없습니다.

소프트웨어 엔지니어링 프로세스와 도구에 대한 제한조건과 제한사항을 고려하고 그에 따라 적합하고 작업 가능한 추적성과 평가 접근 방식을 선택하십시오.

가능한 전략 고려
목적:  필요한 평가 프로세스를 촉진할 하나 이상의 전략을 식별하고 이에 대해 간략히 설명합니다.  

이제 평가/추적성 요구사항 및 원하는 품질 레벨과 사용 가능한 프로세스 및 도구 지원을 통해 평가/추적성에 대한 제한조건을 보다 잘 이해할 수 있게 되었으므로, 채택할 수 있는 잠재적인 평가 전략을 고려해야 합니다. 가능한 전략 처리에 대한 자세한 내용은 Cem Kaner의 "Measurement of the Extent of Testing"(2000년 10월) 백서를 참조하십시오. (Adobe Reader 다운로드)

하위 주제:

테스트 적용 범위 분석 페이지 맨 위로

테스트 적용 범위에 대한 접근 방식에는 여러 가지가 있는데, 한 개의 적용 범위 척도만으로는 테스트 노력의 범위나 완전성을 평가하는 데 필요한 모든 적용 범위 정보가 제공되지 않습니다. 여러 적용 범위 전략을 사용할 경우 구현 노력이 더 필요하거나 덜 필요한데, 특정 측정 카테고리를 사용할 경우 적용 범위 분석 깊이가 일정 지점에 도달하면 보다 자세한 정보를 기록하는 것이 비경제적이 됩니다.

테스트 적용 범위 척도의 몇 가지 카테고리로는 요구사항, 소스 코드, 제품 클레임, 표준이 있습니다. 테스트 평가 전략에서 여러 개의 적용 범위 카테고리를 통합하는 것이 좋습니다. 대부분의 경우 테스트 적용 범위는 첫 번째 인스턴스에서 특정 테스트를 계획하고 구현하는 것을 의미합니다. 그러나 테스트 결과나 결함 분석과 함께 테스트 적용 범위 메트릭과 분석을 고려하는 것도 유용합니다.

테스트 결과 분석 페이지 맨 위로

테스트 결과 분석에 대한 일반적인 접근 방식은 단순히 긍정적인 결과나 부정적인 결과의 수를 실행된 총 테스트 수에 대한 백분율로 참조하는 것입니다. 그러나 이 방법은 테스트 결과를 분석하는 데 있어 단순하고 불완전한 접근 방식입니다.

대신 시간 경과에 따른 상대적 상태동향의 관점에서 테스트 결과를 분석할 것을 권장합니다. 각 테스트 주기 내에서 테스트할 기능 영역, 탐색할 품질 위험성 유형, 테스트의 상대적 복잡도, 각 기능 영역에 적용될 테스트 자원 등의 여러 차원에서 발생한 상대적 테스트 실패 분포를 고려하십시오.

결함 분석 페이지 맨 위로

결함 자체는 명백하게 테스트 노력의 결과와 관련이 있지만, 결함 데이터 분석은 테스트 노력의 진행상태 또는 테스트 노력의 완전성이나 완벽함에 대한 유용한 정보를 제공하지 않습니다. 그러나 일부 테스트 팀과 프로젝트 관리자의 실수는 테스트 진행상태를 측정하는 현재 결함 수로 사용되거나 개발된 소프트웨어의 품질에 대한 게이지로 사용됩니다. 그러나 이 방법은 테스트 의미 없는 접근 방식입니다.

대신 시간 경과에 따른 결함 수의 상대적 동향을 분석하여 상대적 안정성을 측정할 것을 권장합니다. 예를 들어, 테스트 노력이 상대적으로 일정하게 유지된다고 가정할 경우 새 결함 발견 비율은 반복 기간 동안 정규 "종곡선(bell curve)" 기간에 대해 측정된 것으로 간주할 수 있습니다. 발견 비율은 정점에 도달할 때까지 증가하다가 반복 끝에 도달할 때까지 감소합니다. 그러나 이 정보는 결함 해결 비율(해결 유형 분석 포함), 심각도별 결함 분포, 기능 영역별 결함 분포와 같은 기타 결함 메트릭 분석과 함께 제공해야 합니다.

정교한 도구 지원이 있으면 결함 데이터에 대한 복잡한 분석을 상대적으로 쉽게 수행할 수 있지만, 적절한 도구 지원이 없으면 훨씬 어려운 작업이 됩니다.

이해 당사자와 가능한 전략 논의
목적:  초기 이해 당사자 검토를 통해 피드백을 수집하고 필요한 경우 전략을 조정합니다.  

여러 이해 당사자에게 가능한 전략을 프리젠테이션하십시오. 일반적으로 이러한 전략에는 프로젝트 관리자, 소프트웨어 설계자, 개발 관리자, 시스템 분석가, 구성 및 변경 관리자, 배치 관리자 및 고객 대표로 구성된 그룹이 포함됩니다. 이러한 역할 각각은 품질 평가 방법과 관련이 있습니다.

프로젝트 문화에 따라 가능한 전략을 프리젠테이션하는 적절한 형식을 선택해야 합니다. 이러한 형식은 하나 이상의 비정규 회의에서 정규 프리젠테이션이나 워크샵 세션에 이르기까지 다양합니다.

평가 전략 정의 및 합의
목적:  사용할 전략에 대한 이해 당사자의 합의를 얻습니다.  

논의를 통해 피드백을 얻고 모든 이해 당사자의 요구를 해결하는 한 개의 전략으로 평가 전략을 수정하십시오.

최종 합의와 승인을 위해 평가 전략을 프리젠테이션하십시오.

도구 요구사항 정의
목적:  평가 프로세스를 가능하게 하는 지원 도구 구성 요구사항을 정의합니다.  

앞에서 설명한 바와 같이, 정교한 도구 지원이 있으면 측정 데이터에 대한 복잡한 분석을 상대적으로 쉽게 수행할 수 있지만, 적절한 도구 지원이 없으면 훨씬 어려운 작업이 됩니다.

"적용 범위 및 추적성", "결함 분석" 카테고리에 필요한 도구 지원을 고려하십시오.

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

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

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

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



자세한 정보