타스크: 테스트 결과 판별
이 타스크는 테스트 결과를 정확하게 기록하는 방법과 필요한 후속 조치의 유형에 대해 설명합니다.
목적

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

  • 인지된 제품 품질의 계속적 요약 평가 작성
  • 자세한 테스트 결과 식별 및 캡처
  • 품질 실패를 해결하기 위해 적당한 정정 조치 제안
관계
단계
모든 테스트 사건(incident) 및 실패 점검
목적:  각 사건(incident)을 조사하고 결과 문제점을 자세히 이해 

이 타스크에서 테스트 로그를 분석하여 각 테스트의 예상 결과와 실제 결과 사이의 차이점에 관한 의미있는 테스트 결과를 판별합니다. 각 사건(incident) 및 실패를 차례로 식별하고 분석하십시오. 각 발생 내용에 대해 가능한 많이 알아보십시오.

중복 사건(incident), 사건 사이의 공통된 증상과 기타 관련성을 확인하십시오. 이러한 조건이 종종 사건(incident) 그룹의 근본 원인에 대한 유용한 통찰력을 제공합니다.

변경 요청 작성 및 유지보수
목적:  평가, 관리 및 분석을 위해 추적 도구에 변경 요청 정보 입력 

차이점은 테스트 대상 항목의 잠재적 결함을 표시하며, 취할 수 있는 적합한 정정 조치의 표시와 함께 사건(incident) 또는 변경 요청으로서 추적 시스템에 입력되어야 합니다.

하위 주제:

사건 사실 확인 페이지의 맨 위로

정확한 지원 데이터를 사용할 수 있는지 확인하십시오. 첨부할 데이터를 직접 변경 요청에 조합하거나, 데이터를 별도로 얻을 수 있는 위치를 참조하십시오.

가능할 경우 항상 문제점이 재생 가능한지 확인하십시오. 재생 가능한 문제점은 개발자의 주의를 끌고 결국 수정될 가능성이 훨씬 큽니다. 재생할 수 없는 문제점은 개발 팀을 실망시키며 무익한 연구에 유용한 프로그래밍 자원을 낭비하게 만듭니다. 이러한 사건(incident)을 로그하되 재생 불가능한 사건을 재생 가능한 사건과 분리하여 식별하는 것이 좋습니다.

변경 요청 세부사항 분류 페이지의 맨 위로

특히 변경 요청의 표제는 이해할 수 있도록 작성해야 합니다. 표제가 명확하고 간결하며 특정 문제를 명확하게 표현하도록 하십시오. 간략한 표제는 CCB 상태 회의의 결함 목록 요약 및 논의에 유용합니다.

변경 요청의 자세한 설명은 명백하고 쉽게 이해할 있어야 합니다. 가능한 빨리 변경 요청을 로그하는 것이 좋지만 변경 요청을 개발 팀에게 보이기 전에 먼저 설명을 살펴보고 개선하는 것이 좋습니다.

가능한 많은 솔루션 후보를 제공하십시오. 이는 설명에 있는 모호함을 줄이는 데 도움이 되며 종종 명백하게 하는 데 도움이 됩니다. 또한 솔루션이 예외에 근접하게 될 가능성을 증가시킵니다. 게다가 테스트 팀이 문제점을 발견하여 적당한 솔루션을 식별하는 데 도움이 됩니다.

포함시킬 기타 세부사항은 화면 이미지 캡처, 테스트 데이터 파일, 자동화된 테스트 스크립트, 진단 유틸리티의 산출물 및 개발자가 근본적인 결함을 분리하고 정정하는 데 도움이 되는 모든 기타 정보입니다.

상대적 영향 심각도 및 분석 우선순위 표시 페이지의 맨 위로

관리 및 개발 팀에게 문제점의 심각도의 표시를 제공하십시오. 더 큰 팀의 경우 실제 분석 우선순위는 보통 관리 팀에서 판별하도록 남겨 두지만, 개인에게 원하는 분석 우선순위를 표시하고 그 뒤에 필요에 따라서 조정하도록 허용할 수 있습니다. 일반적으로, 변경 요청에 기본적으로 평균 분석 우선순위를 지정하고 필요에 따라 사례별로 해당 우선순위를 올리거나 내릴 것을 권장합니다.

변경 요청이 처리되지 않을 경우 프로덕션 환경에 미칠 영향과 변경 요청이 처리되지 않을 경우 테스트 노력에 미칠 영향을 구별해야 할 수 있습니다. 사용자에게 미치는 심각성의 인식 뿐 아니라 결함이 테스트 노력에 영향을 미치는 시기도 관리 팀이 알아야 합니다.

때로는 두 속성이 모두 필요한 이유를 미리 알기 어렵습니다. 실제로 사건(incident)은 시스템 붕괴와 같이 심각하지만 사건 재생에 필요한 조치는 거의 발생하지 않는 경우도 있습니다. 이 경우 팀은 심각도를 높음으로 표시하지만 매우 낮은 분석 우선순위를 표시할 수 있습니다.

추가 변경 요청을 별도로 로그

사건(incident)은 종종 "연기가 있는 곳에 화재가 있다"라는 오랜 속담과 관련됩니다. 즉 하나의 변경 요청을 식별하고 로그하면서 종종 처리되어야 하는 다른 문제를 식별하게 됩니다. 이렇게 추가로 찾은 결과를 단순히 기존 변경 요청에 추가하려고 하지 마십시오. 해당 정보가 직접 관련되고 기존 문제를 더 잘 해결하는 데 도움이 되는 경우에는 그렇게 해도 괜찮습니다. 기타 문제가 다른데 기존 CR에 대해 식별하면, 해당 문제에 조치가 취해지지 않거나 정당하게 적합한 우선순위를 얻지 못하거나 기타 문제가 처리되는 속도에 영향을 미칠 수 있습니다.

