개념
도구는 다르지만 개념은 같다
Jira, Redmine, Bugzilla, Mantis, Trac — 회사마다 쓰는 이슈 추적 도구는 다르지만, 이들이 다루는 핵심 개념은 거의 동일하다. 하나의 도구를 "버튼 위치"로 외우면 다른 도구로 옮겼을 때 처음부터 다시 배워야 한다. 반대로 공통 개념을 이해하면, 어떤 도구를 접해도 화면 어딘가에서 같은 개념을 찾아 바로 적응할 수 있다.
공통 개념 1 — 이슈 타입(Issue Type)
결함(Bug)만 등록하는 게 아니다. 새 기능 요청(Story/Feature), 개선 작업(Task), 그리고 결함(Bug)이 대표적인 이슈 타입이다. QA가 주로 다루는 건 Bug지만, 테스트 케이스 작성이나 회귀 테스트 같은 QA 작업 자체를 Task로 등록해 추적하는 팀도 많다.
공통 개념 2 — 워크플로(Workflow)
레슨 1에서 배운 결함 생명주기(New → Assigned → ... → Closed)가 바로 이슈 추적 도구의 워크플로다. Jira에서는 이 워크플로를 프로젝트마다 커스터마이징할 수 있어서, 팀마다 상태 이름이나 순서가 조금씩 다를 수 있다 — 하지만 "발견 → 처리 중 → 검증 → 종결"이라는 큰 골격은 어디서나 같다.
공통 개념 3 — 필드(Fields)
- 심각도(Severity) / 우선순위(Priority) — 레슨 1에서 배운 그 값
- 담당자(Assignee) — 지금 이 이슈를 처리해야 할 사람
- 보고자(Reporter) — 이슈를 등록한 사람(QA인 경우가 많다)
- 라벨/컴포넌트(Labels/Components) — 어느 기능 영역에 속하는지 분류(예: "결제", "로그인") — 나중에 레슨 5의 결함 밀도 계산에 이 분류가 쓰인다
- 연결(Links) — "이 이슈는 저 이슈의 중복이다", "이 이슈는 저 기능에 의존한다" 같은 이슈 간 관계
공통 개념 4 — 검색과 필터
이슈가 수백~수천 개 쌓이면, 검색·필터 없이는 아무것도 못 찾는다. "내게 할당된 채 아직 안 고쳐진 심각도 높은 이슈"처럼 조건을 조합해 찾는 기능(Jira의 JQL 등)은 도구마다 문법은 다르지만 개념은 같다 — 상태 + 담당자 + 필드값을 조합해 원하는 이슈 목록을 뽑아내는 것.
Jira 실습 관점에서 볼 것들
이 강의는 Jira 사용법 자체를 목표로 하지 않지만, 실습 삼아 Jira의 무료 클라우드 계정을 만들어 위 4가지 개념(이슈 타입, 워크플로, 필드, 필터)이 화면 어디에 대응하는지 직접 찾아보는 것을 권장한다. 화면 버튼의 정확한 위치보다, **"이게 레슨 1의 어떤 개념에 해당하는가"**를 연결 짓는 게 이 레슨의 목표다.
실무에서 왜 필요한가
거의 모든 QA 채용공고에 "Jira 사용 경험"이 등장한다. 하지만 실무에서 도구는 회사마다, 심지어 같은 회사 안에서도 팀 전환 시 바뀔 수 있다. "Jira 버튼 위치"만 외운 사람은 도구가 바뀌면 처음부터 헤매지만, 공통 개념을 이해한 사람은 새 도구의 화면을 보자마자 "아, 이게 여기서 말하는 워크플로구나"라고 바로 적응한다. 이게 채용 면접에서 "다른 도구도 써보셨나요?"라는 질문에 자신 있게 답할 수 있는 근거가 된다.
실습 과제
과제 1 — 개념 매핑표 만들기 (10분)
Jira(또는 사용해본 다른 이슈 추적 도구)를 하나 떠올려, 이 레슨에서 배운 4가지 공통 개념(이슈 타입/워크플로/필드/필터)이 그 도구의 어떤 화면·메뉴에 대응하는지 표로 정리한다. 써본 도구가 없다면 Jira 무료 계정을 만들어 화면을 직접 둘러보며 채운다.
과제 2 — 필터 조건 설계하기 (8분)
"내가 보고했지만 아직 종결되지 않은, 심각도가 높은 이슈만 보고 싶다"는 조건을 만족하는 필터를 어떤 필드들의 조합으로 구성할지 글로 적어본다.
자가 체크리스트
- 이슈 타입·워크플로·필드·필터라는 4가지 공통 개념을 설명할 수 있다
- 결함 생명주기(레슨 1)가 이슈 추적 도구의 워크플로와 같은 개념임을 안다
- 심각도·우선순위 외에 담당자·보고자·라벨·연결 필드의 역할을 설명할 수 있다
- 도구가 바뀌어도 공통 개념을 기반으로 빠르게 적응할 수 있다고 설명할 수 있다
흔한 실수
- 도구 사용법(버튼 위치)만 암기하고 개념을 이해하지 않는다. 도구가 바뀌면 처음부터 다시 배워야 한다.
- 모든 이슈를 Bug로만 등록한다. 개선 요청이나 작업(Task)까지 전부 Bug로 등록하면 통계(레슨 5)가 왜곡된다.
- 라벨/컴포넌트 분류를 대충 채우거나 생략한다. 나중에 "어느 기능 영역에서 결함이 많이 나오는가"를 분석할 때 이 분류가 없으면 집계 자체가 불가능하다.
참고 자료
- Atlassian Jira 공식 문서 — Workflow — 워크플로 개념의 공식 설명
- ISTQB Glossary — Incident Management Tool — 이슈 추적 도구의 공식 용어 정의