QA의 업무 이야기: ① 테스트 결함 추적 툴 'JIRA'

JIRA는 게임 개발, 특히 QA에게는 필수적인 소프트웨어다. JIRA는 트렐로(Trello)나 컨플루언스(confluence)를 만든 아틀란시안에서 만든 프로젝트 관리 및 결함 추적 도구다. JIRA는 일정 주기를 가지고 프로젝트를 진행하는 애자일 개발 방식에 가장 특화된 툴로, 산출물을 배포하기 위한 기본 단위인 스프린트와 사용자 스토리, 이슈 등 생성이 용이하다. 가시성 또한 좋고, 시각적 데이터를 보기도 편하다. 배포를 의미하는 릴리즈 단계에서도 어떤 상태인지 알아보기에 좋다.

QA뿐 아니라 개발팀이나 기획팀, 아트팀 등 조직 내 여러 팀에서도 활용하기 좋다. 보드(board)에서 자신이 속한 프로젝트에 해야 할 일(To do)도 있고, 진행 중(In progress)인 일들, 리뷰(review) 중인 것들, 끝난 일(done)도 확인할 수 있다. 즉 본인에게 주어진 일은 모두 여기에 기록하고 그게 아니라면 신경 쓸 필요는 없다. 업무 중에는 지라 티켓을 생성해 각각 개발 산출물을 기록해둔다. 변경된 코드, 기획에 따른 데이터 테이블, UI 산출물 나아가 슬랙(Slack)이나 메일 같은 다양한 곳에서 논의된 내용도 코멘트를 활용해 남겨둔다. 이것은 향후 누가 오더라도 쉽게 업무를 이어갈 수 있게 해준다. 퇴근할 때는 본인이 작업한 내용에 대한 티켓에 작업시간과 내용 등을 기록하며, 이를 통해 추후 비슷한 프로젝트를 진행했을 때 얼마나 작업 시간이 걸릴지 예측할 수 있다. 

그래서 주로 테스팅을 담당하는 QA팀에게는 결함을 추적하기 위한 도구로 쓰인다. 결함 관리 도구는 지라(JIRA), 레드마인(REDMINE), 맨티스(Mantis) 등 다양하지만 현장에서 가장 많이 쓰이는 JIRA를 중심으로 결함 추적 도구에 대해 알아보자.

결함을 왜 관리해야 할까?

테스팅의 주요 목적 중 하나는 결함을 찾는 것이다. 흔히 버그라고 불리는 결함은 모든 소프트웨어에서 발생한다. 이런 내용은 테스팅의 7가지 원칙 중 ‘완벽한 테스팅은 불가능하다’에서도 알 수 있다. 이 결함은 반드시 기록해야 한다. 이때는 흔히 버그 트랙킹 시스템(BTS; Bug Tracking System)이라고 불리는 결함 추적 도구를 활용한다. 찾아낸 모든 결함을 조사해 관계자들과 공유하며, 결함을 분류해서 상태를 추적한다.

결함의 원인은 다양하다. 코드 자체가 복잡해서 발생할 수도 있고, 기존 시스템에 대한 이해가 부족해서 나타날 수도 있다. 기획자와 개발자 간 의사소통의 오해로 인해 결함이 생길 수도 있다. 시간이 모자라 담당자가 실수할 수 있다. 잘못된 테스팅으로부터 오는 착각으로 결함이 있다고 오해할 수도 있다. 예를 들어 하드웨어에 문제가 생겨 컴퓨터가 제대로 동작하지 못할 수도 있다. 또는 인터넷에 문제가 생긴 것을 오해해 소프트웨어에 결함이 있다고 인식할 때도 있다. 이외에도 테스트 방식, 테스트 데이터, 테스트 환경 등 여러 가지 변수는 언제나 존재한다. 이 과정에서 결함으로 보고됐지만, 실제로는 결함이 아닌 경우가 있는데 이것을 거짓 양성(false positive)이라고도 불린다. 참고로 이와 반대인 거짓 음성(false negative)은 테스트를 통해 발견되었어야 할 결함을 발견하지 못하는 경우다.

결함 추적 도구는 이런 여러 상황을 해결하기 위해 존재한다. 결함은 소프트웨어 사용 중 보고 할 수 있다. 이외에도 기획서나 개발 관련 문서 등에 정리가 필요한 부분에 대한 이슈가 결함으로써 보고될 수도 있다. 또는 관련자들이 이메일이나 채팅 프로그램, 대화 등을 통해 결함에 대한 이야기를 나눌 수도 있는 것이다. 그러나 그것은 업무에 도움이 되지 않는다. 결함 보고서가 작성되지 않는다면 다른 사람들과 공통적인 체계로 공유가 어렵고, 처리에 대한 논의도 파악하기 힘들다. 결함 추적 도구는 결함의 수나 심각도에 따라 프로젝트 일정이 변경되거나 내용이 수정될 수 있다. 그래서 결함이 품질에 얼마나 영향을 미치고 테스트에 영향을 줄 수 있는지에 대한 정보를 제공한다.

JIRA로 보는 결함 추적의 흐름

우선 결함은 그 상태에 따라 처리가 어떻게 될지 정해진다. 결함 보고서를 작성한 사람(주로 QA)은 보고자가 된다. 이후 담당자가 지정되고, 관련된 사람들도 이슈 상태에 대한 알림을 받을 수 있도록 태그 할 수 있다. 물론 회사의 다양한 구성원도 관련 결함 보고서 또는 다르게도 부르는 이슈(Issue)를 찾아 검색해서 볼 수 있다. 

