Azure Boards에서 소프트웨어 버그 정의, 캡처, 심사 및 관리

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

코드의 결함을 어떻게 추적하고 관리합니까? 고품질 소프트웨어 배포를 지원하기 위해 소프트웨어 문제 및 고객 피드백을 신속하게 해결하려면 어떻게 해야 할까요? 그리고 새로운 기능에 대해 어떻게 좋은 진전을 이루고 기술적인 문제를 해결할 수 있을까요?

최소한 소프트웨어 문제를 캡처하고, 우선 순위를 지정하고, 팀 구성원에게 할당하고, 진행 상황을 추적하는 방법이 필요합니다. 또한 Agile 사례에 맞는 방식으로 코드 결함을 관리하려고 합니다.

이러한 시나리오를 지원하기 위해 Azure Boards는 버그라는 코드 결함을 추적하는 특정 작업 항목 유형을 제공합니다. 버그 작업 항목은 다른 작업 항목 유형의 모든 표준 기능을 몇 가지 더 공유합니다. 표준 기능에 대한 개요는 사용자 스토리, 문제, 버그, 기능 및 서사시를 사용하여 작업 추적을 참조 하세요.

또한 버그는 다음과 같은 추가 기능을 제공합니다.

• 각 팀이 버그를 추적하는 방법을 선택하는 옵션
• 버그를 캡처하는 테스트 도구
• 빌드, 릴리스 및 테스트에 연결된 버그를 추적하기 위해 Azure DevOps 간에 기본 제공 통합

참고 항목

버그 작업 항목 유형은 기본 프로세스에서 사용할 수 없습니다. 기본 프로세스는 버그를 문제로 추적하며 Azure DevOps Services 또는 Azure DevOps Server 2019.1 이상 버전에서 새 프로젝트를 만들 때 사용할 수 있습니다.

필수 조건

• 프로젝트에 추가해야 합니다.
• 작업 항목을 보거나 수정하려면 이 노드에서 작업 항목 보기와 이 노드 권한의 작업 항목 편집이 허용으로 설정되어 있어야 합니다. 기본적으로 기여자 그룹에는 이 사용 권한 집합이 있습니다. 자세한 내용은 작업 추적에 대한 사용 권한 및 액세스 설정을 참조하세요.
• 작업 항목에 추가할 새 태그를 추가하려면 기본 액세스 이상의 권한이 있어야 하며 프로젝트 수준 새 태그 정의 만들기 권한이 허용으로 설정되어 있어야 합니다. 기본적으로 기여자 그룹에는 이 사용 권한 집합이 있습니다. 이해 관계자에 대한 사용 권한이 명시적으로 설정되어 있더라도 액세스 수준을 통해 금지되므로 새 태그를 추가할 수 있는 권한이 없습니다. 자세한 내용은 관련자 액세스 빠른 참조를 참조하세요.
• 읽기 권한자 그룹의 구성원인 모든 프로젝트 멤버는 작업 항목이 포함된 전자 메일을 보낼 수 있습니다.

팁

버그를 보고하려면 이 노드 권한에서 최소한 관련자 액세스 권한 및 편집 작업 항목이 버그를 추가하는 영역 경로 허용으로 설정되어야 합니다. 자세한 내용은 작업 추적에 대한 권한 및 액세스 설정을 참조 하세요.

버그 작업 항목 유형

다음 이미지는 스크럼 프로세스에 대한 버그 작업 항목 유형을 보여줍니다. Agile 및 CMMI 프로세스에 대한 버그 작업 항목 유형은 유사한 정보를 추적합니다. 요구 사항과 함께 제품 백로그에 표시되도록 설계되었으며 작업과 함께 Taskboard에 표시됩니다.

참고 항목

웹 포털에서 볼 수 있는 이미지는 이 문서에 표시된 이미지와 다를 수 있습니다. 이러한 차이는 웹앱에 대한 업데이트, 사용자 또는 관리자가 사용하도록 설정한 옵션 및 프로젝트를 만들 때 선택한 프로세스(Agile, Basic, Scrum 또는 CMMI)로 인해 발생합니다. 기본 프로세스는 Azure DevOps Server 2019 업데이트 1 이상 버전에서 사용할 수 있습니다.

버그와 관련된 필드

