버그의 라이프사이클은 발견된 결함이 발견에서 종료까지 거치는 과정입니다. IT에서 버그의 라이프사이클은 결함 처리를 가속화하고 리스크를 최소화하며 작업의 투명성을 높이기 위해 형식화되었습니다.
문제 역사:
초기 버그 추적 시스템은 오류를 기록하는 것만 가능했습니다. 소프트웨어가 복잡해짐에 따라 결함 상태를 구조적으로 추적하고 모든 처리 단계를 설명하려는 요구가 생겼습니다.
문제:
형식적 단계가 없으면 결함이 잃어버리거나 "정체"되어 닫히지 않거나 수정되었음에도 그대로 남아 있을 수 있습니다. 또한, QA와 개발자 간에 누가 무엇을 해야 하는지에 대한 투명성이 부족해 오해가 발생할 수 있습니다.
해결책:
단계의 표준화(예: New, Open, Assign, In Progress, Fixed, Retest, Closed, Reopened) 및 각 단계에서의 행동 설명은 결함 처리 과정을 정리하고 투명하게 만드는 데 도움이 됩니다.
주요 특징:
테스터에게 재현되지만 프로그래머에게는 재현되지 않는 버그를 닫을 수 있나요?
아니요, 버그는 양측이 합의해야 하며 버그 리포트에 기록된 단계에 따라 재현되어야 합니다.
버그에 대한 답변이 'Won't Fix'로 오면 어떻게 해야 하나요?
QA는 거부 사유를 확인해야 합니다. 만약 사유가 타당하다면(낮은 중요성, 요구사항과의 일치) 코멘트와 함께 버그를 닫을 수 있습니다.
QA가 버그를 닫은 후 문제가 다시 발생하면 재생성해야 하나요?
아니요, 버그를 'Reopened' 상태로 변경하고 재현에 대한 새로운 세부 정보를 추가해야 합니다.
회사는 버그 로그의 기본 기능만 사용했습니다. 결함 수정 후 개발자는 이를 해결된 것으로 표시하고, 테스터는 재테스트를 수행하지 않아 버그가 릴리즈로 돌아왔습니다.
장점:
단점:
팀은 필수 재테스트와 릴리즈 전에 닫는 이유를 설명하는 표준 버그 라이프사이클을 도입했습니다.
장점:
단점: