다음을 통해 공유


품질 대시보드(Agile)

품질 대시보드를 사용하면 개발 중인 소프트웨어의 품질과 관련하여 테스트, 개발 및 빌드 영역에서 발생하는 진행률에 대한 개요를 얻을 수 있습니다. 팀에서는 품질 대시보드를 사용하여 제품 품질에 대한 팀 목표를 지원하는 결정을 확인하고 내릴 수 있습니다.

이 대시보드를 사용하여 테스트 진행률, 빌드 상태, 버그를 해결하고 닫는 작업의 진행률, 버그 다시 활성화 비율, 테스트된 코드의 비율, 코드 변경의 추세 등을 검토할 수 있습니다. 이러한 각 메트릭은 가장 최근 4주에 대해 그려집니다.

팀 프로젝트 포털을 통해 대시보드에 액세스합니다. 포털이 사용하도록 설정되어 있고 SharePoint Server Enterprise Edition을 사용하도록 프로비전된 경우에만 품질 대시보드에 액세스할 수 있습니다. 자세한 내용은 대시보드을 참조하십시오.

항목 내용

  • 대시보드에 표시되는 데이터

  • 품질 추적에 필요한 활동

  • 품질 문제 해결

  • 품질 대시보드 사용자 지정

다음과 같은 질문에 답할 때 이 대시보드를 사용할 수 있습니다.

  • 테스트 노력을 추적하고 있습니까?

  • 팀에서 적절한 기능을 테스트하고 있습니까?

  • 팀의 버그 수정 내용 품질이 높습니까?

  • 테스트가 구식입니까?

  • 팀에서 수행하는 테스트가 충분합니까?

  • 병목 현상이 발생합니까?

필요한 권한

대시보드를 보려면 SharePoint 제품에서 팀 프로젝트에 대한 읽기 권한이 할당된 그룹에 할당되거나 속해야 합니다. 대시보드를 수정, 복사 또는 사용자 지정하려면 SharePoint 제품에서 팀 프로젝트에 대한 멤버 권한이 할당된 그룹에 할당되거나 속해야 합니다. 자세한 내용은 팀 프로젝트에 사용자 추가을 참조하십시오.

Office Excel에서 보고서를 수정하려면 SQL Server Analysis Services에서 TfsWarehouseDataReaders 보안 역할의 멤버여야 하고, SharePoint 제품에서 팀 프로젝트에 대한 멤버 권한이 할당된 그룹에 할당되거나 속해야 합니다. 자세한 내용은 Visual Studio ALM용 데이터 웨어하우스의 데이터베이스에 대한 액세스 부여을 참조하십시오.

작업 항목을 보려면 Readers 그룹의 멤버이거나 이 노드의 작업 항목 보기 권한이 허용으로 설정되어 있어야 합니다. 작업 항목을 만들거나 수정하려면 Contributors 그룹의 멤버이거나 이 노드의 작업 항목 편집 권한이 허용으로 설정되어 있어야 합니다.

대시보드에 표시되는 데이터

팀 멤버는 품질 대시보드를 사용하여 개발 중인 제품의 전체 품질을 확인할 수 있습니다. 이상적인 경우 테스트 통과 비율, 버그 및 코드 변동(code churn)은 모두 동일한 그림을 보여 주지만 그렇지 않은 경우가 많습니다. 차이를 발견하면 적절한 빌드 및 데이터 계열을 더욱 자세하게 조사해야 합니다. 품질 대시보드는 테스트 결과, 테스트의 코드 검사, 코드 변동(code churn) 및 버그를 결합하여 많은 측면을 동시에 파악하는 데 도움을 줍니다.

품질 대시보드에 표시되는 웹 파트에 대한 자세한 내용은 다음에 나오는 그림 및 표를 참조하십시오.

제품 품질 대시보드

참고

테스트 계획 진행률 보고서는 팀에서 테스트 계획을 만들고 Test Runner 및 Microsoft Test Manager를 사용하여 테스트를 실행하는 경우에만 사용할 수 있습니다.

진행률, 빌드 및 코드 차트, 보고서(1단계 ~ 6단계)는 팀 프로젝트의 데이터 웨어하우스를 사용할 수 없는 경우 나타나지 않습니다.

