김성태의 Tech Tips - supersky.pe.kr

효과적인 버그 관리 도구, BTS(Bug Tracking System)

이영석 stone@sqe.co.kr

SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 (주)와이즈스톤 대표이며, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다.

2007년 11월 6일

혀는 몸을 베는 칼이다.

중국 속담에 '차가운 차와 차가운 밥은 참을 수 있지만 차가운 이야기는 견디지 못한다'라는 말이 있다. 말이라는 것만큼 사람에게 큰 상처를 주는 흉기도 없다. 반면 '말 한마디로 천냥 빚을 갚는다'는 말도 있다. 경우에 따라 사람의 말만큼 큰 보배도 없다.

사람과 사람 사이에서 '말 ^[1]'과 '대화 ^[2]'라는 것을 빼고 관계 형성을 생각하기 어렵다. 관계라는 것이 대부분 말과 대화 등의 도구를 통한 커뮤니케이션 ^[3]을 기반으로 형성되고 유지되니 말이다. 개발자와 테스터 사이에서도 이 '말'과 '대화'를 빼고 서로의 관계를 논하기 어렵다.

필자는 지난 몇 년 간 소프트웨어 시험인증 업무를 해오며 개발자와 테스터 간의 언쟁을 자주 목격해 왔다. 개발자 입장에서는 자신의 땀과 노력의 산물인 소프트웨어가 그 본질의 가치를 차치하고 테스트 성공/실패라는 이분법적인 기준으로 평가 받고 지적 받는 것에 대해 쉽사리 그 평가의 논리를 받아들이기 어려울 수 밖에 없다. 반면 테스터는 네거티브한 업무의 특성상 그들의 업무 성과로 발견된 문제점들을 전쟁에서 이긴 승자의 전리품처럼 자랑스럽게 펼쳐놓는 것이 어찌 보면 당연하다 할 수 있다.

이런 서로 상반된 업무의 본질적 특성에 기인하여 개발자와 테스터는 좀처럼 담담한 커뮤니케이션을 이어가기 어렵다. 조금의 말 실수에도 서로의 감정에 상처받기 십상이며, 끝까지 원만한 공감대를 유지하기가 어려워지기도 한다.

좋은 테스터의 자질 중에는 '좋은 인격과 열린 마음', '좋은 대화 능력' 등의 항목이 있다. 테스터 이외에 다른 모든 업무 종사자에게도 이런 자질이 필요하겠지만, 특히나 개발자와 많은 부분에서 의견 충돌이 발생할 수밖에 없는 테스팅 업무의 특성상 테스터에게 더욱 요구되는 중요한 항목이라 하겠다. 필자는 기회가 있을 때마다 이러한 문제의 해결 방안으로 다음과 같은 조언을 하곤 한다.

'서로 얼굴을 맞대고 대화하지 마라!'

감정이 노출되는 말을 이용한 커뮤니케이션보다는 직접적인 감정 전달이 어려운 글을 통한 커뮤니케이션, 이를테면 정형화(formal)된 포맷을 이용해 서로 의사 소통을 한다면 혹시나 발생할 수 있는 불필요한 감정 소모를 피할 수 있을 것이다.

이러한 해법으로 메일, 메신저, 문자 등이 있을 수 있지만 보다 효과적인 시스템 도구의 도움을 받을 수 있다. BTS(Bug Tracking System)는 그런 도움을 주는 시스템 도구 중 하나다.

위로

BTS(Bug Tracking System)이란 무엇인가?

BTS의 정의는 다음과 같다.

'BTS는 QA와 개발자가 발견된 소프트웨어의 버그를 추적하는 것을 돕기 위한 소프트웨어' ^[4](A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work. It may be regarded as a sort of issue tracking system)

즉 개발 과정(개발 중이거나 혹은 개발이 완료된)에서 발견된 소프트웨어 버그의 상태(결함은 상태를 갖는다) 변화 과정을 추적하기 위한 소프트웨어라는 것이다. 여기서 말하는 추적이란 특정 도구를 이용해 어떠한 대상의 움직임을 따라 가는 것을 말한다. 예를 들면 전투기의 움직임을 레이더가 추적하듯이 말이다.