버그 작업 항목 유형은 일부 버그별 필드를 사용합니다. 초기 문제와 진행 중인 검색을 모두 캡처하려면 다음 표에 설명된 필드를 사용합니다. CMMI(Capability Maturity Model Integration) 프로세스에 대해 정의된 버그와 관련된 필드에 대한 자세한 내용은 버그, 문제 및 위험 필드 참조를 참조하세요. 다른 모든 필드에 대한 자세한 내용은 작업 항목 필드 인덱스입니다.

---

필드, 그룹 또는 탭

사용법

---

재현 단계
(friendly name=Repro Steps)

다른 팀 구성원이 코드 결함을 완전히 이해할 수 있도록 충분한 정보를 캡처하는 데 사용합니다. 버그 및 예상 동작을 찾거나 재현하기 위해 수행된 작업을 포함합니다.

---

시스템 정보
빌드에서 찾을 수 있습니다.

적용할 버그 및 테스트와 관련된 소프트웨어 및 시스템 구성에 대한 정보입니다. 테스트 도구를 통해 버그를 만들 때 빌드 필드의 시스템 정보 및 찾은 항목이 자동으로 채워집니다. 이러한 필드는 소프트웨어 환경에 대한 정보를 지정하고 버그가 발생한 위치를 빌드합니다. 자세한 내용은 다른 구성 테스트를 참조 하세요.

---

수용 기준

버그를 닫기 전에 충족할 조건을 제공합니다. 작업이 시작되기 전에 고객 승인 기준을 가능한 한 명확하게 설명합니다. 팀은 이 기준을 승인 테스트의 기초로 사용하고 항목이 만족스럽게 완료되었는지 여부를 평가해야 합니다.

---

빌드에 통합

버그를 수정하는 코드를 통합하는 빌드의 이름을 지정합니다. 버그를 해결할 때 이 필드를 지정해야 합니다. 온-프레미스 Azure DevOps의 경우 실행된 모든 빌드의 드롭다운 메뉴에 액세스하려면 빌드에서 찾은 항목 및 빌드의 통합에 대한 정의를 업데이트 FIELD 하여 전역 목록을 참조할 수 있습니다. 전역 목록은 실행되는 각 빌드로 자동으로 업데이트됩니다. 자세한 내용은 빌드 및 테스트 통합 필드를 기반으로 하는 쿼리를 참조 하세요.
빌드 번호를 정의하는 방법에 대한 자세한 내용은 빌드 번호 형식 옵션을 참조 하세요.

---

우선 순위¹

• 1: 제품이 배송되고 곧 해결되기 전에 작업 항목을 성공적으로 해결해야 합니다.
• 2: 제품이 배송되기 전에 작업 항목을 성공적으로 해결해야 하지만 즉시 해결할 필요는 없습니다.
• 3: 작업 항목의 해결은 리소스, 시간 및 위험에 따라 선택 사항입니다.

---

심각도¹

버그 또는 작업 항목이 프로젝트 또는 소프트웨어 시스템에 미치는 영향에 대한 주관적인 등급입니다. 예를 들어 사용자 인터페이스 내의 원격 링크(드문 이벤트)로 인해 애플리케이션 또는 웹 페이지가 충돌하는 경우 심각한 고객 환경인 경우 심각도 = 2 - 높음 및 우선 순위 = 3을 지정할 수 있습니다. 허용되는 값 및 제안된 지침은 다음과 같습니다.

• 1 - 중요: 수정해야 합니다. 하나 이상의 시스템 구성 요소 또는 전체 시스템이 종료되거나 광범위한 데이터 손상이 발생하는 결함입니다. 또한 필요한 결과를 얻기 위해 허용되는 대체 방법이 없습니다.
• 2 - 높음: 수정을 고려합니다. 하나 이상의 시스템 구성 요소 또는 전체 시스템이 종료되거나 광범위한 데이터 손상이 발생하는 결함입니다. 그러나 필요한 결과를 얻기 위해 허용되는 대체 방법이 있습니다.
• 3 - 보통: (기본값) 시스템이 잘못되거나 불완전하거나 일관되지 않은 결과를 생성하는 결함입니다.
• 4 - 낮음: 필요한 결과를 얻기 위해 허용되는 해결 방법이 있는 사소한 또는 미용 결함입니다.

---

배포

