버그이야기
소프트웨어 또는 시스템 실행 중 기능이 정상적으로 동작하지 않을 때나 동작하지 않아야 함에도 동작하는 오류Error를 만날 때가 있습니다. 이런 오류를 버그Bug, 결함Defects 또는 이슈Issue라고 부릅니다. 이는 사용자 관점에서의 버그이고 제품을 만드는 개발 관점에서 버그는 소프트웨어나 시스템의 오작동의 원인이 되는 코드상 오류 외 다음과 같은 것들이 포함됩니다.
버그 종류
요구사항과 다르게 동작하거나 요구사항이 누락된 소프트웨어, 시스템
API, 네트워크, 하드웨어 문제로 발생하는 오류 또는 기대하지 않은 동작의 발생
해커의 공격, 어뷰징 등으로 발생한 보안 이슈
고객 요구사항, 기획 명세서, 개발 설계서 등 문서상 존재하는 결함
복잡한 코드, 아키텍처의 복잡도로 발생하는 문제
: 어떤 코드가 시스템에 무슨 영향을 미칠지 예측할 수 없을 정도로 관리가 어렵거나 구조와 기능 파악이 어려운 경우 그리고 수정, 개선, 최적화 등 유지보수가 어려운 코드나 아키텍처
운영체체, 시스템, 하드웨어 등 개발 환경 변경(예: 버전 업, 외부 물리적 요인 등 영향에 의한 변경 등)
유저 시나리오 사용성 문제
클라이언트, 서버, 데이터가 적절한 성능을 제공하지 못하는 문제
데이터가 조회되지 않거나 데이터의 누락, 내용 오류가 발생되는 문제
소프트웨어가 다양한 환경으로 이식되지 못하는 문제
시스템, 모듈 간 인터페이스가 안 되는 문제
이와 같은 다양한 원인으로 발생하는 결함은 장애의 원인이 될 수 있습니다.
테스터는 소프트웨어 테스트를 수행하며 발견된 문제를 결함으로 판단하여 지라JIRA와 같은 버그 관리 시스템에 내용을 기록하고 수정 → 완료 → 회귀 처리 상태를 추적합니다. 또한 프로젝트별, 제품별로 버그 데이터를 관리하고 이를 분석하여 재발을 방지하고 발생할 수 있는 문제를 예측하는 데 사용합니다.
버그 관리 시스템을 사용하는 이유
버그 관리 시스템 또는 이슈 트래킹 시스템이라고 불리는 프로그램은 버그의 발견부터 해결까지 프로젝트의 이슈를 추적하고 관리하는 시스템입니다. 버그 관리 시스템의 종류에는 지라JIRA, 레드마인REDMINE, 코드비머CodeBeamer, 맨티스Mantis 등이 있고 현재 IT업계에서 가장 많이 사용하고 있는 시스템은 아틀라시안 Atlassian 의 지라입니다.
버그를 등록하고 관리하는데 굳이 비용을 들여 별도의 시스템을 도입하는 이유가 무엇인가? 라고 질문한다면 그에 대한 대답은 다음과 같습니다. 바로 버그, 고객의 요구사항과 불만, 개선요청 하나하나가 모두 조직의 자산이기 때문입니다. 버그 관리 시스템으로 등록되고 관리되는 기록을 통해 관리자는 조직의 자산을 효과적으로 운영 할 수 있고, 후임자는 버그의 과거 히스토리를 통해 재발을 방지하기 위한 지식과 경험의 거름으로 사용 할 수 있습니다. 그리고 프로젝트에서는 각 구성원에게 할당된 업무와 역할, 프로젝트의 진행상황과 관련 정보를 버그 관리 시스템이라는 하나의 채널을 통해 빠르게 공유하고 소통할 수 있습니다.
버그 관리 시스템이 필요한 보다 구체적인 이유를 살펴보면 아래와 같습니다.
이슈 보고 내용과 보고 체계의 일관성과 표준화를 통한 명확한 커뮤니케이션이 가능하다.
버그 발견에서 해결까지 형상 관리 도구의 개정 버전별로 버그 처리 과정을 구체화할 수 있고 진행 상황을 쉽게 추적할 수 있다.
버그 데이터를 관리하고 분석하여 재발을 예방하고 발생할 수 있는 문제를 예측할 수 있다.
프로젝트별, 제품별, 담당자별, 이슈 유형별, 버그 중요도별 등 유용한 버그 통계 자료를 제공한다.
버그 증가율, 수정률 등 버그 통계를 분석하여 프로젝트와 제품의 품질 상태를 측정하고 품질을 제어할 수 있으며 병목되는 컴포넌트 또는 담당자를 확인하여 문제를 빠르게 해결할 수 있다.
테스트 조직, 개발 조직의 성과 지표KPI, Key Performance Indicator로 사용할 수 있다. 예를 들어, 발견 버그 수 대비 유효 버그율, 오픈 후 장애 발생 수, 장애/결함 예방 활동 수행, 프로젝트별 결함 발생 수준, 사이드 이펙트 발생 또는 재등록율로 회귀 버그 발생률 확인 등을 지표로 사용할 수 있다.
프로젝트 일정 관리, 고객 요구사항 관리(예: 고객의 요청사항을 실시간 접수하고 일원화하여 관리), 배포Release 관리를 할 수 있다.
버그 생명주기
버그 생명주기는 결함 또는 버그가 식별되어 등록된 시점부터 수정까지 다양한 단계를 통과하는 방법을 정의하는 순환 절차를 나타내는 것입니다. 즉, 테스터가 버그를 기록할 때 시작되고 버그가 수정되면 완료되는 과정을 추적하는 절차입니다. 결함 생명주기 동안 버그나 작업 흐름은 대표적으로 네 가지 상태로 구성됩니다.
등록(New/Open/Reopen)
New와 Open은 신규로 발견한 버그를 등록한 상태이고 Reopen은 이전에 등록하고 수정한 버그가 다시 재현된 경우의 상태입니다. 버그 등록 시 해당 버그를 처리할 담당자를 지정하고 지정된 담당자가 이슈를 수락하면 Assigned로 상태가 변경됩니다.
진행 중인 작업(Work in Progress)
이슈의 담당자가 내용 확인 후 작업이 시작되면 In Progress 상태로 변경됩니다.
해결(Resolved)
이슈 처리 작업이 완료된 상태입니다. 해결 방안은 총 7가지로 구성되어 있습니다.
- 수정 Fixed: 등록된 버그가 실제 오류로 판명되었고 수정이 완료된 상태
- 중복된 버그 Duplicated: 이미 등록된 결함 중에 동일한 결함이 있는 경우
- 의도됨 As Designed: 문서에 명세 되어있지 않으나 기획/개발에서 의도한 대로 동작하는 경우
- 재현안됨 Cannot reproduce: 이슈가 재현되지 않는 경우
- 수정 보류 Postpone: 수정을 보류하거나 차후로 연기하는 경우
- 버그 아님 Not a Bug: 등록된 버그를 결함으로 볼 수 없는 경우
- 수정 안함 Won’t fix: 버그나 개선이 필요한 상황은 맞지만 수정하지 함기로 한 결함
완료 또는 종료 상태(Closed /Done)
해결된 결함에 대해 테스터의 수정 확인이 완료된 상태입니다.
결함 생명주기 단계
버그 리포팅 작성 방법
버그를 발견하고 보고하는 것은 테스트 업무 흐름 중 중요한 활동에 해당됩니다. 발견된 버그는 정확한 정보와 내용이 작성된 상태로 개발자 또는 관련자에게 전달되어야 합니다. 버그 리포팅을 잘 작성하는 것은 모든 테스터가 가져 할 업무 수행 능력에 해당됩니다.
버그를 등록할 때 버그 판단이 잘못되거나 정확한 내용으로 기술하지 않으면 버그를 찾는 데 시간만 소모하고 수정하지 못하는 비생산적인 활동만 발생하게 됩니다. 잘못 작성된 버그 리포트의 가장 큰 문제점은 다시 재현할 수 없다는 것이며 이는 테스트 방법의 차이, 개발·테스트 환경 차이, 테스트 수행 절차의 잘못된 기술로 인해 발생합니다.
버그 판단의 오류를 줄이기위해 확인된 버그에 대한 검증은 테스터가 2~3회 재검사를 수행하고 확신이 서면 내용을 작성합니다. 버그로 판명될 경우 하나의 환경에서만 발생하는 버그인지 여러 환경에서 재현해보고 환경적 특이사항을 기술합니다. 또 발생한 버그의 이전 히스토리를 확인해서 회귀 버그 여부 또는 이슈 수정에 의해 새롭게 발생한 사이드 이펙트Side Effect에 해당되는지 확인하여 기록해서 이슈 수정 담당자의 작업 과정 중 유의할 부분에 대해 내용을 전달하도록 합니다.
버그 리포팅은 버그 내용과 이를 재현하는 과정을 명확하고 간결하며 사실적으로 기술하고 불필요한 절차를 줄이고 공격이나 비난 등 오해할 수 있는 모호한 표현을 사용하지 않도록 주의하며 디버깅을 위한 필요한 정보를 제공해줘야 합니다.
버그 리포팅을 구성하는 방법과 이를 반영하여 작성한 버그 리포트 예시는 다음과 같습니다.
결함 보고서 내용 입력 가이드
결함 우선순위, 중요도