각각의 버그에는 상태가 존재하며 그 상태는 계속 변한다. 그러므로 추적(tracking)이 필요하다. 다시 말해 버그의 상태가 어떻게 변해가고 있는지에 대한 추적이 필요하며 그에 대한 도구가 바로 BTS인 것이다. BTS 도입으로 다음과 같은 효과를 기대할 수 있다.

발견된 버그의 현재 상태를 알 수 있다. 발견된 버그가 수정되었는지 아니면 수정되지 않았는지 등에 대한 버그 상태 정보를 알 수 있다. 즉 내가 보고한 버그가 현재 수정되었는지 수정 완료 보고를 듣기 전까지 알 수 없었던 상태 파악의 어려움을 해결할 수 있다.
버그 수정 진행 상황을 파악할 수 있다. 발견된 버그가 누구에 의해 검토되었는지 혹은 기각되었는지, 그리고 누구에 의해 수정되었는지 등 버그 수정 진행 상황을 파악할 수 있다.
알려진 버그의 누락을 막을 수 있다. 시스템을 통한 관리로 혹시라도 생길 수 있는 발견된 버그의 수정 누락을 막을 수 있다. 전화와 쪽지, 이메일 등을 사용하여 수백, 수천 개의 버그를 수개월, 수년간의 프로젝트 기간 동안에 누락되는 일 없이 관리한다는 것은 어려운 일이 될 것이다.
개발자와 테스터 간의 커뮤니케이션 비용을 줄일 수 있다. 서두에서 언급한 것처럼 개발자와 테스터간의 정형화된 대화 방법을 시스템이 제안함으로써, 버그에 대한 정확한 정보를 주고 받을 수 있어 불필요한 커뮤니케이션 비용을 줄일 수 있다. 또한 개발자와 테스터의 상반된 입장으로 생길 수 있는 조직간의 감정 싸움 등을 막을 수 있는 효과도 있다.
실시간 버그의 통계 정보를 얻을 수 있다(제품의 품질 성숙도를 알 수 있다). 현재 시점의 발견된 버그의 개수와 수정되지 않고 남아 있는 심각한 버그 개수 등의 통계 정보를 시스템을 통해 실시간으로 얻을 수 있고, 이로 인해 제품의 현시점의 품질 성숙도를 예측할 수 있다.

위로

BTS 제품들

현재 인지도가 가장 높고 많이 사용하는 오픈 소스 BTS로는 Mantis ^[5], Bugzilla ^[6], Trac ^[7], Scarab ^[8] 등이 있다. 소프트웨어 개발을 지원하기 위한 솔루션보다 테스팅 관련 솔루션은 현실적으로 대부분 도입 우선순위가 밀린다. 이런 이유로 인해 대부분의 소프트웨어 개발사에서 사용하는 BTS는 프리웨어다. 또한 대부분이 외산 소프트웨어다. 이러한 상황은 국내 QA 산업의 현황을 보여준다는 점에서 한번쯤 생각해 볼만한 부분이다.

Mantis

Mantis는 사용자로 등록한 회사만 약 600여 개에 이를 정도로 많은 사용자를 보유한 시스템이다. 이렇게 많은 사용자가 Mantis 사용 중 발생한 버그를 서로 등록하고 서로 수정을 하여 점차 완성도를 높여가고 있다.
사용자 인터페이스는 직관적이며 한국 사용자들의 눈에 친숙한 느낌을 준다. OS에 상관없이 PHP와 MySQL, 아파치(또는 IIS)만 있으면 사용할 수 있다. 각 나라별 언어를 지원(localization)하여 사용 언어 설정만 바꾸면 바로 한글 인터페이스로 사용할 수 있다. 다만 한글 번역이 일부 부분에서 매끄럽지 않아 수정이 필요하다. 각각의 모듈이 PHP 파일로 서비스되고 있어, 여러 개의 클래스나 모듈을 따져가면서 수정해야 하는 자바나 펄(Perl)보다 개발자가 쉽게 수정할 수 있다. 위키(WiKi) 형태로 WAP을 지원하며, 웹 서비스로 닷넷, 자바 등의 라이브러리를 제공하며 웹 서비스를 통한 이클립스 플러그인을 제공한다는 특징이 있다. 버그를 등록하는 화면이 간단하기 때문에 특별한 사용 설명서 없이 처음 접하는 사람도 쉽게 작업할 수 있다.