배포 컨트롤은 작업 항목이 포함된 릴리스의 링크 및 표시를 지원합니다. 컨트롤을 사용하려면 릴리스에 대한 설정을 사용하도록 설정해야 합니다. 자세한 내용은 이 문서의 뒷부분에 있는 릴리스에 작업 항목 연결을 참조하세요.

---

개발

개발 컨트롤은 개발 개체에 대한 링크 및 링크 표시를 지원합니다. 이러한 개체에는 Git 커밋 및 끌어오기 요청 또는 TFVC 변경 집합 및 버전이 지정된 항목이 포함됩니다. 작업 항목 또는 커밋, 끌어오기 요청 또는 기타 개발 개체의 링크를 정의할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 개발에 작업 항목 연결을 참조하세요.

---

참고:

¹ 메뉴 선택 또는 선택 목록을 변경하려면 작업 추적 환경 사용자 지정을 참조 하세요. 사용자 지정 방법은 프로젝트에서 사용하는 프로세스 모델에 따라 달라집니다.

팀이 버그를 추적하는 방법 선택

팀은 버그를 요구 사항 또는 작업으로 추적할 수 있습니다. 팀 선택을 지원하려면 다음 요소를 고려하세요.

• 팀의 크기입니다. 소규모 팀은 기본 버그를 요구 사항으로 추적하여 경량 공간을 얻을 수 있습니다.
• 작업을 추적하기 위한 조직의 요구 사항입니다. 팀이 시간을 추적해야 하는 경우 버그를 작업으로 추적하도록 선택합니다.
• 팀이 작업을 구성하는 방법. 팀이 제품 백로그를 사용하여 작업의 우선 순위를 지정하고 버그를 추가하는 경우 버그를 요구 사항으로 추적합니다.
• 계획 창, 속도 차트, 예측, 롤업 및 배달 계획과 같은 팀에서 사용하려는 도구입니다. 작업으로 버그를 추적하면 이러한 도구 중 몇 가지를 사용할 수 없습니다.

다음 표에서는 팀에서 버그를 추적해야 하는 세 가지 옵션을 요약합니다. 자세한 내용을 알아보고 팀에 대한 옵션을 설정하려면 백로그 및 보드에 버그 표시를 참조 하세요.

---

옵션

원하는 시기를 선택합니다.

---

요구 사항으로 버그 추적

• 요구 사항과 함께 버그 우선 순위 지정(스택 순위)
• 예측에 대한 버그 예상 작업
• Kanban 보드에서 버그 상태 업데이트
• 속도 차트 및 누적 흐름 다이어그램에 버그 포함
• 예측 도구를 사용하여 스프린트 계획을 지원할 수 있습니다.
• 버그를 계획 창으로 끌어서 놓아 스프린트에 버그를 할당할 수 있습니다.
• 배달 계획에서 버그를 볼 수 있습니다.

참고 항목

• 요구 사항 범주에 버그가 할당됩니다.

---

작업으로 버그 추적

• 작업과 유사한 버그에 대한 예상 작업
• 스프린트 작업 보드에서 버그 상태 업데이트
• 버그를 요구 사항에 자식 항목으로 연결
• 버그를 계획 창으로 끌어서 놓아 스프린트에 버그를 할당할 수 있습니다.

참고 항목

• 작업 범주에 버그가 할당됩니다.
• 사용자 스토리(Agile), 제품 백로그 항목(스크럼) 또는 CMMI(요구 사항)는 버그에 대한 자연스러운 부모 작업 항목 유형입니다.
• 배달 계획에 버그가 표시되지 않음

---

버그가 백로그 또는 보드에 표시되지 않음

• 쿼리를 사용하여 버그 관리

참고 항목

• 버그는 버그 범주와 연결되며 백로그 또는 보드에 표시되지 않습니다.
• 백로그, 보드, 스프린트 백로그, 작업표 또는 배달 계획에 버그가 표시되지 않습니다.
• 버그를 계획 창으로 끌어서 놓아 스프린트에 버그를 할당할 수 없습니다.

---

작업 항목 유형 사용자 지정

버그 및 기타 작업 항목 유형을 사용자 지정할 수 있습니다. 또는 소프트웨어 문제 또는 고객 피드백을 추적하는 사용자 지정 형식을 만듭니다. 모든 작업 항목 유형을 사용하여 다음 요소를 사용자 지정할 수 있습니다.