품질 대시보드에 나타나는 차트를 해석하거나 업데이트하거나 사용자 지정하는 방법에 대한 자세한 내용은 다음 표에 나와 있는 항목을 참조하십시오.

웹 파트

표시되는 데이터

관련 항목

1단계

가장 최근 4주 동안 가장 최근에 기록된 결과(실행 안 함, 차단됨, 실패 또는 성공)로 그룹화된 모든 테스트 사례의 테스트 결과를 보여 주는 누적 영역형 그래프입니다.

테스트 계획 진행률 Excel 보고서

테스트 계획 진행률 보고서

2단계

가장 최근 4주 동안 실패 또는 성공한 빌드의 수를 보여 주는 누적 세로 막대형입니다.

빌드 상태 보고서

빌드 상태 Excel 보고서

3단계

가장 최근 4주 동안 발생한 모든 버그의 상태별로 그룹화된 누적 개수에 대한 누적 영역형 그래프입니다.

버그 진행률 Excel 보고서

버그 진행률 Excel 보고서

4단계

가장 최근 4주 동안 팀에서 해결됨 또는 닫힘 상태로부터 다시 활성화한 버그의 수에 대한 누적 영역형 그래프입니다.

버그 다시 활성화 Excel 보고서

버그 다시 활성화 Excel 보고서

5단계

가장 최근 4주 동안 BVT(빌드 확인 테스트) 및 다른 테스트에서 테스트된 코드의 비율을 보여 주는 꺾은선형 차트입니다.

코드 검사 보고서

코드 검사 Excel 보고서

6단계

팀에서 가장 최근 4주 동안 빌드 전에 체크 인에서 추가, 제거 및 변경한 코드의 줄 수를 보여 주는 누적 영역형 그래프입니다.

코드 변동(code churn) 보고서

코드 변동(code churn) Excel 보고서

7단계

예정 이벤트의 목록입니다. 이 목록은 SharePoint 웹 파트에서 파생됩니다.

이벤트 웹 파트 가져오기

해당 없음

8단계

활성 작업 항목, 해결된 작업 항목 및 닫힌 작업 항목의 수입니다. 각 번호를 선택하여 작업 항목의 목록을 열 수 있습니다. 이 목록은 Team Web Access 웹 파트에서 파생됩니다.

프로젝트 작업 항목 웹 파트

해당 없음

9

최근 빌드와 해당 상태의 목록입니다. 특정 빌드를 선택하여 자세한 정보를 볼 수 있습니다. 이 목록은 Team Web Access 웹 파트에서 파생됩니다.

최근 빌드 웹 파트

범례:

빌드가 진행 중임: 빌드 시작되지 않음

빌드가 시작되지 않음: 빌드 진행 중

빌드가 성공함: 빌드 성공

빌드가 실패함: 빌드 실패

빌드가 중지됨: 빌드 중지됨

빌드가 부분적으로 성공함: 빌드 부분 성공

빌드 실행, 모니터링 및 관리

10

가장 최근의 체크 인 목록입니다. 특정 체크 인을 선택하여 자세한 정보를 볼 수 있습니다. 이 목록은 Team Web Access 웹 파트에서 파생됩니다.

최근 체크 인 웹 파트

코드 개발 및 보류 중인 변경 내용 관리

품질 모니터링에 필요한 활동

품질 대시보드의 유용성과 정확도를 높이려면 팀에서 이 단원에 설명된 활동을 수행해야 합니다.

테스트 계획 진행률 추적에 필요한 활동

테스트 계획 진행률 보고서의 유용성과 정확도를 높이려면 팀에서 다음과 같은 작업을 수행해야 합니다.

  • 테스트 사례와 사용자 스토리를 정의하고 테스트 사례에서 사용자 스토리로 연결되는 테스트한 사람 링크를 만듭니다.

  • 테스트 계획을 정의하고 테스트 사례를 테스트 계획에 할당합니다.

  • 수동 테스트의 경우 테스트 사례에서 각 유효성 검사 단계의 결과를 성공 또는 실패로 표시합니다.

    중요

    테스터는 유효성 검사 단계를 수행하는 경우 테스트 단계의 상태를 표시해야 합니다.테스트 사례의 전체 결과는 테스터가 표시한 모든 테스트 단계의 상태를 반영합니다.따라서 테스터가 테스트 단계를 실패로 표시했거나 아무 것도 표시하지 않은 경우에는 테스트 사례의 상태가 실패로 설정됩니다.

    자동화된 테스트의 경우 각 테스트 사례가 통과 또는 실패로 자동으로 표시됩니다.

  • (선택 사항) 필터링을 지원하려면 반복영역 경로를 각 테스트 사례에 할당합니다.

    참고

    영역 및 반복 경로를 정의하는 방법에 대한 자세한 내용은 영역 및 반복 경로 추가 및 수정을 참조하십시오.

