버그 추적

요구 사항을 확인하기 위해 테스트를 실행할 때는 버그를 찾아야 합니다. 발견된 각 버그의 진행 상태를 기술하고 추적하는 데는 버그 작업 항목을 사용하십시오.

버그 작업 항목을 만드는 방법에 대한 자세한 내용은 Team Web Access를 사용하여 수동 테스트 실행을 참조하십시오. 버그가 발견되면 이 항목의 과정을 따라 버그의 우선 순위를 지정하고, 버그가 수정되었는지 확인하고, 해당 작업과 관련된 결정 사항에 대한 레코드가 있는지 확인합니다.

버그 심사

프로젝트의 개발 작업 및 테스트가 시작된 후에는 설정된 간격에 따라 심사 회의를 소집해야 합니다. 이 회의를 소집하는 간격과 회의 시간은 상황에 따라 다릅니다.

일반적으로 버그 심사 회의는 프로젝트 관리자가 개최하며, 팀장과 특정 프로젝트 위험에 대한 의견을 제시할 수 있는 비즈니스 분석가 및 관련자가 이 회의에 참석합니다. 프로젝트 관리자는 새 버그 및 다시 열린 버그에 대한 활성 버그 쿼리를 사용하여 심사할 버그 목록을 생성합니다.

심사가 시작되기 전에 해결해야 하는 버그와 해결 우선 순위를 결정하기 위한 기준을 정합니다. 이 기준은 일반적으로 버그의 심각도, 가치(또는 지연에 따른 기회 비용)가 큰 기능과 관련된 버그, 또는 그 밖의 프로젝트 위험을 식별합니다.

심사 기준은 팀 프로젝트의 문서 폴더에 저장해야 합니다. 시간이 지나면서 이 문서는 업데이트됩니다. 단, 프로젝트에 버전 제어가 설정되어 있고, 감사 및 평가를 위한 증명 정보용으로 프로젝트의 지정된 시점에 사용되는 특정 기준을 가져올 수 있어야 합니다.

프로젝트의 초기에는 대개 심사하는 대부분의 버그를 수정하도록 결정합니다. 그러나 프로젝트가 진행되면서 심사 기준(또는 목표)을 높여 수정되는 버그 수를 줄일 수 있습니다.

심사 기준을 높이고 보고된 버그를 수정하지 않은 채로 두도록 허용하는 것은 취사 선택의 문제로, 이는 버그 수정이 프로젝트 범위, 예산 및 일정을 준수하는 것보다 덜 중요하다고 보는 것입니다.

사용자가 정한 기준을 사용하여 수정할 버그와 버그 상태, 우선 순위, 심각도 및 기타 필드의 설정 방법을 결정합니다. 기본적으로 템플릿에서는 "수정해야 함"을 의미하는 1부터 "중요하지 않음"을 의미하는 4까지 네 단계의 우선 순위를 제공합니다. 프로세스 템플릿에서 정의를 변경할 경우에는 지침, 도움말 텍스트 및 모든 기준 문서도 업데이트해야 합니다.

버그 수정

버그가 심사에 통과하고 버그에 우선 순위가 지정된 후에는 추가 조사를 위해 개발자에게 버그를 할당해야 합니다.

버그 작업 항목에는 재현 단계를 위한 탭이 있으며 이 탭에서는 버그를 재현하는 데 필요한 사항을 제공해야 합니다. 그러나 어려운 버그를 재현할 수 있도록 IntelliTrace도 사용할 수 있어야 합니다. IntelliTrace에 대한 자세한 내용은 소프트웨어 품질 추적을 참조하십시오.

개발자는 작업 과정에 관한 사항을 결정한 후 버그 작업 항목에서 결정 사항을 기록해야 합니다.

수정에 관한 결정