• 사용자 지정 필드 추가 또는 제거
• 작업 항목 양식 내에 사용자 지정 컨트롤 또는 사용자 지정 탭 추가
• 워크플로 상태 사용자 지정
• 조건부 규칙 추가
• 작업 항목이 표시되는 백로그 수준 선택

프로세스를 사용자 지정하기 전에 Azure Boards 구성 및 사용자 지정을 검토하는 것이 좋습니다.

특정 프로세스를 사용자 지정하려면 상속 프로세스 사용자 지정을 참조 하세요.

버그 추가 또는 캡처

여러 다른 Azure DevOps 도구에서 버그를 정의할 수 있습니다. 여기에는 백로그 및 보드 및 테스트 도구가 포함됩니다.

팁

기본적으로 제목 필드는 버그를 만들 때 필요한 유일한 필드입니다. Azure Boards를 사용하여 사용자 스토리 또는 제품 백로그 항목을 추가하는 것과 같은 방식으로 버그를 빠르게 추가할 수 있습니다. 필요한 필드를 만들려면 상태 변경에 따라 조건부 규칙을 추가합니다. 자세한 내용은 작업 항목 유형에 규칙 추가(상속 프로세스)를 참조하세요.

백로그 또는 보드에서 버그 추가

팀이 요구 사항으로 버그를 관리하도록 선택한 경우 제품 백로그 또는 Kanban 보드에서 버그를 정의할 수 있습니다. 자세한 내용은 제품 백로그 만들기 또는 Kanban 보드 사용 시작을 참조하세요.

• 제품 백로그에서 버그 추가

  

• 제품 백로그에서 버그 추가

  

팁

제품 백로그 또는 Kanban 보드에서 버그를 추가하면 버그에 팀에 대해 정의된 기본 영역 경로 및 반복 경로가 자동으로 할당됩니다. 자세한 내용은 백로그 및 보드에서 참조하는 팀 기본값을 참조 하세요.

스프린트 백로그 또는 작업 보드에서 버그 추가

팀이 작업으로 버그를 관리하도록 선택한 경우 Kanban 보드, 제품 백로그, 스프린트 백로그 또는 스프린트 태스크보드에서 버그를 정의할 수 있습니다. 제품 백로그 작업 항목에 자식으로 버그를 추가합니다.

• Kanban 보드에서 연결된 자식 버그 추가
  백로그 항목에 작업을 추가하는 것과 동일한 방식으로 버그를 추가합니다. 자세한 내용은 작업 또는 자식 항목을 검사 목록으로 추가를 참조하세요.

  

• 스프린트 백로그에서 연결된 자식 버그 추가
  스프린트 백로그에 작업을 추가하는 것과 동일한 방식으로 버그를 추가합니다. 자세한 내용은 백로그 항목에 작업 추가를 참조 하세요.

  

테스트 도구에서 버그 만들기

테스트하는 동안 버그를 추가하는 데 사용할 수 있는 두 가지 테스트 도구에는 웹 포털 Test Runner 및 테스트 및 피드백 확장이 포함됩니다.

• Test Runner: 수동 테스트를 실행할 때 버그를 만들도록 선택할 수 있습니다. 자세한 내용은 수동 테스트 실행을 참조 하세요.

  

• 테스트 및 피드백 확장: 예비 테스트를 실행할 때 버그를 만들거나 작업을 만들도록 선택할 수 있습니다. 자세한 내용은 테스트 및 피드백 확장을 사용한 예비 테스트를 참조 하세요.

버그 수명 주기 및 워크플로 상태

다른 모든 작업 항목 유형과 마찬가지로 버그 작업 항목 유형에는 잘 정의된 워크플로가 있습니다. 각 워크플로는 3개 이상의 상태와 이유로 구성됩니다. 이유는 항목이 한 상태에서 다른 상태로 전환된 이유를 지정합니다. 다음 이미지는 Agile, 스크럼 및 CMMI 프로세스에 대해 정의된 기본 버그 워크플로를 보여 줍니다.

애자일.	스크럼	Cmmi

