[지식/경험] 이슈(버그) 관리

 

 

 

안녕하세요. 딩딩입니다.

 

이번 포스팅은 게임 QA가 이슈 관리하는 것에 대한 것을 다루려고 합니다.

 

---

 

 

이슈는 무엇일까?

 

 

버그를 부르는 명칭입니다.

 

물론 제가 경험한 회사에서 사용했던 단어입니다.

버그, 결함 등 많은 표현 단어가 있습니다. 포스팅은 제가 경험한 기준으로 이슈로 표현하도록 하겠습니다.

 

 

1. 기획서(명세)를 기반으로 만든 TC에서 기획 의도 다르게 빌드에 적용된 모든 것은 이슈

2. 명세 기반의 TC를 모두 체크 후 테스트 진행 시 발생하는 예외 사항은 모두 이슈

 

 

위의 두 가지의 형태로 대부분의 이슈를 찾아낼 수 있고 이렇게 발견한 이슈들은 BTS 툴을 이용해서 관리됩니다.

이를 흔히 QA의 기본 업무인 테스팅과 이슈(결함) 리포팅이라고 합니다.

(BTS 툴 : 이후 포스팅에서 BTS툴 종류들을 다루겠습니다.)

 

 

 

레드마인

출처 입력

BTS 툴이란 Bug Tracking System의 약자로 버그 추적 시스템입니다.

레드마인은 회사에서 메인으로 사용하였던 BTS 툴입니다. 무료툴이기도 하고 간결하며, 관리하기가 용이합니다.

여러 종류의 BTS들이 있지만 주요 기능은 대부분 동일합니다. 주로 아래와 같은 3가지로 확인이 가능합니다.

(레드 마인 내 항목들은 커스텀이 가능하고 후에 살짝 읽어본 ISTQB 자격증 책자에 버그 생애 주기와 비슷합니다.)

 

 

1. 이슈 상태 관리(히스토리)

2. 목표 버전 관리

3. 담당자

 

 

1) 이슈의 상태 관리

세부적으로 여러 단계가 있습니다. 아래와 같고 회사마다 부르거나 추가, 제거되는 부분은 있지만 이슈관리의 개념적인 내용은 동일하다고 생각하시면 됩니다.

 

- 이슈의 유형

ㄴ 결함 : 버그입니다. 기획의도와 다른 모든 내용, 기능상 문제, 논리적 문제 등 발생하는 문제입니다.

ㄴ 문의 : QA가 판단 시 모호한 내용의 경우 담당자에게 문의하는 내용

ㄴ 의견 : QA가 검증한 내용에 대한 기능, 개선 의견 등의 다양한 내용을 의견으로 건의

 

- 이슈의 상태

현재 리포팅된 이슈의 상태를 확인하는 영역입니다.

이것으로 현재 해당 이슈가 어떤 진행 상태인지를 파악할 수 있습니다.

ㄴ 신규 : 새롭게 등록한 이슈

ㄴ 진행 : 할당받은 담당자가 현재 이슈 확인 후 수정 진행 중인 상태

ㄴ 해결 : 할당받은 담당자가 이슈를 수정 완료한 상태

ㄴ 재수정 : QA가 해결된 이슈를 확인 후 수정되지 않아서 다시 해당 담당자에게 돌린 상태

ㄴ 완료 : QA가 해결된 이슈를 확인 시 수정이 되어서 해당 이슈를 닫은 상태

ㄴ 보류 : 목표 버전 및 수정 확인이 제한되거나 다양한 이유로 보류해 놓은 상태

ㄴ 거절 : 할당받은 담당자가 확인 시 결함이 아니거나, 기획의도인 경우 다시 거절로 QA에게 돌려주는 상태

ㄴ 의견 : 코멘트

 

- 이슈의 심각도

(회사에 따라 크리티컬, 하이, 노말, 로우 등으로 표현하거나 더 세부적으로 구분되는 경우도 있습니다.)

단계별로 구분하며, 게임에 직접적, 회사 매출에 직접적으로 타격을 주는 경우 높은 심각도가 매겨집니다.

심각도가 낮은 경우에도 어떤 상황인지에 따라 달라질 수 있습니다.

예를 들면 정책과 관련된 텍스트나 버튼이 미 노출된다면, 노말급 이슈가 아닌 크리티컬한 이슈가 됩니다.

 

ㄴ 크리티컬 : 게임의 강제 종료, 크래시, 정책, 결제 이슈, 실행 불가, 기기 손상, 재화 어뷰징 등

ㄴ 메이저 : 특정 콘텐츠의 진입 불가, 게임 진행 중 무한 로딩, 특정 스텝 시 화면 프리징, 특정 기능 사용 불가

