결함 라이프 사이클(1)

버그 수명주기라고도 하는 결함 수명주기는 전체 수명에서 여러 상태를 포괄하는 결함의 주기입니다. 이것은 테스터에 의해 새로운 결함이 발견되는 즉시 시작되며 테스터가 결함을 닫아서 그것이 다시 복제되지 않을 것이라는 확신을 줄 때 끝납니다.

결함 워크 플로우 :
아래 그림과 같이 단순한 다이어그램을 사용하여 결함 수명주기의 실제 워크플로를 이해해야 합니다.

결함 상태 :
1) New : 이것은 결함 수명주기의 첫 번째 결함 상태입니다. 새로운 결함이 발견되면 '새'상태로 떨어지고 결함 수명주기의 나중 단계에서 이 결함에 대해 검증 및 테스트가 수행됩니다.

2) Assigned :이 단계에서는 새로 생성된 결함이 결함을 처리하기 위해 개발 팀에 지정됩니다. 이것은 프로젝트 책임자 또는 테스트 팀 관리자가 개발자에게 할당합니다.

3) Open : 개발자가 결함을 분석하는 과정을 시작하고 필요한 경우 결함을 수정합니다. 개발자가 결함이 적절하지 않다고 생각하면 특정 이유에 따라 아래의 네 가지 상태 (중복, 지연, 거부 또는 버그 없음)로 전송될 수 있습니다.

4) Fixed : 개발자가 필요한 변경 작업을 수행하여 결함 수정 작업을 완료하면 결함 상태를 '고정'으로 표시할 수 있습니다.

5) Pending Retest : 결함을 수정 한 후 개발자는 결함을 테스터에게 할당하여 결함을 다시 테스트하고 테스터가 결함을 다시 테스트할 때까지 결함 상태를 'Pending Retest'로 남깁니다.

6) Retest :이 시점에서 테스터는 결함 재검사 작업을 시작하여 요구 사항에 따라 결함이 개발자에 의해 정확하게 수정되었는지 여부를 확인합니다.

7) Reopen : 결함에 문제가 계속 발생하면 개발자에게 다시 할당되어 결함의 상태가 'Reopen'으로 변경됩니다.

8) Verified : 테스터가 재 테스트를 위해 개발자에게 배정된 후 결함에서 문제를 찾지 못하면 결함이 정확하게 고정된 경우 결함의 상태가 '검증됨'으로 지정됩니다.

9) Closed : 결함이 더 이상 존재하지 않으면 테스터는 결함 상태를 'Closed'로 변경합니다.

 

기타 :

Reject: 개발자가 결함을 진짜 결함으로 간주하지 않으면 개발자가 결함을 '거부'로 표시합니다.
Duplicate : 개발자가 다른 결함과 동일한 결함을 발견하거나 결함의 개념이 다른 결함과 일치하는 경우 개발자의 결함 상태가 '중복'으로 변경됩니다.
Deffered : 개발자가 결함이 매우 중요한 우선 순위가 아니라고 판단하고 다음 릴리스에서 수정될 수 있는 경우 결함 상태를 '지연됨'으로 변경할 수 있습니다.
Not a bug : 결함이 애플리케이션의 기능에 영향을 미치지 않으면 결함 상태가 '버그 아님'으로 변경됩니다.