이전 글에서 우리는 개발자가 고마워하는 완벽한 버그 리포트 작성법을 알아봤습니다. 그렇다면 우리가 정성껏 작성한 버그 리포트는 JIRA와 같은 시스템에 등록된 이후 어떤 여정을 거치게 될까요? 그냥 ‘해결될 때까지 대기’하는 걸까요?
결함 생명주기란 무엇인가?
결함 생명주기는 버그가 처음 보고된 후부터 최종적으로 처리될 때까지 거치는 여러 ‘상태(Status)’의 흐름을 정의한 프로세스입니다.
이는 택배 배송 과정과 비슷합니다. ‘집화 처리’, ‘터미널 간선상차’, ‘배달 중’, ‘배달 완료’처럼, 버그도 명확한 상태 값을 가지며 개발팀과 QA팀 사이를 오고 갑니다. 이를 통해 우리는 버그가 현재 누구의 손에 있으며 어떤 조치가 필요한지 명확히 알 수 있고, 보고된 버그가 누락되는 것을 방지할 수 있습니다.
버그의 일생: 대표적인 상태(Status) 알아보기
결함의 상태 이름은 회사나 팀의 정책에 따라 조금씩 다를 수 있지만, 일반적으로 다음과 같은 흐름을 따릅니다.
1. 신규 (New)
QA 엔지니어가 처음 버그를 발견하고 시스템에 등록한 상태입니다. 버그가 막 태어난 순간이죠. 이 상태의 버그는 아직 아무에게도 할당되지 않았으며, 내용 검토를 기다리고 있습니다.
2. 할당 (Assigned 또는 Open)
개발 리더나 프로젝트 매니저(PM)가 ‘신규’ 상태의 버그를 검토하고, 유효한 결함이라고 판단하면 담당 개발자에게 배정합니다. 이제 이 버그는 공식적으로 주인이 생겼으며, 개발자의 작업 목록에 추가됩니다.
3. 수정 중 (In Progress 또는 Fixed)
담당 개발자가 버그의 원인을 분석하고 코드를 수정하는 작업을 진행 중인 상태입니다. 개발자가 수정을 완료하면, 보통 ‘Fixed’ 또는 ‘Resolved(해결됨)’ 상태로 변경합니다. 이는 ‘내 컴퓨터에서는 일단 고쳤으니, QA가 테스트할 수 있도록 테스트 서버에 곧 반영하겠다’는 신호입니다.
4. 재테스트 (Ready for QA 또는 In Test)
개발자가 수정한 코드가 테스트 서버에 반영(배포)되어, QA가 수정 여부를 다시 확인할 수 있게 된 상태입니다. 이제 공은 다시 QA에게 넘어왔습니다.
5. 종료 (Closed)
가장 이상적인 마무리입니다. QA가 ‘재테스트’ 상태의 버그를 다시 확인해보니, 문제가 완벽하게 해결된 것을 확인했습니다. QA는 이 버그를 ‘종료’ 상태로 변경하며, 이 버그의 기나긴 여정은 행복하게 마무리됩니다.
6. 재오픈 (Reopened)
안타까운 경우입니다. QA가 재테스트를 해보니 문제가 여전히 발생하거나, 수정한 부분 때문에 또 다른 문제(사이드 이펙트)가 발생했습니다. 이때 QA는 버그를 ‘재오픈’ 상태로 변경하고, 왜 다시 열었는지에 대한 코멘트를 추가합니다. 재오픈된 버그는 보통 ‘할당(Assigned)’ 상태로 돌아가 개발자에게 다시 전달됩니다.
그 외의 상태들
- 보류 (Deferred 또는 On Hold): 버그인 것은 맞지만, 심각도가 낮거나 수정에 너무 많은 노력이 들어 이번 버전에서는 수정하지 않기로 결정된 상태입니다. 다음 릴리즈나 추후에 수정하기 위해 잠시 보류해 둡니다.
- 거절 (Rejected 또는 Invalid): 검토 결과, 보고된 내용이 버그가 아니라고 판단될 때 사용됩니다. 이는 기획 의도에 맞는 정상 동작이거나, 이미 보고된 중복 버그이거나, 테스트 환경의 문제일 수 있습니다.
결론: 상태의 흐름을 이해하는 것이 소통의 시작이다
결함 생명주기는 팀원 모두가 버그의 현재 위치와 책임자를 명확히 알게 해주는 약속이자 소통의 프레임워크입니다.
QA 엔지니어는 이 흐름을 이해함으로써, 단순히 버그를 보고하는 것을 넘어 자신이 보고한 버그가 잘 처리되고 있는지 지능적으로 추적할 수 있습니다. 또한 “이 버그는 왜 아직도 ‘Fixed’ 상태인가요? ‘Ready for QA’로 언제쯤 변경될까요?”와 같이 개발자와 명확한 상태를 기반으로 소통하며 프로젝트의 전체 품질 현황을 관리하는 데 기여할 수 있습니다.