Bugzilla

Bugzilla는 BTS에 관심을 가진 사용자라면 한번쯤 들어봤을 만큼 세계적으로 널리 알려진 시스템이다. 모질라, 리눅스 커널, 아파치, 이클립스, 레드햇, GNOME 등의 오픈 소스 진영에서 이미 버그 추적 시스템으로 사용되었으며, 그로 인해 안정성이 이미 검증된 시스템이다.
개발 언어는 펄을 이용했으며, 서버는 MySQL과 PostgreSQL을 지원한다. Bugzilla를 설치한 후 BTS의 기능을 제대로 사용하려면 추가로 Graph, SMTP 등의 모듈을 패치해야 한다. 몇 가지 모듈을 추가로 설치해야 하므로 빠른 시간 내에 프로젝트에 도입하려는 사용자들은 조금 불편하다고 느낄 수 있다. 하지만 불편함을 차치하고, Bugzilla는 기대 이상의 막강한 기능과 플러그인을 제공한다. 모바일 클라이언트, IDE 통합 도구(Eclipse, Mylyn), 프로젝트 관리(TaskJuggler), CVS, 테스크 케이스 관리(Testopia) 외에도 시스템에 추가할 수 있는 수많은 플러그인을 제공한다. 플러그인을 패치만 하면 추가 모듈이 Bugzilla로 손쉽게 통합된다. 다만 여러 가지 플러그인 모듈간의 연계성으로 인해 사용자 커스터마이징은 까다로운 경향이 있다.

Trac

Trac은 BTS보다는 프로젝트 관리도구에 더 가깝다고 할 수 있다. 최소한의 BTS 기능만 가지고 있지만 다양한 외부 모듈과 연계하여 기능을 지원한다. 기본 언어는 파이썬으로 작성되어 있어 좋은 성능을 제공하며, 데이터베이스는 파일 데이터베이스 개념인 SQLite를 사용한다. 버전 관리를 위한 subversion과 위키를 이용한 문서 관리 기능을 추가할 수 있다. Trac은 Timeline이라는 변경 이력(audit trail)을 제공하며, Milestone으로 통해 현재의 버그 상태 등을 한눈에 볼 수 있도록 하는 기능을 제공한다. Trac은 여타 BTS보다 설치가 까다롭지만, 설치에 공을 들인 만큼의 높은 성능을 기대할 만하다.

Scarab

Tigris라는 회사에서 GPL을 따르는 오픈 소스로 만든 Scarab은 BTS를 매우 간단한 사용자 인터페이스로 구현했다. 개발 언어는 자바를 이용하였다.
Scarab 내부에 웹 서버로 톰캣(Tomcat)을 포함하고 있으며, 사용자가 높은 버전의 톰캣으로 바꿀 수도 있다. 데이터베이스로는 MySQL, PostgreSQL, hypersonic을 지원한다. 추가 모듈을 다운로드하려면 Ant나 Maven이 필요하다. 국가별 사용 언어를 자동으로 지원하여 Scarab을 깔면 따로 설정 변경 없이 바로 한글을 사용할 수 있다. BTS의 기본 기능은 충실히 구현했지만 Bugzilla에 비해 다양한 플러그인이나 추가 모듈 등이 제공되지 않아 좀더 다양한 기능의 BTS로 확장하기에는 어려운 점이 많다. 프로그램 구조가 쉬워 자바에 익숙한 사용자라면 별로 어렵지 않게 커스터마이징할 수 있다.

위로

BTS 도입시 고려사항

BTS 도입시 다음과 같은 항목을 참고하여 각 제품을 비교한다면 도입 목적에 맞는 솔루션을 선택할 수 있다.

웹 클라이언트 지원

BTS는 무엇을 위한 시스템인지 사용자가 바로 인지할 수 있도록 사용자에게 친숙한 환경을 제공해야 한다. 국내 사용자들은 대부분 간단하고 직관적인 UI를 좋아하는 경향이 있어 몇몇 오픈 소스 BTS는 좋은 기능을 제공하더라도 국내 개발자나 테스터들에게 익숙하지 않을 수 있다. 또한 테스트하는 환경과 상관없이 웹을 통해 다양한 환경에서 BTS를 사용할 수 있어야 한다. 그러므로 BTS를 선택시 웹 클라이언트 지원 여부는 중요한 선택 기준이 된다.

이기종 플랫폼의 웹 서버 지원

BTS를 윈도우 환경 또는 유닉스 환경 등에 상관없이 설치하고 사용할 수 있는지 여부를 확인한다. 개발 프로젝트 진행시 다양한 프로그램 개발 환경이 존재하고 테스트 환경이 각각 다를 수 있으므로 특정 환경에서만 구동되는 BTS의 경우 사용성이 떨어진다. 이러한 이유로 다양한 플랫폼을 지원하는지 여부는 BTS 선택시 중요한 고려 항목이다.

프로세스 및 워크플로우 커스터마이징

기본적으로 BTS는 버그 추적 프로세스를 내장하고 있다. 버그 추적 프로세스의 기본 기능은 대부분의 BTS들이 비슷하지만 BTS마다 프로세스들이 약간씩 다르다. 처음 BTS를 쓰다 보면 요구사항이 생기고 그럴 때마다 소스 코드 수정 없이 프로세스 변경을 가능하게 해주는 기능이 필요하다. 마찬가지로 워크플로우를 설정하는 기능도 요구사항이 바뀔 수 있으므로 수정할 수 있는 기능이 필요하다.

버그간 연관 관계 정보 제공(duplicates, related, mother/daughter)

많은 테스터가 버그를 등록하는 경우에 부득이하게 버그가 중복 등록된다. 또한 새로 등록하는 버그가 기존에 이미 등록된 버그와 연관성을 갖는 경우가 있다. 이런 경우를 위해 버그의 연관정보 설정 및 연관정보 제공 기능이 필요하다.

이벤트 통보 기능

버그가 등록되는 경우, 버그 검토를 할당 받을 경우, 할당된 버그가 해결되는 경우 등에 각각의 담당자에게 이메일이나 메신저 혹은 SMS를 통해 상황을 전달하는 기능이 필요하다. 통보 메시지는 버그의 모든 변경사항을 전달할 수 있어야 한다. 또한 메시지 형태를 기본 템플릿으로 제공하거나 사용자가 메시지 형태를 커스터마이징할 수 있도록 하는 기능이 요구된다.

리포트, 차트, 쿼리 구성 및 저장

버그의 각 상태, 버그의 심각성 정보, 버그 등록 후 처리된 시간 등을 파악할 수 있는 리포트 기능이 필요하다. 리포트는 여러 가지 조건에서 사용자가 원하는 형태로 구성할 수 있어야 하고, 차트 역시 다양한 형태의 그래프들로 구성할 수 있어야 한다. 또한 사용자가 작성한 쿼리를 계속 사용할 수 있도록 쿼리 저장 기능 역시 제공되어야 한다. 대부분의 오픈 소스 제품의 경우에는 리포트와 차트 기능이 다양하게 제공되지 않는다. 상용 제품의 경우 이 부분에 강점이 있다.

변경사항에 대한 추적 기능(audit-trail)

버그의 상태 사항정보 중 등록, 할당, 등록된 버그 열기, 중복, 연기, 해결 등의 과정을 거치면서 버그의 변경 사항들에 대한 이력이 추가된다. 이러한 버그의 변경 이력들을 모두 추적할 수 있도록 하는 기능이 제공되어야 한다.

다국어 지원(UTF-8)