개발자는 다른 팀 멤버와 협력하여 코드의 다른 부분에 영향을 주며 의미 있는 재발 테스트가 필요할 수 있는 수정 사항을 추천할 수 있습니다. 버그 작업 항목 기록에서는 감사 또는 SCAMPI(Standard CMMI Appraisal Method for Process Improvement) 평가에 유용한 의사 결정 분석 및 위험 관리 증명 정보를 문서화하므로 이러한 수정 사항의 위험을 평가하는 데 관련된 의견을 여기에 기록해야 합니다. CMMI에 대한 자세한 내용은 CMMI의 배경을 참조하십시오.

버그 수정에 대한 단위 테스트 업데이트 및 실행

단위 테스트에서는 코드 단위가 올바르게 구현되었는지 확인합니다. 단위 테스트를 작성하고 수행하면 테스트가 시작되기 전에 버그를 식별할 수 있으며 그에 따라 품질 제어 비용을 줄일 수 있습니다. 개발자는 개발 작업 구현 또는 버그 수정 구현의 일부로 작성할 모든 코드에 대해 단위 테스트를 작성해야 합니다. 자세한 내용은 단위 테스트를 사용하여 코드 확인을 참조하십시오.

테스트 우선 개발 전략에서는 코드를 수정하기 전에 단위 테스트를 작성할 수도 있습니다. 이 유형의 전략은 Agile 소프트웨어 개발자들이 선호합니다. CMMI에서는 단위 테스트를 특정 순서로 작성하지 않아도 되며 효과적인 기능 확인만 거치면 됩니다.

단위 테스트가 작성되었고 실행되었다는 증명 정보는 CMMI 평가에 필요합니다. 코드 수정 사항에 대한 작업(task) 작업 항목에 테스트를 연결하고 해당 작업을 버그 작업 항목에 연결해야 합니다. 이렇게 하면 SCAMPI 수석 평가자가 찾는 증명 정보를 추적할 수 있습니다.

버그 수정을 위한 코드 검토 및 리팩터링

코드 검토는 코드를 매일 작성하는 빌드에 통합하기 전에 새 코드나 변경된 코드가 설정된 품질 목표를 충족하는지 확인하는 데 사용됩니다. 품질과 관련하여 고려해야 하는 사항은 코딩 표준, 아키텍처 및 디자인 준수 여부, 성능, 안정성, 보안 등입니다. 코드 검토를 통해 다른 개발자로부터 코드 작성 방법에 대한 유용한 정보를 얻을 수도 있습니다. 코드 검토 및 리팩터링 방법에 대한 자세한 내용은 개발 작업 구현을 참조하십시오.

버그 닫기

버그를 수정한 후에는 버그 작업 항목을 닫기 전에 이를 테스터에게 할당하여 문제가 해결되었는지 확인해야 합니다.

수정 확인

수정 사항을 확인하기 위해 테스터는 버그를 재현하고, 예기치 않은 추가 동작을 찾은 다음, 필요한 경우 버그를 다시 활성화해야 합니다.

버그 해결 여부를 확인할 경우 버그가 완전히 수정되지 않았음을 발견할 수도 있고 해결 방법이 만족스럽지 않을 수도 있습니다. 이 경우 버그를 해결한 사람과 버그에 대해 논의하여 합의에 도달하면 버그를 다시 활성화합니다. 버그를 다시 활성화할 경우 정보가 보존되도록 버그 설명에 해당 버그를 다시 활성화하는 이유를 포함해야 합니다.

버그 작업 항목 닫기

버그는 여러 가지 이유로 닫을 수 있습니다. 간단한 예로, 버그가 수정된 것으로 확인된 경우 버그를 닫을 수 있습니다. 그러나 버그가 다음 버전의 제품까지 연기되거나, 버그가 재현할 수 없는 버그인 것으로 입증되거나, 중복된 버그로 확인되는 경우에도 버그를 닫을 수 있습니다. 버그가 닫힌 이유에 대해 혼동이 없도록 이러한 각 이유를 문서화하고 버그를 올바르게 닫아야 합니다.