각 회사마다 또는 프로젝트마다 다르게 워크 플로우를 설정할 수 있다. 이것은 지라만의 강점이다. 소프트웨어의 빌드, 테스트 및 출시하는 것까지 도움이 되는 워크 플로우를 사용자가 지정할 수 있기 때문이다. 누구나 결함이 어떤 흐름을 가지고 상태가 정해지는지 이해하기 쉽다.

일반적으로는 Open(이슈 생성) - In progress(수정, 작업 중) - Close(수정 확인 완료)의 뼈대를 가지고 있으며, 각 상황에 따라 다음과 같은 이슈도 있을 수 있다.

• Need more information (정보가 더 필요한 상태)
• Pending (보류 상태)
• Request close (이슈 close 요청)
• Re open (다시 opne 상태로 변경)
• Claim fix (수정 확인 요청 상태)
• Review in progress (수정 작업에 대한 리뷰)

일부 예시로 들었지만 필요에 따라 다양한 상태를 생성할 수 있고 지울 수도 있다. 명백한 결함이라면 보통 개발자가 담당자가 되어 이슈를 수정한다. 코드를 수정할 수도 있고, 오타를 수정하거나 빠졌던 데이터를 더 넣을 수도 있다. 기획의도 확인이 필요할 때는 기획자가 담당자가 된다. 기획서의 내용이 서로 충돌되거나 실제 클라이언트의 동작이 기획에 없는 등의 경우는 의외로 많이 발생한다. 또, 기획서 해석에 대한 오해가 있을 때 역시 확인을 위해 결함 보고서로 등록해둔다. 

이 모든 과정은 관계자 누구나 관련 내용을 찾아보고 훗날 결함 수정 확인 후 발생하거나, 비슷한 결함이 발견될 시 해결을 위한 참고 사항이 될 수 있다. 또 다른 경우로 수정 방향과 그 영향에 따라 개발이나 테스트 프로세스에 대한 개선 아이디어가 나올 수 있다. 

JIRA로 보는 결함 보고서 내용

JIRA에 제공되는 결함 보고서 기능은 여러 가지다. 생성된 이슈를 서로 연결할 수 있고, 복제하거나 이동시킬 수 있다. 이를 통해 관리가 더 수월하도록 만들 수 있다. 담당자는 작업 이력 및 시간을 남길 수 있고 개발 과정에서 해결 방법을 태그하기 용이하다. QA의 경우 관련된 테스트 케이스를 연결해 결과를 처리하기에 용이하다. 보고용으로는 관련 파일이나 이미지, 동영상 등 첨부하기 편리한 것도 장점이다. 보고서에 필요한 각 항목별 내용이 체계적으로 나뉘어 있으니 쓰기도 편하고 보기에도 좋다. 

더불어 결함 보고서에 필수적으로 들어가야 하는 내용은 다음과 같다.

• 식별 번호
• 제목과 내용 설명
• 해당 영역(feature)/심각도/우선순위
• 날짜/담당자/보고자/보고 대상이 되는 조직 및 담당자들
• 빌드 및 서버 등 테스트 환경
• 로그, 덤프, 스크린샷, 녹화 영상 등 참고 자료
• 기대결과
• 재현스텝 및 재현율

위의 내용은 누구나 이해 가능하도록 작성해야 한다. 결함 내용은 구체적일수록 좋다. 다만 QA가 보고서를 많이 작성하는 만큼 주 담당자인 개발자들도 많은 보고서를 보게 된다. 특히 제목에 더 신경 써서 제목이 곧 내용이 되도록 간결한 문장으로 전달하는 것이 중요하다. 

실제 JIRA의 결함 보고서를 만들기 위한 툴의 예시이다. 이 역시 프로젝트 별로 항목을 바꿀 수 있는데 관련 세부 정보를 모두 사용자가 설정할 수 있다. JIRA를 통한 이런 버그 트랙킹 시스템은 결함의 구체적인 영향을 식별하고 재현과 확인 테스팅을 통해 결함 수정을 돕는다. 나아가 필요에 따라 문제를 해결할 다른 방법도 찾을 수 있다. 이 모든 과정은 제품의 품질을 높인다는 점에서 소프트웨어 개발 과정에 반드시 필요하다. 

결함 추적 도구로써의 JIRA

JIRA는 결함 추적 도구로써 모든 정보를 알기 편하게 제공한다. 포괄 검색 기능이나 메일을 통한 자동 변동 사항 공유, @를 통한 멘션 등 사용자 지정을 통해서 소통하기 편리하다. 담당자나 보고자 등 세부사항에 내용 변동이 있거나 오타가 있을 때도 편리하다. 만약, 개발사와 퍼블리셔(배포사)가 다를 경우 복사와 같은 기능을 통해서 이슈에 대한 정보를 공유하기도 쉽다. 또한 같은 JIRA 활용 시 필요한 부분은 권한이 허락하는 것에 따라 볼 수도 있어, 협력사 간 업무에 대한 이해를 돕는다. 

이러한 JIRA는 테스트 관리 도구인 테스트레일(TestRail)과 완벽하게 어울린다. 테스트 레일은 테스트에 대한 내용에 대한 결과를 입력하고, 테스트 케이스를 작성해 테스트 작업을 관리할 수 있다. 결함이 발견되고 JIRA에 이슈로서 등록되면 테스트레일 내 존재하는 테스트 케이스에 연결시키는 매핑을 통해서 결과 처리를 할 수 있다. 이때 JIRA에도 연결된 테스트 케이스가 노출된다. 이를 통해 어떤 문제 때문에 어떤 영향을 주는지 파악하기 수월해진다. 지금까지 테스트 결함 추적 툴 지라에 대해 살펴보았다. 다음 편에선 테스트레일에 대해 좀 더 자세히 살펴볼 예정이다.