ㄴ 노말 : 모델링 깨짐, 이미지 잘림, UI 겹침, 이펙트가 나오지 않음, 버튼 터치가 잘되지 않음 , 사소한 기능 장애

ㄴ 마이너 : 오타, 이미지 밀림, UI 밀림

 

- 이슈의 우선순위

심각도와 별개로 해당 이슈의 우선순위를 선정하는 것입니다.

보통 1~4순위 등으로 표현하고 심각도와 별개로 '일정에 따라 우선순위'가 보통 매겨집니다.

같은 크리티컬 이슈라도 당장 이번에 들어가냐 다음에 들어가냐에 따라 우선순위가 달라지는 것과 같습니다.

 

ㄴ 1순위 : 당장 이번에 들어가야한 급한 이슈 및 요청으로 최우선적으로 해결되어야할 이슈

ㄴ 2순위 : 메이저급, 메인급으로 진행되는 내용에서 발생해서 처리해야할 이슈들

ㄴ 3순위 : 일반적인 등록 이슈

ㄴ 4순위 : 다음 스펙에 들어갈 이슈 및 보류된 이슈

 

 

2) 목표 버전 관리

업데이트나 개발은 마일스톤 단위로 일정이 산정됩니다.

그렇다면, 특정 마일스톤에서 들어가는 콘텐츠나 시스템, 이벤트 등이 있을 것인데

해당 이슈가 어떤 목표 버전에서 처리 예정인지 확인 가능한 항목입니다.

목표 버전을 관리하는 건 프로젝트마다 다른데 보통 아래와 같습니다.

 

- 해당 이슈를 해당 목표 버전에서 처리 예정 (ex. 마일스톤2에서 고치고 가야할 이슈)

- 해당 이슈가 발생한 버전 (ex. 마일스톤2에서 발생한 이슈)

 

주로 당연히 이슈를 어떤 버전에서 처리한 것인가를 정하는 게 주이지만, 간혹 BTS에서 이슈 관리를 용이하게 하기 위해서 발생한 버전으로 관리하는 경우가 있습니다.

이 역시도 담당자들에 사용 노하우기 때문에 사용하기 나름이라고 말씀드릴 수 있겠습니다.

 

 

3) 담당자

현재 어떤 사람이 이슈를 추적하고 있는지 담당자 이름으로 확인됩니다.

직접 QA가 등록 시 해당 담당자를 지정해서 리포팅을 진행합니다.

- QA

- 유관부서(사업, 운영, 서비스 PM, CS 팀)

- 개발사(담당 기획자, 프로그래머, 그래픽 디자이너 등)

 

 

 

 

"이슈의 관리"

 

 

 

위에 설명된 내용을 간략하게 정리를 하면 아래와 같습니다.

 

1. 테스트를 진행한 QA가 버그를 담당자를 지정해서 리포팅한다.

2. 버그를 리포팅 받은 담당자가 수정 진행한다.

3. 수정 완료한 담당자는 다시 리포팅한 QA에게 해결로 돌려준다.

4. QA는 이를 수정 확인한다. 수정 확인 시 이슈를 닫음 처리한다.

5. QA가 확인 시 수정이 되지 않으면 재수정 상태로 다시 담당자에게 돌려준다.

 

이런 행위를 반복하면서 특정 목표 버전의 일정을 기준으로 반복하면서 빌드를 점점 안정화 시키게 됩니다.

 

 

 

 

마지막으로 이슈를 BTS에 리포팅할 때 필요한 것은 아래와 같은 내용이 첨부가 되어야 합니다.

 

- 환경 : 이슈를 찾은 환경이 라이브 서버인지? QA 서버인지? 등의 테스트 환경입니다.

- 이슈 내용 : 발생 이슈의 내용입니다. (실제 결과이며, 간헐적인 경우 몇번 시도해서 몇번 발생했는지도 기입)

- 이슈 발생 버전 : 발생한 빌드의 버전입니다.

- 재현 스텝 : 가능하다면 1. 2. 3.등으로 넘버링하여 정확하게 재현할 수 있도록 간결하게 알려주어야 합니다.

- 참고사항 : 사용한 기기의 정보, 플랫폼 등의 이슈를 발견한 당시의 참고 상태와 정보를 설명합니다.

+ 스크린샷 및 동영상 등

- 기대결과 : 기획서(명세)에 기입된 기대 결과를 적어줍니다. (올바른 구동에 대한 결과)

 

 

---

 

QA의 기본적인 업무인 이슈관리에 대해서 설명해드렸습니다.

흔히들 생각하는 QA = 테스트라고 하시는 부분이 바로 이 이슈 관리 부분입니다. 하지만 이 부분은 세밀하게 따져보면 QA의 업무가 아닌 QC의 업무입니다. 관련 내용은 이후에 별도의 포스팅으로 진행할 예정이고요!