버그 진행률 및 버그 다시 활성화 추적에 필요한 활동

버그 진행률 및 버그 다시 활성화 보고서의 유용성과 정확도를 높이려면 팀에서 다음 활동을 수행해야 합니다.

  • 버그를 정의합니다.

  • 팀에서 각 버그를 수정하거나 확인하거나 닫거나 다시 활성화할 때 버그의 상태를 업데이트합니다.

  • (선택 사항) 반복 또는 영역 필드로 필터링하려면 각 버그의 반복영역 경로를 지정합니다.

빌드 상태, 코드 검사 및 코드 변동(code churn) 추적에 필요한 활동

빌드 상태, 코드 검사 및 코드 변동(code churn) 보고서의 유용성과 정확도를 높이려면 팀 멤버가 다음 활동을 수행해야 합니다.

  • 빌드 시스템 구성. Team Foundation Build를 사용하려면 빌드 시스템을 설정해야 합니다.

    자세한 내용은 빌드 시스템 구성 및 관리을 참조하십시오.

  • 빌드 정의를 만듭니다. 여러 개의 빌드 정의를 만든 다음 각 빌드 정의를 실행하여 서로 다른 플랫폼에 대한 코드를 생성할 수 있습니다. 또한 각 빌드를 서로 다른 구성에 대해 실행할 수 있습니다.

    자세한 내용은 빌드 프로세스 정의을 참조하십시오.

  • 빌드의 일부로 자동 실행되도록 테스트 정의. 빌드 정의 과정에서 빌드의 일부로 실행하거나 테스트가 실패할 경우 실패하도록 테스트를 정의할 수 있습니다.

    자세한 내용은 빌드 프로세스에 기본 템플릿 사용을 참조하십시오.

  • 코드 검사 데이터를 수집하도록 테스트 구성. 코드 검사 데이터를 보고서에 표시하려면 팀 멤버가 테스트를 실행하여 해당 데이터를 수집해야 합니다.

    자세한 내용은 빌드 프로세스에서 테스트 실행을 참조하십시오.

  • 빌드를 정기적으로 실행. 일정한 간격마다 또는 각 체크 인 후에 빌드를 실행할 수 있습니다. 일정 트리거를 사용할 때 정기 빌드를 만들 수 있습니다.

    자세한 내용은 빌드 정의 만들기 또는 편집빌드 실행, 모니터링 및 관리을 참조하십시오.

    참고

    팀 멤버가 빌드 탐색기를 사용하여 빌드에 수동으로 등급을 매길 수도 있지만 이러한 등급은 빌드 품질 지표 보고서에 반영되지 않습니다.빌드 등급은 빌드 요약 보고서에 나타납니다.자세한 내용은 완료된 빌드의 품질 평가빌드 요약 보고서를 참조하십시오.

품질 문제 해결

다음 표에서는 품질 대시보드가 팀에서 수행할 수 있는 작업을 모니터링하고 식별하는 데 도움이 될 수 있는 특정 품질 문제에 대해 설명합니다.

문제

검토할 보고서

문제 해결 정보

빌드 실패

빌드 상태

야간 빌드는 소프트웨어 개발 프로젝트에 중요합니다. 빌드가 성공적으로 완료되지 않거나 BVT(빌드 확인 테스트)를 통과하지 않는 경우 팀은 문제를 즉시 해결해야 합니다.

테스트 실패

테스트 계획 진행률

코드 변동

코드 변동(code churn)과 실패한 테스트의 비율이 높으면 팀에서 소프트웨어에서 그렇게 자주 오류가 발생하는 이유를 확인할 수 있습니다. 원인에는 느슨한 개발 관행이나 초기 반복 주기에 너무 엄격한 테스트가 포함될 수 있습니다.

테스트가 통과하지만 버그 발견 비율이 높음