웹 기반의 외산 솔루션을 사용할 때 사용자가 가장 곤란을 겪는 경우가 바로 한국어 지원 부분이다. 버그를 등록하거나 또는 등록된 버그를 검색할 때 한국어 처리 중 문제가 발생하는 경우가 빈번히 발생한다. 사용하고자 하는 언어를 지원하는지 여부는 중요한 고려 사항이며, 사용 언어를 변경하는 경우에 애플리케이션 코드를 수정하기보다는 CONFIG를 수정하여 간단히 해결할 수 있도록 하는 기능이 제공되어야 한다.

다중 프로젝트 지원

회사 내에 발생하는 여러 개의 프로젝트 관리를 위해 다수의 프로젝트를 관리할 수 있도록 하는 기능이 제공되어야 한다.

접근 제어 지원

BTS는 버그 등록 권한, 버그 상태 수정 권한, 다중 프로젝트 제어 권한, 사용자 할당 권한 등을 사용자의 역할에 맞도록 세분화하여 할당할 수 있는 기능이 제공되어야 한다.

LDAP/Active Directory 지원

기존 사용자 정보를 저장하고 있는 시스템과 연동을 위해 LDAP 등의 기능이 제공되어야 한다.

사용자 필드 편집 기능 지원

회사별로 또는 프로젝트별로 버그 등록시 필요한 입력 정보와 불필요한 입력 정보는 다르다. 이러한 입력 정보 필드 수정을 애플리케이션 코드 수정을 통해 해야 한다면 사용성이 좋지 못하다. 그런 이유로 BTS에는 간단한 설정을 통해 특정 입력 필드를 추가하거나 삭제하는 기능이 제공되어야 한다.

버그 검색

수백, 수천 개의 등록된 버그에서 찾고자 하는 버그를 검색 기능없이 찾기란 불가능하다. 등록된 버그를 검색하는 기능이 제공되어야 한다. 또한 버그의 상태별, 제목별, 내용별 등 다양한 검색 설정이 가능하여야 한다.

위로

후기

앞서 언급한 바와 같이 BTS는 개발자와 테스터간의 커뮤니케이션만을 위한 도구는 아니다. BTS를 통해 소프트웨어 개발사는 개발과정 중에 발생하는 버그 수정의 누락 방지, 버그 현황 파악, 개발과정에서 발생된 버그의 통계 파악 등의 도움을 받을 수 있다.

이러한 도구가 있음에도 불구하고 사용하지 않는다는 것은 어떤 목적에서건 사용하는 것만 못하다는 것은 자명한 일이라 하겠다. 더구나 대부분의 도구가 무료로 제공되어 큰 비용이 들지 않음에도 말이다.

얼마전 와이즈스톤에서는 오픈 소스로 OWL ^[9]이라는 BTS를 공개했다(http://wisestone.kr/owl/download/). 철저한 외산 소프트웨어의 분석을 토대로 개발된 제품인 까닭에 오픈 소스 소프트웨어임에도 불구하고 높은 사용성과 완성도를 제공한다. 외산 소프트웨어가 장악하고 있는 국내 BTS 시장에서 국산 BTS OWL의 공개는 우리나라의 소프트웨어 품질관리 기술의 위상이 높아졌음을 보여주는 사례라 하겠다.

다음 컬럼에서는 개발자와 테스터의 공통점과 차이점에 대해 살펴 보겠다.

위로

주

^[1] 말: [명사] 사람의 생각이나 느낌 따위를 표현하고 전달하는 데 쓰는 음성 기호. 곧 사람의 생각이나 느낌 따위를 목구멍을 통하여 조직적으로 나타내는 소리를 가리킨다.
^[2] 대화(對話): [명사] 마주 대하여 이야기를 주고받음. 또는 그 이야기.
^[3] 커뮤니케이션: [명사]사람들끼리 서로 생각, 느낌 따위의 정보를 주고받는 일. 말이나 글, 그 밖의 소리, 표정, 몸짓 따위로 이루어진다.
^[4] wikipedia.org
^[5] Mantis
^[6] Bugzilla
^[7] Trac
^[8] Scarab
^[9] OWL