목적:
|
평가, 관리 및 분석을 위해 추적 도구에 변경 요청 정보 입력
|
차이점은 테스트 대상 항목의 잠재적 결함을 표시하며, 취할 수 있는 적합한 정정 조치의 표시와 함께 사건(incident) 또는 변경 요청으로서 추적 시스템에 입력되어야 합니다.
하위 주제:
정확한 지원 데이터를 사용할 수 있는지 확인하십시오. 첨부할 데이터를 직접 변경 요청에 조합하거나, 데이터를 별도로 얻을 수 있는 위치를 참조하십시오.
가능할 경우 항상 문제점이 재생 가능한지 확인하십시오. 재생 가능한 문제점은 개발자의 주의를 끌고 결국 수정될 가능성이 훨씬 큽니다. 재생할 수 없는 문제점은 개발 팀을 실망시키며 무익한 연구에 유용한 프로그래밍
자원을 낭비하게 만듭니다. 이러한 사건(incident)을 로그하되 재생 불가능한 사건을 재생 가능한 사건과 분리하여 식별하는 것이 좋습니다.
특히 변경 요청의 표제는 이해할 수 있도록 작성해야 합니다. 표제가 명확하고 간결하며 특정 문제를 명확하게 표현하도록 하십시오. 간략한 표제는 CCB
상태 회의의 결함 목록 요약 및 논의에 유용합니다.
변경 요청의 자세한 설명은 명백하고 쉽게 이해할 있어야 합니다. 가능한 빨리 변경 요청을 로그하는 것이 좋지만 변경 요청을 개발 팀에게 보이기 전에 먼저 설명을 살펴보고 개선하는 것이 좋습니다.
가능한 많은 솔루션 후보를 제공하십시오. 이는 설명에 있는 모호함을 줄이는 데 도움이 되며 종종 명백하게 하는 데 도움이 됩니다. 또한 솔루션이 예외에 근접하게 될 가능성을 증가시킵니다. 게다가 테스트 팀이
문제점을 발견하여 적당한 솔루션을 식별하는 데 도움이 됩니다.
포함시킬 기타 세부사항은 화면 이미지 캡처, 테스트 데이터 파일, 자동화된 테스트 스크립트, 진단 유틸리티의 산출물 및 개발자가 근본적인 결함을 분리하고 정정하는 데 도움이 되는 모든 기타 정보입니다.
관리 및 개발 팀에게 문제점의 심각도의 표시를 제공하십시오. 더 큰 팀의 경우 실제 분석 우선순위는 보통 관리 팀에서 판별하도록 남겨 두지만, 개인에게 원하는 분석 우선순위를 표시하고 그 뒤에 필요에 따라서
조정하도록 허용할 수 있습니다. 일반적으로, 변경 요청에 기본적으로 평균 분석 우선순위를 지정하고 필요에 따라 사례별로 해당 우선순위를 올리거나 내릴 것을 권장합니다.
변경 요청이 처리되지 않을 경우 프로덕션 환경에 미칠 영향과 변경 요청이 처리되지 않을 경우 테스트 노력에 미칠 영향을 구별해야 할 수 있습니다. 사용자에게 미치는 심각성의 인식 뿐 아니라 결함이 테스트 노력에
영향을 미치는 시기도 관리 팀이 알아야 합니다.
때로는 두 속성이 모두 필요한 이유를 미리 알기 어렵습니다. 실제로 사건(incident)은 시스템 붕괴와 같이 심각하지만 사건 재생에 필요한 조치는 거의 발생하지 않는 경우도 있습니다. 이 경우 팀은 심각도를
높음으로 표시하지만 매우 낮은 분석 우선순위를 표시할 수 있습니다.
사건(incident)은 종종 "연기가 있는 곳에 화재가 있다"라는 오랜 속담과 관련됩니다. 즉 하나의 변경 요청을 식별하고 로그하면서 종종 처리되어야 하는 다른 문제를 식별하게 됩니다. 이렇게 추가로 찾은 결과를
단순히 기존 변경 요청에 추가하려고 하지 마십시오. 해당 정보가 직접 관련되고 기존 문제를 더 잘 해결하는 데 도움이 되는 경우에는 그렇게 해도 괜찮습니다. 기타 문제가 다른데 기존 CR에 대해 식별하면, 해당
문제에 조치가 취해지지 않거나 정당하게 적합한 우선순위를 얻지 못하거나 기타 문제가 처리되는 속도에 영향을 미칠 수 있습니다.
|