스크럼 버그의 경우 상태를 커밋됨(활성과 유사)에서 완료로 변경 합니다. Agile 및 CMMI의 경우 먼저 버그를 해결하고 버그가 수정되었음을 나타내는 이유를 선택합니다. 일반적으로 버그를 만든 사람은 수정 사항을 확인하고 상태를 해결됨에서 닫힘으로 업데이트합니다. 버그가 해결되거나 닫힌 후 더 많은 작업이 발견되면 상태를 커밋됨 또는 활성으로 설정하여 다시 활성화할 수 있습니다.

참고 항목

Agile 프로세스 버그 작업 항목 유형에는 이전에 버그를 만든 사람에게 다시 할당한 규칙이 있었습니다. 이 규칙은 기본 시스템 프로세스에서 제거되었습니다. 규칙을 추가하여 이 자동화를 복원할 수 있습니다. 상속 프로세스의 경우 워크플로 상태에 규칙 적용, 상태 변경에 따라 다시 할당 자동화를 참조하세요.

수정 사항 확인

수정 사항을 확인하기 위해 개발자 또는 테스터는 버그를 재현하고 더 많은 예기치 않은 동작을 찾으려고 시도합니다. 필요한 경우 버그를 다시 활성화해야 합니다.

버그 수정을 확인할 때 버그가 수정되지 않았거나 해결에 동의하지 않을 수 있습니다. 이 경우 버그를 해결한 사용자와 논의하고, 합의에 도달하고, 버그를 다시 활성화할 수 있습니다. 버그를 다시 활성화하는 경우 버그 설명에 버그를 다시 활성화하는 이유를 포함합니다.

버그 닫기

버그가 수정된 것으로 확인되면 닫습니다. 그러나 다음 이유 중 하나로 버그를 닫을 수도 있습니다. 선택할 수 있는 이유는 프로젝트 프로세스 및 버그 전환 상태에 따라 달라집니다.

Agile 프로세스:

• 지연: 다음 제품 릴리스까지 버그 수정을 연기합니다.
• 수정됨: 버그가 수정된 것으로 확인되었습니다.
• 중복: 버그가 현재 정의된 다른 버그를 추적합니다. 각 버그를 링크 유형의 중복/중복 으로 연결하고 버그 중 하나를 닫을 수 있습니다.
• 디자인: 기능은 디자인된 대로 작동합니다.
• 재현할 수 없음: 테스트는 버그를 재현할 수 없음을 증명합니다.
• 사용되지 않음: 버그의 기능이 제품에 더 이상 없습니다.
• 백로그에 복사됨: 버그를 추적하기 위해 사용자 스토리가 열렸습니다.

스크럼 프로세스:

• 버그 없음: 버그가 버그가 아닌 것으로 확인되었습니다.
• 중복: 버그가 현재 정의된 다른 버그를 추적합니다. 각 버그를 링크 유형의 중복/중복 으로 연결하고 버그 중 하나를 닫을 수 있습니다.
• 백로그에서 제거됨: 버그가 버그가 아닌 것으로 확인되었습니다. 백로그에서 버그를 제거합니다.
• 작업 완료: 버그가 수정된 것으로 확인되었습니다.

CMMI 프로세스:

• 지연: 다음 제품 릴리스까지 버그 수정을 연기합니다.
• 중복: 버그가 현재 정의된 다른 버그를 추적합니다. 각 버그를 링크 유형의 중복/중복 으로 연결하고 버그 중 하나를 닫을 수 있습니다.
• 거부됨: 버그가 버그가 아닌 것으로 확인되었습니다.
• 확인됨: 버그가 수정된 것으로 확인되었습니다.

팁

버그가 닫히고 배포에서 수정 사항이 적극적으로 릴리스되면 회귀로 인해 다시 열지 않는 것이 좋습니다. 대신 새 버그를 열고 이전의 닫힌 버그에 대한 링크를 열어야 합니다.

버그가 닫힌 이유에 대한 향후 혼동을 피하기 위해 토론 필드에서 버그를 닫는 방법에 대한 자세한 내용을 설명하는 것이 좋습니다.

끌어오기 요청을 병합할 때 버그 닫기 자동화

팀에서 Git 리포지토리를 사용하는 경우 끌어오기 요청의 성공적인 병합 시 연결된 버그 및 기타 작업 항목의 상태를 닫도록 설정할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 끌어오기 요청에서 작업 항목 상태 설정을 참조하세요.