상태 분석 및 평가
목적:  테스트의 주요 척도 및 지표를 계산 및 전달 

하위 주제:

사건 분배

기능 영역, 품질 위험성, 지정된 테스트 및 지정된 개발자와 같이 사건(incident)이 분배되는 영역을 기반으로 사건을 분석하십시오.

평균 결함 수 이상인 것으로 나타나는 기능 영역과 같이 분배의 패턴을 찾으십시오. 또한 과로하여 해당 작업 품질이 나빠지고 있는 개발자 및 테스터를 찾으십시오.

테스트 실행 적용 범위

테스트 실행 적용 범위를 평가하려면 테스트 로그를 검토하고 다음을 판별해야 합니다.

  • 이 테스트 주기에서 수행된 테스트(테스트 스크립트 또는 테스트 케이스) 수와 모든 의도한 테스트 대상 항목에 대한 총 테스트 수 사이의 비율.
  • 성공적으로 수행된 테스트 케이스의 비율.

목표는 이 테스트 주기의 대상이 되는 테스트의 충분한 수가 유용하게 실행되도록 하는 것입니다. 이것이 불가능한 경우 또는 해당 실행 데이터를 증대시키려면 다음을 기반으로 하나 이상의 추가 테스트 적용 범위 기준을 식별할 수 있습니다.

  • 품질 위험성 또는 우선순위
  • 스펙 기반 적용 범위(요구사항 등)
  • 비즈니스 요구 또는 우선순위
  • 코드 기반 적용 범위

개념: 테스트의 주요 척도, 요구사항 기반 테스트 적용 범위를 참조하십시오.

이 테스트 주기에 대한 테스트 평가 보고서에 현재 테스트 결과를 기록하십시오.

변경 요청 통계

결함을 분석하려면 결함 분석 전략의 일부로 선택된 척도를 검토하고 분석해야 합니다. 사용되는 가장 일반적인 결함 척도는 다음의 여러 척도를 포함합니다(종종 그래프 형식으로 표시됨).

  • 결함 밀도 - 결함 수가 하나 이상의 결함 속성(예: 기능 영역에 대한 분배 또는 상태 또는 심각도와 비교한 품질 위험성)의 함수로 표시됩니다.
  • 결함의 상태동향 - 결함 수가 시간에 대한 함수로 표시됩니다.
  • 결함 기간 - 결함의 지정된 상태(열림, 신규, 확인 대기 등)로 유지된 시간의 함수로 결함 수가 표시되는 특수 결함 밀도 보고서

이 테스트 주기의 척도를 현재 반복에 대한 실행 중 총계 및 이전 반복 분석의 척도와 비교하여 시간에 따른 최근에 만들어진 상태동향을 보다 잘 이해하십시오.

요청에 대해 지원하는 찾은 결과와 함께 다이어그램 양식으로 결과를 제공하는 것이 바람직합니다.

현재 품질 경험의 평가 작성
목적:  소프트웨어 제품에서 현재 인지하거나 경험한 품질에 대한 피드백 제공 

소프트웨어 제품 품질의 좋은 측면과 나쁜 측면을 모두 강조하면서 현재 품질 경험의 요약을 공식화하십시오.

미해결 품질 위험성 평가 작성
목적:  프로젝트에 가장 많은 잠재적 노출을 제공하는 나머지 위험성 영역에 대한 피드백 제공 

품질 위험성 측면에서 아직 처리되지 않은 영역을 식별 및 설명하고 이것이 팀에 남기는 영향과 노출을 표시하십시오.

각 미해결 품질 위험성이 가질 것으로 고려하는 우선순위의 지표를 제공하고 해당 우선순위를 사용하여 이러한 문제가 처리되어야 하는 순서를 표시하십시오.

테스트 적용 범위 평가 작성
목적:  테스트 적용 범위 분석의 요약 평가 작성 

테스트 실행 적용 범위 단계의 작업을 기반으로 하여 데이터가 표시하는 상태 및 정보의 간략한 요약문을 제공하십시오.

테스트 평가 요약 초안 작성
목적:  테스트 결과를 이해 당사자(stakeholder)에게 통보하고 품질 및 테스트 상태의 객관적인 평가 작성 

테스트 평가 요약으로 이 테스트 주기에 대한 테스트 결과를 제공하십시오. 이 단계는 요약의 초안을 개발하는 것입니다. 이는 수집된 이전 정보를 읽을 수 있는 요약 보고서로 어셈블하여 수행됩니다. 이해 당사자(stakeholder) 집단 및 프로젝트 컨텍스트에 따라서 요약의 실제 형식과 내용이 달라집니다.

종종 더 광범위한 집단에 공개하기 전에 초안을 이해 당사자(stakeholder)의 소집단에 분배하여 통합할 수 있는 피드백을 얻는 것이 좋습니다.

이해 당사자(stakeholder)에게 발견된 핵심사항에 대해 조언
목적:  평가 요약을 적절하게 진행하고 공표 

어떤 방법이든 적합한 방법을 사용하여 이 정보를 공개하십시오. 피드백을 수집하고 다음 조치를 판별할 수 있도록 이러한 정보를 중앙 프로젝트 사이트에 공개하거나 정기적으로 갖는 상태 회의에서 제출하는 것을 고려하는 것이 바람직합니다.

평가 요약을 공개하는 것은 때로는 민감한 정치적 문제가 될 수 있음에 주의하십시오. 개발 관리자와 협상하여 개발자들의 작업을 존중하면서 찾은 결과의 정직하고 정확한 요약을 반영하는 방식으로 결과를 제시하십시오.

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

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

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

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



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