버그 추세 보고서
버그 추세 보고서를 사용하여 팀이 얼마나 자주 버그를 발견하고 해결하는지를 추적할 수 있습니다.이 보고서에서는 보고되고, 해결되고, 닫히는 버그의 롤링 또는 이동 평균을 시간 경과에 따라 보여 줍니다.큰 팀 또는 다수의 버그를 관리하는 경우 매주 버그 추세 보고서를 모니터링하여 팀이 버그를 얼마나 효율적으로 찾고, 해결하고, 닫고 있는지를 파악할 수 있습니다.
보고서 액세스, 새로 고침 또는 관리 방법에 대한 자세한 내용은 보고서(Agile)를 참조하십시오.
[!참고]
이 보고서에는 SQL Server Reporting Services로 프로비전된 팀 프로젝트를 포함하는 팀 프로젝트 컬렉션이 필요합니다.팀 탐색기를 열고 팀 프로젝트 노드를 확장한 경우
보고서가 나타나지 않으면 이 보고서를 사용할 수 없습니다.
항목 내용
|
다음과 같은 질문에 답할 때 이 보고서를 사용할 수 있습니다.
|
필요한 권한
보고서를 보려면 SQL Server Reporting Services에서 브라우저 역할이 할당된 그룹에 할당되거나 속해야 합니다.자세한 내용은 팀 프로젝트에 사용자 추가 또는 권한 관리를 참조하십시오.
보고서의 데이터
버그 추세 보고서는 지정된 필터를 기준으로 팀이 열고, 해결하고, 닫은 버그의 평균 롤링 수를 계산합니다.롤링 평균은 계산되는 날 이전의 7일에 대한 것입니다.즉, 보고서는 당일 이전의 7일에 대해 각 상태의 평균 버그 수를 계산한 후에 이 결과를 7로 나눕니다.데이터는 데이터 웨어하우스에서 파생됩니다.
다음 그림에서는 버그 추세 보고서의 예를 보여 줍니다.
.png "버그 추세 보고서 예제")
이 보고서는 최대 세 줄의 그래프를 표시하며 각 그래프는 활성화된 버그, 해결된 버그 및 닫힌 버그의 평균 롤링 수를 나타냅니다.
다음과 같은 방식으로 보고서를 필터링할 수 있습니다.
보고서의 시작 날짜와 종료 날짜를 변경합니다.
반복 및 영역 경로 또는 버그 상태, 우선 순위, 심각도를 지정하여 보고서에서 계산되는 버그를 필터링합니다.
자세한 내용은 이 항목의 뒷부분에 나오는 보고서 필터링을 참조하십시오.
.gif "Dd380674.collapse_all(ko-kr,VS.110).gif")
버그 추적에 필요한 활동
버그 추세 보고서의 유용성과 정확도를 높이려면 팀에서 다음 활동을 수행해야 합니다.
버그를 정의하고 해당 반복 및 영역 경로를 지정합니다.
수정되고, 확인되고, 닫힘에 따라 각 버그의 상태를 업데이트합니다.
심사 도중 각 버그의 우선 순위 및 심각도를 지정합니다.
심사 통합 문서를 사용하여 버그의 반복, 영역, 상태, 우선 순위 및 심각도를 빠르게 업데이트할 수 있습니다.자세한 내용은 심사 통합 문서를 참조하십시오.
스프린트 또는 반복 기간 설정
현재 반복에 대한 버그 추세를 확인하려면 보고서의 시작 날짜 및 종료 날짜가 현재 반복 주기의 시작 날짜 및 종료 날짜와 일치해야 합니다.
반복 기간을 변경하려면
반복 시작(날짜) 또는 반복 종료(날짜) 옆에 있는 달력 아이콘을 클릭한 다음 날짜를 클릭합니다.
보고서 보기를 클릭합니다.
보고서 해석
제품 개발 주기의 어느 시점에 있는지에 따라 버그 비율이 달라집니다.팀은 반복의 후반 단계보다는 전반 단계에서 더 많은 버그를 발견해야 합니다.팀은 제품 주기의 끝에 가까운 반복에서 대부분의 버그를 닫아야 합니다.
모든 현재 팀 프로젝트 활동 그리고 버그 상태 및 다시 활성화 보고서가 제공하는 기타 수치와 비교하여 버그를 검토할 때 버그 비율을 가장 정확하게 해석할 수 있습니다.예를 들어 잘못 작성된 코드인 경우, 새로 통합된 코드인 경우, 향상된 테스트 방법을 사용하는 경우 또는 "버그 배시"와 같은 예외적인 이벤트의 경우 팀이 버그를 매우 빠르게 찾아낼 수 있습니다.반면에 고품질 제품의 경우 또는 비효율적인 테스트 방법을 사용하는 경우에는 버그를 찾기가 어렵습니다.코드 검사, 코드 변동, 테스트 속도 등의 수치를 참조하면 버그 추세를 보다 정확하게 평가할 수 있습니다.
제품 주기의 끝부분에서 제품이 안정화될 때는 버그의 발견 빈도가 줄어야 합니다.
버그 추세 보고서에는 다음 표의 왼쪽 열에서 설명하는 지표 중 하나 이상이 나타날 수 있습니다.오른쪽 열의 질문을 검토하면 어떤 영역을 해결해야 하는지 보다 자세히 알 수 있습니다.
지표 |
질문 사항 |
|---|---|
팀이 연속적인 기간 동안 거의 동일한 숫자의 버그를 발견하고 있음.팀에서 몇 주 동안 또는 몇 번의 반복 동안 같은 숫자의 버그를 발견하면 근본적인 원인을 확인해야 합니다.테스트 주기의 초반에는 테스트가 충분히 정밀하거나 진전되지 않아서 많은 버그가 발견되지 않을 수 있습니다.초기 반복에서는 이러한 상황이 예상됩니다.하지만 제품이 완성되어 감에 따라 보다 광범위한 시나리오와 통합에 대한 테스트가 이루어져야 합니다. |
|
팀이 기간별로 많은 버그를 발견하고 있음.불량 코드인 경우, 새로 통합된 코드인 경우, 효율적인 테스트 방법을 사용하는 경우 또는 "버그 배시"와 같은 특정 이벤트의 경우 팀이 버그를 쉽게 찾아낼 수 있습니다. |
|
팀이 기간별로 적은 수의 버그를 발견하고 있음.고품질 솔루션의 경우 또는 비효율적인 테스트 방법을 사용하는 경우 팀이 버그를 찾아내는 데 어려움을 겪을 수 있습니다. |
|
팀이 기간별로 많은 버그를 해결하고 있음.해결 비율이 높은 것은 일반적으로 팀이 작업을 훌륭히 진행하고 있다는 의미입니다. |
|
팀이 버그를 빨리 해결하지만 닫지 않고 있음.버그 수정을 확인해야 할 팀 멤버가 너무 적은 것일 수도 있고, 다른 우선 순위 작업 때문에 해결된 버그를 아직 닫지 못한 것일 수도 있습니다. |
|
보고서의 정상적인 버전
정상적인 버그 추세 보고서에는 팀이 개발 주기의 초반에 더 많은 버그를 발견하고, 릴리스의 끝이 다가올수록 더 적은 수의 버그를 발견하고 있는 것으로 나타납니다.팀은 프로젝트의 끝에 다가갈수록 더 많은 버그를 해결하고 닫아야 합니다.
팀에서 버그를 발견하는 속도보다 해결하는 속도가 빨라지면 활성 버그의 수가 줄어들기 시작합니다.팀이 발견하는 버그의 수가 줄어들기 시작하면 제품이 안정화되어 가는 것입니다.
보고서의 비정상적인 버전
비정상적인 버그 추세 보고서에는 팀이 출시일이 가까워질수록 더 많은 버그를 발견하고 있거나 버그를 더 느리게 해결하고 있는 것으로 나타날 수 있습니다.이러한 상황에서는 버그가 수정되지 않고 있기 때문에 팀의 버그 백로그가 커집니다. 이러한 상황의 원인을 조사해 보는 것이 좋습니다.다음 그림에서는 많은 버그를 발견하고, 발견하는 것보다 더 적은 수의 버그를 해결하고, 해결하는 것보다 더 적은 수의 버그를 닫는 팀의 보고서를 보여 줍니다.
.png "버그 추세 보고서의 비정상적인 버전")
보고서 필터링 및 표시 변경
다음과 같은 방법으로 버그 추세 보고서를 필터링하거나 표시를 변경할 수 있습니다.
보고서의 시작 날짜와 종료 날짜를 변경합니다.
반복 및 영역 경로, 상태, 우선 순위 또는 심각도를 지정하여 보고서에서 계산되는 버그를 필터링합니다.
다음 그림에서는 사용 가능한 필터를 보여 줍니다.
.png "버그 추세 보고서의 필터")
보고서에서 계산되는 버그를 필터링하려면
다음 작업 중 하나 또는 둘 모두를 수행합니다.
반복 및 영역 목록에서 포함할 각 반복이나 제품 영역의 확인란을 선택합니다.
상태, 우선 순위 또는 심각도 목록에서 포함할 각 상태, 우선 순위 또는 심각도의 확인란을 선택합니다.
보고서 보기를 클릭합니다.