테스트 계획 진행률

버그 진행률

많은 버그가 발견된 동일한 기간에 많은 테스트가 성공하는 경우 팀에서는 다음과 같은 가능성을 조사할 수 있습니다.

  • 테스트가 현재 제품 단계에 맞게 충분히 엄격하지 않을 수 있습니다. 초기 반복에서는 간단한 테스트가 좋습니다. 하지만 제품이 완성되어 감에 따라 보다 광범위한 시나리오와 통합에 대한 테스트가 이루어져야 합니다.

  • 테스트 방법이 구식이거나 잘못된 기능을 테스트할 수 있습니다.

  • 다른 테스트 방법이 더 나은 결과를 제공할 수 있습니다.

  • 버그가 보고되지만 테스트 대상이 아닙니다. 보고되지만 테스트 사례에 연결되어 있지 않은 버그는 재발 테스트 대상이 아닙니다.

테스트가 구식임

테스트 계획 진행률

코드 검사

코드 변동

많은 테스트가 통과하고 상당한 양의 코드가 변경되고 코드 검사가 줄어드는 경우 팀에서 새 코드를 실행하는 테스트를 실행하지 않을 수 있습니다.

코드가 변경되는 것과 같은 속도로 테스트가 개발되지 않기 때문에 테스트 검사의 적합성이 점점 떨어질 수 있습니다.

팀에서 버그를 테스트하거나 닫거나 해결된 버그를 다시 활성화하고 있지 않음

버그 진행률

버그 진행률 보고서에서 해결된 버그가 급증하는 경우 개발자가 버그를 해결하고 있지만 테스터가 버그를 확인 및 닫지 않고 있습니다. 팀에서는 이 패턴이 나타난 이유를 확인해야 합니다.

테스트가 너무 적음

테스트 계획 진행률

코드 변동

팀에서 너무 적은 테스트를 실행하고 코드 변동(code churn)이 많으며 코드 검사가 예상보다 적은 경우 팀에서 테스트에 더 많은 리소스를 할당해야 할 수 있습니다. 또한 팀에서는 테스터가 팀의 다른 멤버와 함께 동일한 기능에 집중하도록 해야 합니다.

다시 활성화

버그 다시 활성화

팀에서 빠른 속도나 점점 증가하는 속도로 버그를 다시 활성화하는 경우 테스터가 개발자의 수정 내용을 자주 거부하는 것입니다. 팀에서는 거부된 수정 내용을 다시 작업하도록 상당한 리소스를 할당하는 것을 방지하기 위해 이러한 문제를 해결해야 합니다. 잠재적인 원인에는 잘못된 버그 보고, 부실한 테스트 작업실 관리, 과도하게 공격적인 심사 등이 있습니다.

부적절한 단위 테스트

코드 검사

코드 변동

코드 검사의 감소가 코드 변동(code churn)의 증가와 동시에 발생하는 경우 개발자가 코드를 검사하는 해당 단위 테스트 없이 코드를 체크 인하는 것일 수 있습니다.

대부분의 경우 팀에서 테스트 기반 개발이나 유사한 방법을 실행하는 경우 코드 검사는 100%에 근접합니다. 단위 테스트가 BVT로 다시 사용되는 경우 코드 검사가 해당 보고서에 표시됩니다.

품질 대시보드 사용자 지정

다음과 같은 방법으로 품질 대시보드를 사용자 지정할 수 있습니다.

  • 특정 제품 영역 또는 반복만 볼 수 있도록 각 Excel 보고서의 필터를 변경합니다.

  • 쿼리에서 발견한 작업 항목의 목록을 표시하는 사용자 지정 쿼리 웹 파트를 추가합니다. 예를 들어, 테스트 사례에 연결되지 않은 모든 활성 버그를 나열하는 쿼리를 추가할 수 있습니다. 이 쿼리는 보고되지만 테스트를 통해 발견되지 않으므로 재발 테스트 대상이 아닌 버그의 양을 보여 줍니다.

  • 버그 추세실패 분석과 같은 기존 Excel 보고서를 대시보드에 추가합니다.

Office Excel에서 보고서를 사용하여 작업하고 사용자 지정하는 방법에 대한 자세한 내용은 Microsoft 웹 사이트의 다음 페이지를 참조하십시오.