버그 나열 및 심사

대부분의 팀은 버그를 추적하기 위해 선택한 옵션에 관계없이 하나 이상의 버그 쿼리를 정의합니다. 쿼리를 사용하면 활성 버그, 할당되지 않은 버그, 부실 버그, 버그 추세 등을 나열할 수 있습니다. 그런 다음 팀 대시보드에 쿼리 및 쿼리 차트를 추가하여 버그 상태 및 진행률을 모니터링할 수 있습니다.

버그 쿼리

공유 쿼리를 열거나 쿼리 편집 기를 사용하여 다음 옵션과 같은 유용한 버그 쿼리를 만듭니다.

• 우선 순위별 활성 버그(State <> Done 또는 State <> Closed)
• 진행 중인 버그(State = Committed 또는 State = Active)
• 대상 릴리스에 대해 수정할 버그(Tags Contains RTM)
• 최근 버그 - 지난 3주 이내에 열린 버그(Created Date > @Today-21)

팀에 관심 있는 쿼리가 있으면 상태 또는 추세 차트를 만들 수 있습니다. 만든 차트를 대시보드에 추가할 수도 있습니다.

쿼리 결과의 심사 모드

코딩 및 테스트를 시작한 후에는 버그를 검토하고 순위를 매기기 위해 주기적인 심사 모임을 개최해야 합니다. 일반적으로 프로젝트 소유자는 버그 심사 모임을 실행합니다. 심사 회의에는 팀 리더, 비즈니스 분석가 및 특정 프로젝트 위험에 대해 이야기할 수 있는 기타 이해 관계자가 참석합니다.

프로젝트 소유자는 새 버그와 다시 연 버그에 대한 공유 쿼리를 정의하여 심사할 버그를 나열할 수 있습니다.

쿼리 결과 페이지에서 위쪽 및 아래쪽 화살표를 사용하여 버그 작업 항목 목록 내에서 빠르게 위아래로 이동할 수 있습니다. 각 버그를 검토할 때 할당하거나, 세부 정보를 추가하거나, 우선 순위를 설정할 수 있습니다.

스프린트에 버그 구성 및 할당

팀이 버그를 요구 사항으로 추적하는 경우 백로그에서 활성 버그 목록을 확인합니다. 필터 함수를 사용하면 버그에만 집중할 수 있습니다. 제품 백로그에서 다음 작업을 수행할 수도 있습니다.

• 백로그에서 버그 구성, 다른 항목에 대한 스택 순위(필터링을 사용하는 경우 스택 순위가 비활성화됨)
• 계획 창을 사용하여 백로그에서 스프린트에 버그 할당
• 매핑 창을 사용하여 기능 또는 기타 포트폴리오 백로그 항목에 대한 부모 버그
• 포트폴리오 백로그 항목에 대한 작업 롤업을 봅니다.

팀에서 버그를 작업으로 추적하는 경우 관리되는 쿼리를 사용하여 버그를 나열하고 심사합니다. 그런 다음 각 스프린트 내에서 스프린트 백로그 또는 작업 보드에서 스프린트에 할당된 버그가 표시됩니다.

작업 보드 항목 및 쿼리 목록 항목

스프린트 태스크보드에 표시되는 항목이 해당 스프린트 백로그에서 만든 쿼리 목록과 다를 수 있는 이유를 알아차리고 궁금할 수 있습니다.

작업 또는 버그를 반복에 할당할 수 있지만 부모 백로그 항목에 연결하지는 않습니다. 이러한 항목은 만든 쿼리에 표시되지만 작업 보드 자체에 표시되지 않을 수 있습니다. 시스템은 쿼리를 실행한 다음 작업 보드 항목을 표시하기 전에 몇 가지 백그라운드 프로세스를 적용합니다.

이러한 이유로 인해 작업 범주에 속한 작업 항목이 스프린트 백로그 또는 작업 보드에 표시되지 않을 수 있습니다.

