jira bug tracking tool tutorial
JIRA 버그 추적 : JIRA의 결함 수명주기
Jira 다운로드 및 설치 이전 튜토리얼에서 자세히 설명했습니다. 테스트 팀은 항상 결함 관리를 위해 JIRA를 선택하는 것에 대해 걱정합니다.
의심의 여지가 있습니다. JIRA 버그 추적 도구는 IT 비즈니스에 적용 가능하지만 일반적인 티켓팅 시스템이라는 사실에서 기인합니다.
IT 프로젝트의 경우에도 개발 팀에서 JIRA의 인기는 테스터 및 QA 팀을 불편하게 만듭니다. 편안함이나 불편 함에도 불구하고 테스트 팀은 대부분의 회사에서 JIRA 버그 추적 도구를 사용할 수밖에 없습니다. 우리의 JIRA 교육에 대한 완전한 가이드 도구에 대한 뛰어난 지식을 제공합니다.
=> 전체 JIRA 튜토리얼 시리즈를 보려면 여기를 클릭하십시오.
왜? 간단한 논리 기업은 여러 도구에 투자하기를 원하지 않습니다. 도구 활용도를 극대화하고 너무 많은 라이센스를 구입하는 데 열중하지 않는 것이 비즈니스에 적합합니다.
따라서 개발 팀이 Atlassian JIRA 버그 추적 도구를 사용하여 요구 사항, 개선 사항, 작업 또는 사용자 스토리를 추적하면 테스트 팀이이를 버그 추적에 사용해야합니다.
하지만 진정해 . JIRA의 결함 관리는 다른 도구와 마찬가지로 우수합니다. . 실제로 어떤 상황에서는 더 나을 수도 있습니다.
이 튜토리얼은 스크린 샷과 모든 것을 통해 버그 추적에 대한 JIRA의 적용 가능성을 보여줄 튜토리얼입니다.
학습 내용 :
JIRA 버그 추적 도구의 최고의 기능
여기 있습니다.
# 1) JIRA는 내부의 모든 작업을 이슈로 취급합니다.
따라서 JIRA에서 결함을 생성하는 것은 ' 곤충 ”.
# 2) 결함보고에는 모든 문제에 대해 기록 된 다음 정보가 필요합니다.
- 결함 ID
- 결함 제목
- 결함 설명 (재현 단계)
- 환경 정보
- 스크린 샷 (첨부)
- 심각성
- 누군가에게 할당
- 상태- 버그 수명주기의 모든 상태
결함을 효과적으로 생성 할 수 있도록 모든 옵션을 사용할 수 있습니다.
아래 빨간색으로 강조 표시된 필드를 참고하십시오.
여기에 표시되지 않는 두 필드는 다음과 같습니다.
- 결함 ID
- 상태
이 두 필드는 JIRA에 의해 자동 생성됩니다. 모든 이슈에는 JIRA가 할당 한 고유 ID가 있습니다. 모든 이슈의 상태는 버그를 생성 할 때 기본적으로 JIRA에서“To-Do”또는“New”입니다.
따라서, 결함보고를위한 모든 공통 기능은 JIRA에서도 사용할 수 있습니다. 실제로 레이블, 결함 연결, 노력 추정과 같은 더 많은 옵션을 사용할 수 있습니다.
# 3) 결함 수명주기 :
모든 버그 수명주기 상태 Bugzilla (또는 다른 인기있는 버그 추적기 )도 여기에서 수행 할 수 있습니다.
이것은 JIRA 관리자가 약간의 사용자 정의가 필요하지만 쉽게 할 수 있습니다. 이러한 경우 사용자 정의에 신경 쓰지 않고 기본 설정도 잘못 할 수 없습니다.
# 4) 개발자 팀과의 의견 및 협업
모든 이슈, 업데이트, 사람 할당, 개발자 팀으로부터받은 코멘트 – 모든 것은 활동 로그 아래 JIRA에서 추적됩니다.
이를 통해 개발 팀과 더 나은 가시성과 협업이 가능합니다.
# 5) 추적 성을 가능하게하기 위해 결함을 요구 사항에 연결
JIRA 이슈 필드의 링크 옵션을 사용하면 특정 이슈를 다른 이슈에 연결할 수 있습니다. 결함 2가 결함 1의 복제본이면 해당 관계를 설정할 수 있다고 가정 해 보겠습니다.
마찬가지로 결함이 요구 사항을 차단하거나 요구 사항과 관련된 경우-이 측면을 JIRA에서 볼 수 있습니다.
결과 링크는 아래와 같이 문제 세부 정보 페이지에 나타납니다.
관계 유형은 자명하며 단순하고 일상적인 언어 단어 (관련, 원인 등)를 사용하면 JIRA 사용자가이 권한을 매우 쉽고 직관적으로 사용할 수 있습니다.
# 6) CSV 파일에서 결함을 가져올 수 있습니다.
이것은 한 번에 JIRA에서 이슈의 대량 생성을 돕습니다. 또한 팀이 신입이고 문제를 도구에 직접 작성하지 않으려는 경우 Excel 시트에 결함을보고하도록 할 수 있습니다. 검토되고 유효한 것으로 확인되면이 기능을 사용하여 한 번에 도구로 가져올 수 있습니다.
어떤 방식으로 사용하든 이것은 큰 장점입니다.
# 7) 결함은 Word, XML 및 인쇄 가능한 형식으로 내보낼 수 있습니다.
이는 결함 데이터의 더 나은 이식성을 지원하며 특히 JIRA가 아닌 사용자와 결함 데이터를 공유하려는 경우 유용합니다.
# 8) 포괄적 인 문제 보고서 :
또한 보고서가 필요한 경우 ' 프로젝트 – 보고서 ”및 아래와 같이 모든 종류의 보고서를 생성합니다.
JIRA의 분석을 한 단어로 검토해야한다면 환상적입니다.
JIRA 고급 / 고급 사용자는 고급 검색 필터를 만들어 더 깊은 통찰력을 생성 할 수도 있습니다.
예를 들면 여러 프로젝트 (BM 및 AB)에서 할당 된 모든 결함을 확인하려면 아래와 같은 JQL 쿼리를 사용할 수 있습니다.
따라서 대체로 JIRA의 버그 추적 / 결함 관리는 전용 버그 추적기보다 우수하지는 않지만 매우 유사합니다. 다음에 작업해야 할 때 걱정하지 마세요. 당신은 좋은 손에 있습니다.
테스트에 대한 JIRA의 적용 가능성 – 대체 딜레마
이것이 동전의 한면이지만 사람들이 QA 또는 테스트에 대한 JIRA의 적용 가능성을 보는 방식에는 확실히 다른 차원이 있습니다.
QA 그룹에 'JIRA 란 무엇입니까?'라고 물으면 많은 사람들이 JIRA가 결함 추적 도구라고 대답 할 것입니다. 나는 많은 선임 QA 전문가들로부터 이것을 들었습니다. 이는 결함 관리 / 추적이 JIRA를 사용한 전부라는 사실 때문일 수 있습니다.
그러나 더 많은 것이 있습니다. 제대로 사용하면 민첩한 기능을 갖춘 핵심 JIRA가 높은 수준의 프로젝트 관리를위한 원 스톱 상점이 될 수 있습니다.
SCRUM 및 KANBAN 보드를 통한 요구 사항 추적 및 진행, 버그 추적, 추정, 스프린트 추적,보고 및 협업을 실제로 지원할 수 있습니다.
한 가지 도구를 사용하고있을 수 있지만 다음에 도구를 이해하고 더 잘 사용하는 데 도움이되는 몇 가지 사항과 도구에 대해 알아보십시오.
따라서 다음 단계로 JIRA의 몇 가지 다른 멋진 기능 (버그 추적과 직접 관련이 없을 수 있음)을 탐색 할 수 있습니다.
- 맞춤형 대시 보드
- 테스트 관리 추가 기능
- 투표 및 이슈보기
- 시간 추적
- 애자일 프로젝트 및 스크럼 보드
- Confluence / Documentation 지원 통합 등
Jira 이슈 및 다양한 필드 생성
Jira 문제 : 다양한 유형의 Jira 문제
Jira는 이슈를 생성 / 기록하는 매우 간단한 방법을 제공합니다.
버그를 신고 할 수있을뿐만 아니라 다른 종류의 '티켓'또는 '요청'도 가능합니다. 일반적인 요청 관리 응용 프로그램에 가깝습니다.
이 튜토리얼에서는 Jira의 이슈 유형, 이슈 생성, '이슈 생성'페이지의 다양한 필드 및 이해하기 쉽도록 그림 표현과 함께 간단한 용어로 세부 사항에 대해 자세히 설명합니다.
Jira 문제
조직마다 적합성 / 요구 사항에 따라 다른 유형의 문제가있을 수 있습니다. Jira 관리자는이 필드를 효율적으로 사용자 지정할 수 있습니다.
문제는 다양한 유형이 될 수 있으며 아래에 문제 유형의 설명 / 의미가 나와 있습니다.
- 곤충: 이것은 응용 프로그램에서 발견 된 결함 또는 편차입니다.
- 개선 요청 : 변경 요청 (CR)이라고도합니다. 이 유형은 기존 기능의 변경 사항이나 완전히 새로운 기능을 나타내는 데 사용됩니다.
- 직무: 이것은 구성 또는 분석 문제에 가깝습니다. 예를 들어 , 적절한 구성을 설정하는 것은 작업이 될 수 있습니다.
- 질문: 문제는 응용 프로그램에서 일부 기능을 사용하는 방법에 대해 질문하는 것처럼 간단 할 수 있습니다. 이 유형은 최종 고객이 더 자주 사용합니다.
- 서사시: 이것은 일반적으로 몇 가지 작은 문제로 이상적으로 나누어지는 큰 문제입니다. 애자일 환경에서 주요 서사시 문제를 완료하려면 여러 번의 스프린트가 필요할 수 있습니다.
- 재무 개체 : 종종 프로젝트 / 제품 관리는 이러한 유형의 문제를 사용하여 재정을 추적합니다.
- 이야기: 기능에 대한 전체 사용자 스토리가 문제 유형일 수 있습니다.
- 테스트 케이스 : 문제는 테스트 케이스가 될 수 있습니다. 이 유형의 문제는 Jira가 Zypher와 같은 플러그인과 통합되면 사용할 수 있습니다.
이슈 생성
사용자가 Jira 및 원하는 프로젝트에 로그인했다고 가정합니다.
1 단계:
‘+’(‘생성’) 도구 모음 버튼을 클릭합니다.
그러면 아래 이미지와 같이 화면 / 페이지가 표시됩니다.
이 페이지에서 프로젝트 및 발행 / 요청 유형을 선택하고 '다음'버튼을 클릭합니다.
그러면 다음 이미지와 같이 '문제 생성'페이지가 열립니다.
2 단계:
'문제 만들기'페이지에서 가능한 한 많은 필수 세부 정보 및 기타 데이터를 입력합니다.
3 단계 :
'만들기'버튼을 클릭합니다. 이렇게하면 고유 한 문제 ID가 생성됩니다. ID는 숫자로 연결된 프로젝트 식별자로 구성됩니다.
위의 예에서 선택한 프로젝트는‘TestProject’이므로 ID는‘TESTPROJ1234’와 같을 수 있습니다.
- 이슈가 생성되면 이슈 ID를 사용하여 검색 할 수 있습니다.
'이슈 생성'페이지의 필드 설명
(문제 작성 페이지 이미지는 가독성을 높이기 위해 세 부분으로 나뉩니다)
노트 :Jira 관리자 및 / 또는 개발자는 조직의 필요에 따라 사용자 지정 필드를 추가 / 제거 할 수 있습니다.
# 1) 요약 :
이것은 또한 더 자주 이슈의 제목으로 불리며 Jira 이슈에서 매우 중요한 분야입니다.
제목 자체를보고 문제를 이해할 수 있도록 제목은 가능한 한 독특하고 정확해야합니다. 이를 통해 버그 검토위원회 및 / 또는 제품 소유자가 문제를 자세히 살펴 보지 않고도 우선 순위를 지정하고 문제를 할당 할 수 있습니다.
# 2) 구성 요소 :
'버그'문제 유형의 경우 결함이 감지 된 애플리케이션의 모듈 또는 영역의 이름입니다.
CR의 경우 변경이 필요한 영역 일 수 있습니다. 이것은 일반적으로 응용 프로그램에 존재하는 다른 모듈 / 구성 요소로 구성된 드롭 다운입니다. 프로젝트 담당자는 관리자로부터이를 채워야합니다.
# 3) 설명 :
일반적으로 문제 유형이 버그 인 경우 문제를 재현하는 단계를 포함해야합니다.
향상 요청의 경우 일반적으로 애자일 용어로 이야기라고하는 새로운 요구 사항에 대해 자세히 설명해야합니다. 이상적으로이 필드는 문제 워크 플로 과정에서 정기적으로 업데이트되어야합니다.
# 4) 버전 수정 :
문제 / 향상 요청이 전달 될 버전의 이름입니다. 이 값은 일반적으로 민첩한 스크럼 환경에서 스크럼 마스터와 협력하여 제품 소유자가 채 웁니다.
# 5) 우선 순위 :
이 필드는 문제의 중요도를 나타냅니다.
이는 애플리케이션 테스트가 테스트 단계에서 진행될 수 없음을 의미합니다. 응용 프로그램의 충돌이 이상적입니다 예 'Show Stopper'(중요) 문제의.
버그 검토위원회와 제품 소유자는 문제의 우선 순위를 변경할 수있는 모든 권리를 갖습니다. 이 필드는 '낮음', '중간'( '주요'), '중요', '비공개'등과 같은 값이있는 드롭 다운 목록입니다.
# 6) 라벨 :
이 필드는 문제를 분류하는 데 도움이되는 텍스트와 함께 입력됩니다.
# 7) 환경 :
이것은 선택적 필드이며 여기에 테스트 환경이 지정됩니다.
# 8) 첨부 :
생성되는 문제에 대한 지원 이미지. 사용자는 간단히 이미지를 끌어서 놓거나 복사하여 붙여 넣을 수 있습니다.
# 9) 버전 / 초에 영향 :
'버그'유형의 문제의 경우 여기에 제품 버전을 입력해야합니다.
예를 들어 5.6, 5.7 등
# 10) 연결된 문제 :
이 드롭 다운에서 적절한 값을 선택하여 다른 관련 문제를 새 문제에 연결할 수 있습니다.
예를 들어 문제가 다른 문제의 수정으로 인해 발생한 경우 드롭 다운에서 선택할 값은 'Introduced By'가 될 수 있습니다. 이 필드는 일부 수정 또는 개선으로 인해 새로운 결함이 발생하는 경우 매우 중요합니다.
=> 문제 : '연결된 이슈'에서 적절한 값을 선택하면 여기에 관련 이슈 ID가 언급됩니다.
# 11) 양수인 :
문제에 대해 작업 할 사용자의 이름입니다.
예를 들어 버그의 경우 문제를 해결할 개발자의 이름이됩니다. 이 필드는 일반적으로 제품 소유자 또는 스크럼 마스터가 채 웁니다. 다시 문제를 할당하는 사람은 조직마다 다를 수 있습니다.
=> 'Assign to me'( 'Assignee'필드 오른쪽 모서리에 있음)를 클릭하면 로그인 한 사용자에게 문제가 할당됩니다.
# 12) 에픽 링크 :
서사시 관련 링크를 선택하십시오.
# 13) 스프린트 :
여기서 스프린트의 이름이 선택되어 문제가 언제 처리 될 것인지를 나타냅니다. 제품 소유자가 결정한 미래의 스프린트가 될 수 있습니다.
# 14) 팀 :
애자일 환경에는 여러 팀이있을 수 있습니다. 문제는 팀 중 하나에 할당됩니다. 이 할당은 일반적으로 제품 소유자 또는 제품 소유자와 협력하여 스크럼 마스터가 수행합니다.
# 15) 시작 시점의 추정 :
이 필드는 문제를 해결하는 데 필요한 시간을 나타냅니다.
더 자주 '추측'이라고합니다. 이것은 또한 필요한 테스트 노력으로 구성됩니다. 시간 / 일 / 주 또는 스토리 포인트로 언급 될 수 있습니다. 스프린트 계획 중 애자일 환경에서 전체 팀은 공통된 추측에 도달합니다.
# 16) 기자 :
이 필드는 로그인 한 사용자의 이름으로 Jira에 의해 자동으로 채워집니다.
노트 : 아래와 같이 다른 사용자 정의 필드가있을 수 있습니다 (위 이미지에는 표시되지 않음).
(i) 환경 유형 :
테스트 또는 프로덕션 환경에서 결함이 발견되었는지 여부를 나타냅니다.
이 필드 값은 조직마다 다를 수 있습니다. Jira가 최종 고객이 아닌 조직 내부에서만 문제를 생성하는 데 사용되는 경우이 필드는 전혀 존재하지 않을 수 있습니다.
(ii) 재현 가능 :
결함을 재현 할 수 있습니까? 이 필드는 버그 이외의 문제 유형에는 사용할 수 없습니다.
(iii) 고객 :
이 필드는 문제를 제기 한 최종 고객의 이름입니다. Jira가 내부 문제 처리에만 사용되는 일부 조직에서는이 필드가 없을 수 있습니다.
노트 : 위에서 설명한 모든 필드는 일반적으로 기본 탭인 '문제 만들기'페이지의 '필드'탭에 속합니다. 이 페이지는 다음 자습서에서 다룰 '문서'등과 같은 더 많은 탭을 갖도록 사용자 정의 할 수 있습니다.
Jira는 다양한 유형의 문제를 쉽고 효율적으로 관리 할 수있는 효과적인 방법을 제공합니다.
오늘날 가능한 많은 사용자 정의로 Jira가 가장 인기있는 선택이되었습니다.
JIRA에서 문제를 처리하는 방법
JIRA 이슈 작업 – JIRA에서 결함을 기록하는 방법
로그인 한 사용자가 관리자가 아니고 테스트 프로젝트가 구성 요소 (모듈 1 및 모듈 2, 버전 – 버전 1 및 버전 2)가있는 'STH 용 테스트'라고 가정하고 문제 생성으로 넘어가겠습니다. 키 – TFS가 이미 있습니다. 만들어진.
JIRA 이슈 생성
문제는 JIRA의 핵심을 형성하므로 문제를 생성하기 위해 메뉴 모음에 바로 옵션이 있습니다.
'이슈 생성'버튼을 클릭합니다. 또는 JIRA 페이지에서 'c'를 입력하면 다음과 같은 'Create Issue'대화 상자가 열립니다.
이 페이지의 모든 필드는 자명합니다. 아래에서 가장 중요한 것을 논의 할 것입니다.
계획 : 모든 이슈는 프로젝트에 속합니다. 드롭 다운을 클릭하고이 이슈가 속할 프로젝트를 선택하여 동일하게 선택할 수 있습니다.
불화를위한 최고의 무료 음성 체인저
문제 유형 :이 필드는 JIRA를 통해 생성 및 추적 할 수있는 모든 유형의 이슈를 표시합니다. 이 목록에서 다음 옵션을 사용할 수 있습니다 (이 목록은 관리자가 설정 한 설정에 따라 다를 수 있음).
항목 버그, 새로운 기능, 작업, 개선은 이름이 의미하는 것과 정확히 같습니다. 에픽과 스토리는 애자일 프로젝트와 더 관련이 있습니다. 스토리는 애자일에서 처음부터 끝까지 추적해야하는 요구 사항입니다. 에픽은 이야기의 그룹입니다.
필요에 따라 문제 유형을 선택합니다. 나는 '버그'로 갈 것입니다.
요약 : 여기에 버그 제목을 지정합니다. 이 필드를 올바르게 사용하면 많은 중요한 정보를 성공적으로 전송할 수 있습니다. 여기서 주목해야 할 몇 가지 측면 :
버그 / 결함은 본질적으로 옳지 않은 것입니다. 버그 제목에 접근하는 올바른 방법은 '무엇이 잘못되었는지'를 간결하게 정의하는 것입니다.
예 잘못된 제목 / 요약의 경우 '화면의 내용을 지우는 옵션이 있어야합니다'입니다. 이 글을 읽었을 때 나의 초기 반응은 다음과 같을 것입니다.“좋아요, 있어야합니다.하지만 여기서 문제는 무엇입니까? 옵션이 전혀 없습니까? 아니면 옵션이 있고 내용을 지우지 않습니까?”
또한이 버그를 열고 자세히 살펴보면이 질문에 대한 답을 찾을 수 있다는 데 동의합니다.
그러나 여기서 강조하는 것은이 '요약'필드를 가장 효율적인 방식으로 사용하는 것입니다. 따라서 매우 적절한 요약 / 제목은 '홈 로그인 페이지의 내용을 지우는 옵션은 클릭 할 때 필드를 지우지 않습니다.'입니다.
이 필드가 제공하는 제한된 공간에서 모호함없이 정확한 문제를 전달하는 방식으로 제목을 작성하십시오.
우선 순위 :이 필드는 다음 값 중 하나를 사용할 수 있습니다.
버그에 적합한 옵션을 선택하십시오.
와 놓다 티 :이 목록은 프로젝트의 구성 요소를 표시합니다. 적절하게 선택하십시오.
영향을받는 버전 및 수정 버전: 이 두 필드는 프로젝트에 사용 가능한 버전을 표시합니다. 특정 버전에서 발생한 특정 문제를 동일한 버전에서 수정할 필요는 없습니다. 이러한 경우 영향을받는 버전을 현재 버전으로 선택하고 수정 버전을 다음 버전으로 선택할 수 있습니다.
또한 이러한 필드는 여러 값을 가질 수 있습니다. 특정 문제가 다음과 같이 버전 1과 버전 2 모두에 영향을 미치도록 설정할 수 있습니다.
양수인 :이 문제를 더 전달받을 사람의 이름을 입력 할 수 있습니다. 자신에게 이슈를 할당 할 수도 있습니다.
기술 : 문제에 대해 원하는만큼 많은 정보를 입력하는 데 도움이되는 선택적 텍스트 필드입니다. 의 경우 곤충 ,이 필드를 사용하여 결함을 재현하는 단계에 대한 자세한 정보를 제공하는 것이 일반적입니다.
모든 정보를 제공하는 것이 가장 중요합니다.
“주와 도시라는 두 개의 필드가 있습니다. 종속 필드가 있습니다. 드롭 다운에서 State를 선택하면 City 필드에 내가 선택한주의 각 도시가 표시되어야합니다.
내가 '선택한 일부 주에 대해 도시가 비어 있습니다'라는 버그를 제기 한 경우. 설명 필드에서이 결함에 대해 자세히 설명 할 수 있습니다.
불충분 한 설명의 예는 다음과 같습니다.
1) 사이트 입력
2) 주소 페이지를 클릭하십시오
3) 이름, 주소 등과 같은 기타 세부 정보를 입력하십시오.
4)”State”드롭 다운을 클릭합니다. 주 선택
5) '도시'드롭 다운을 클릭합니다 – 도시 이름을 기록해 둡니다.
위의 설명은 정확하지만 완전하지는 않습니다. 이 분야에 관해서는 너무 많은 정보를 제공하지만 너무 적지 않은 편입니다.
다음 단계가 설명에 추가되면 더 이해하기.
6) 주를 'California'로 선택하고 'City'드롭 다운을 클릭합니다. 모든 주가 표시되고 사용자가 필요에 따라 도시를 선택할 수 있습니다.
7) 주를 'Louisiana'로 선택하고 'City'드롭 다운을 클릭하면 목록이 비어 있습니다.
8) 뉴저지 주와 유타 주에서도 도시가 비어 있습니다.
따라서 반복하려면 정확한 단계, 정확한 데이터 및이 필드를 완료하는 데 필요하다고 생각하는 기타 정보를 제공하십시오.
부착 : 문제가있는 모든 지원 문서를 업로드 할 수 있습니다.
모든 정보가 만족스럽게 입력되면 'Create Issue'대화 상자 끝에있는 'Create'버튼을 클릭하여 이슈를 생성 할 수 있습니다.
이슈가 생성되고 이슈 ID와 함께 사용자에게 메시지가 표시됩니다.
참고 : 문제 ID를 확인하십시오. 프로젝트의 '키'로 시작합니다. 특정 프로젝트에 속하는 문제를 추적 / 그룹화하는 JIRA의 방법입니다.
이제 위 메시지에 표시된 링크를 클릭하여 생성 된 문제를 볼 수 있습니다.
이슈 생성 페이지에 대한 추가 세부 정보
1) “Create Issue”페이지의 오른쪽 상단 모서리에 필드 구성 옵션이 있습니다.
이 옵션은 이슈 생성 대화 상자에서 보려는 필드를 선택 / 변경하는 데 사용할 수 있습니다. 선택이 이루어지면 JIRA는 후속 이슈에 대한 변경 사항도 기억합니다.
두) 'Create Issue'페이지 하단에 'Create another'가 있습니다.
이 옵션을 선택하고 'Create (만들기)'를 클릭하면 현재 이슈가 생성됩니다. JIRA는
프로젝트, 이슈 유형 및 이전 이슈에 따라 자동으로 선택된 요약을 제외한 기타 필드와 함께 '이슈 생성'대화 상자가 열립니다.
이것으로“JIRA에서 이슈 생성하기”주제를 마칩니다.
다음 Atlassian JIRA 튜토리얼에서는 하위 작업과이를 특정 QA 목적으로 사용하는 방법에 대해 알아 봅니다.
=> 완전한 JIRA 튜토리얼 시리즈를 보려면 여기를 방문하십시오.
너에게
이제 여러분의 의견을들을 시간입니다. 버그 추적을 위해 JIRA를 사용하는 데 어려움이 있습니까?
결함 관리를 위해 JIRA를 채택하는 데 테스트 팀이 갖는 저항에 무게가 있다고 생각하십니까?