• 작업 또는 버그가 부모 백로그 항목에 연결되지 않았습니다. 스프린트로 설정된 반복 경로가 있는 부모 제품 백로그 항목(스크럼), 사용자 스토리(Agile) 또는 요구 사항(CMMI)에 연결한 버그 및 작업만 스프린트 백로그 페이지에 표시됩니다.
• 작업 또는 버그는 다른 작업 또는 버그의 부모이거나 사용자 스토리가 다른 사용자 스토리의 부모입니다. 작업, 버그 또는 사용자 스토리 의 계층 구조를 만든 경우 계층의 맨 아래에 있는 자식 수준 작업 또는 자식 수준 스토리만 표시됩니다.
• 작업 또는 버그의 연결된 부모는 다른 팀에 대해 정의된 백로그 항목에 해당합니다. 또는 태스크 또는 버그의 부모 백로그 항목의 영역 경로가 작업 또는 버그의 영역 경로와 다릅니다.

버그에 연결된 인라인 테스트 만들기

팀에서 버그를 요구 사항으로 추적하는 경우 Kanban 보드를 사용하여 테스트를 추가하여 버그 수정을 확인할 수 있습니다.

버그 상태 업데이트

보드의 새 열에 버그를 끌어서 놓아 버그 상태 업데이트할 수 있습니다.

• 팀이 버그를 요구 사항으로 추적하는 경우 다음 이미지와 같이 Kanban 보드를 사용합니다. 자세한 내용은 Kanban 보드 시작을 참조하세요.

  

• 팀에서 버그를 작업으로 추적하는 경우 작업 보드를 사용합니다. 자세한 내용은 작업 보드 업데이트 및 모니터링을 참조하세요.

  

중간 상태를 추적하도록 보드 사용자 지정

중간 열을 추가하여 보드의 버그 상태 추적할 수 있습니다. 보드 열의 상태 따라 필터링하는 쿼리를 정의할 수도 있습니다. 자세한 내용은 다음 문서를 참조하세요.

• Kanban 보드에 열 추가
• 스프린트 태스크보드 사용자 지정
• Kanban 보드 변경 쿼리

워크플로 상태에 따라 버그 재할당 자동화

선택 작업을 자동화하려면 버그 작업 항목 유형에 사용자 지정 규칙을 추가합니다. 예를 들어 다음 이미지와 같이 규칙을 추가합니다. 이 규칙은 버그가 해결되면 버그를 연 사람에게 버그를 다시 할당하도록 지정합니다. 일반적으로 해당 사용자는 버그가 수정되어 있는지 확인하고 버그를 닫습니다. 자세한 내용은 워크플로 상태에 규칙 적용(상속 프로세스)을 참조하세요.

끌어오기 요청에서 작업 항목 상태 설정

끌어오기 요청을 만들 때 설명에서 연결된 작업 항목의 상태 값을 설정할 수 있습니다. 구문을 따릅니다. {state value}: #ID. 끌어오기 요청을 병합하면 시스템에서 설명을 읽고 작업 항목 상태를 업데이트합니다. 다음 예제에서는 작업 항목 #300 및 #301을 해결됨으로, #323 및 #324를 Closed로 설정합니다.

Azure DevOps 간 통합

통합을 지원하기 위해 Azure DevOps에서 사용하는 방법 중 하나는 개체를 다른 개체에 연결하는 것입니다. 작업 항목을 작업 항목에 연결하는 것 외에도 작업 항목을 다른 개체에 연결할 수도 있습니다. 다음 이미지와 같이 빌드, 릴리스, 분기, 커밋 및 끌어오기 요청과 같은 개체에 연결합니다.

작업 항목 또는 빌드 및 릴리스 개체에서 링크를 추가할 수 있습니다.

개발 작업에 작업 항목 연결

개발 컨트롤은 빌드, Git 커밋 및 끌어오기 요청에 대한 링크 연결 및 표시를 지원합니다. 또는 TFVC 리포지토리를 사용하는 경우 변경 집합 및 버전이 지정된 항목에 대한 링크를 지원합니다. 링크를 선택하면 새 브라우저 탭에서 해당 항목이 열립니다. 자세한 내용은 작업 항목에서 Git 개발 드라이브를 참조 하세요.

작업 항목을 릴리스에 연결

배포 컨트롤은 작업 항목이 포함된 릴리스의 링크 및 표시를 지원합니다. 예를 들어 다음 이미지는 현재 작업 항목에 대한 링크가 포함된 여러 릴리스를 보여 줍니다. 각 릴리스를 확장하여 각 단계에 대한 세부 정보를 볼 수 있습니다. 각 릴리스 및 스테이지에 대한 링크를 선택하여 해당 릴리스 또는 스테이지를 열 수 있습니다. 자세한 내용은 배포에 작업 항목 연결을 참조 하세요.

파이프라인 실행에 작업 항목 연결

파이프라인은 종종 Git 리포지토리에 새 커밋이 발생할 때 자동으로 실행되도록 정의됩니다. 커밋 파이프라인과 연결된 작업 항목은 파이프라인 설정을 사용자 지정하는 경우 파이프라인 실행의 일부로 표시됩니다. 자세한 내용은 파이프라인 사용자 지정을 참조하세요.

빌드 실패 시 작업 항목 만들기 또는 편집

YAML이 아닌 클래식 파이프라인을 사용하는 경우 빌드 실패에 대한 작업 항목을 만들 수 있습니다. 자세한 내용은 빌드 옵션, 실패 시 작업 항목 만들기를 참조하세요.

버그 상태, 할당 및 추세 모니터링

차트를 작성하고 대시보드에 추가할 수 있는 쿼리를 사용하여 버그 상태, 할당 및 추세를 추적할 수 있습니다. 예를 들어 다음은 시간에 따른 상태 및 활성 버그별 우선 순위별 활성 버그 추세를 보여 주는 두 가지 예입니다.

쿼리, 차트 및 대시보드에 대해 자세히 알아보려면 관리되는 쿼리 및 차트 및 대시보드를 참조하세요.

분석 뷰 및 분석 서비스를 사용하여 버그 보고서 만들기

Analytics 서비스는 SQL Server Reporting Services를 기반으로 이전 플랫폼을 대체하는 Azure DevOps의 보고 플랫폼입니다.

분석 보기는 작업 항목을 보기 위해 미리 빌드된 필터를 제공합니다. 버그 보고에는 4개의 분석 보기가 지원됩니다. 이러한 보기를 정의된 대로 사용하거나 추가로 편집하여 필터링된 사용자 지정 보기를 만들 수 있습니다.

• 버그 - 월별 모든 기록
• 버그 - 지난 26주
• 버그 - 지난 30일
• 버그 - 오늘

분석 뷰 사용에 대한 자세한 내용은 분석 보기란? 및 사용자 지정 분석 보기를 기반으로 Power BI에서 활성 버그 보고서 만들기를 참조하세요.

Power BI를 사용하여 쿼리에서 얻을 수 있는 것보다 더 복잡한 보고서를 만들 수 있습니다. 자세한 내용은 Power BI Data 커넥트or를 사용하여 커넥트 참조하세요.

Marketplace 확장

여러 버그 관련 Marketplace 확장이 있습니다. Azure DevOps용 Marketplace를 참조하세요.

확장에 대한 자세한 내용은 Microsoft에서 개발한 Azure Boards 확장을 참조 하세요.

다음 단계

템플릿을 사용하여 작업 항목 추가 및 업데이트

관련된 문서

• 작업 항목 이동, 유형 변경 또는 삭제
• 작업 항목 복사 또는 복제

제품 백로그 및 Kanban 보드

• 백로그, 포트폴리오 및 Agile 프로젝트 관리
• 백로그 만들기
• 기능 및 서사시 정의
• 백로그를 구성하고 자식 작업 항목을 부모에 매핑
• 백로그, 보드, 쿼리 및 계획을 대화형으로 필터링
• 제품 백로그 예측

Kanban 보드

• 보드 및 칸반 정보
• Kanban 보드 빠른 시작
• 카드 순서 다시 지정
• 작업 또는 자식 항목을 검사 목록으로 추가

스프린트 백로그 및 태스크보드

• 스크럼 및 스프린트 작업 모범 사례
• 스프린트에 백로그 항목 할당
• 작업 추가
• 작업표 업데이트

Azure DevOps 내에서 통합

• 사용자 스토리, 문제, 버그 및 기타 작업 항목 연결
• 작업 항목 또는 끌어오기 요청 수행
• 실행 또는 빌드 번호 구성

산업 리소스

• 헨릭 크니버그에 의해 좋은 나쁜 기술 부채 (그리고 TDD가 도움이되는 방법)
• 스벤 요한과 에베르하르트 울프가 게시한 기술 부채 관리