what is defect bug life cycle software testing
결함 수명주기 소개
이 튜토리얼에서는 테스트 환경에서 작업하는 동안 테스터가 처리해야하는 다양한 단계의 결함을 인식 할 수 있도록 결함의 수명주기에 대해 설명합니다.
또한 결함 수명주기에 대해 가장 자주 묻는 인터뷰 질문을 추가했습니다. 이것은 결함의 수명주기를 이해하기 위해 결함의 다양한 상태를 아는 것이 중요합니다. 테스트 활동을 수행하는 주된 목적은 제품에 문제 / 오류가 있는지 확인하는 것입니다.
실제 시나리오에서 오류 / 실수 / 결함은 모두 버그 / 결함이라고하므로 테스트를 수행하는 주된 목적은 제품에 결함이 발생하지 않도록하는 것입니다 (결함이없는 것은 비현실적인 상황입니다). ).
이제 결함이 무엇인지에 대한 질문이 생깁니다.
학습 내용 :
결함이란 무엇입니까?
간단히 말해서 결함은 애플리케이션의 예상 동작을 실제 동작과 일치하지 않아 애플리케이션의 정상적인 흐름을 제한하는 애플리케이션의 결함 또는 오류입니다.
이 결함은 개발자가 애플리케이션을 설계하거나 구축하는 동안 실수를했을 때 발생하며 테스터가이 결함을 발견하면 결함이라고합니다.
고품질 제품이 고객에게 전달 될 수 있도록 최대한 많은 결함을 찾기 위해 애플리케이션을 철저히 테스트하는 것은 테스터의 책임입니다.
워크 플로로 이동하기 전에 결함 수명주기와 다양한 결함 상태를 이해하는 것이 중요합니다.
따라서 결함 수명주기에 대해 자세히 알아 보겠습니다.
지금까지 결함의 의미와 테스트 활동과의 관계에 대해 논의했습니다. 이제 결함 수명 주기로 이동하여 결함의 워크 플로와 다양한 결함 상태를 이해하겠습니다.
상세한 결함 수명주기
버그 수명주기라고도하는 결함 수명주기는 전체 수명의 여러 상태를 포함하는 결함의주기입니다. 이는 테스터가 새로운 결함을 발견하자마자 시작되고 테스터가 해당 결함을 닫아 다시 재현되지 않도록 보장 할 때 종료됩니다.
결함 워크 플로
이제 아래와 같이 간단한 다이어그램을 통해 결함 라이프 사이클의 실제 워크 플로를 이해할 때입니다.
결함 상태
# 1) 새로운 :이것은 결함 라이프 사이클에서 결함의 첫 번째 상태입니다. 새로운 결함이 발견되면 '신규'상태가되며 결함 수명주기의 후반 단계에서이 결함에 대한 검증 및 테스트가 수행됩니다.
# 2) 할당 됨 : 이 단계에서는 새로 생성 된 결함이 결함 작업을 위해 개발 팀에 할당됩니다. 이것은 프로젝트 리더 또는 테스트 팀의 관리자가 개발자에게 할당합니다.
# 3) 열기 : 여기에서 개발자는 결함 분석 프로세스를 시작하고 필요한 경우 수정 작업을합니다. 개발자가 결함이 적절하지 않다고 생각하면 아래 네 가지 상태 중 하나로 이전 될 수 있습니다. 중복, 지연, 거부 또는 버그 아님 -특정 이유에 따라.
이 네 가지 상태에 대해 잠시 후에 논의하겠습니다.
# 4) 고정 : 개발자가 필요한 변경 사항을 적용하여 결함 수정 작업을 완료하면 결함 상태를 '수정 됨'으로 표시 할 수 있습니다.
# 5) 보류중인 재 테스트 : 결함을 수정 한 후 개발자는 결함을 테스터에게 할당하여 마지막에 결함을 다시 테스트하고 테스터가 결함을 다시 테스트 할 때까지 결함 상태는 'Pending Retest'로 유지됩니다.
# 6) 재시험 : 이 시점에서 테스터는 결함을 재 테스트하는 작업을 시작하여 요구 사항에 따라 개발자가 결함을 정확하게 수정했는지 확인합니다.
# 7) 재 개설 : 결함에서 문제가 지속되면 테스트를 위해 개발자에게 다시 할당되고 결함 상태가 '다시 열기'로 변경됩니다.
# 8) 확인 : 테스터가 재 테스트를 위해 개발자에게 배정 된 후에도 결함에서 문제를 발견하지 못하고 결함이 정확하게 수정 되었다면 결함의 상태가 '검증 됨'으로 지정된다고 느낍니다.
# 9) 휴무 : 결함이 더 이상 존재하지 않으면 테스터는 결함 상태를 '종료 됨'으로 변경합니다.
몇 가지 더 :
- 거부 됨 : 개발자가 결함을 진짜 결함으로 간주하지 않으면 개발자가 '거부 됨'으로 표시합니다.
- 복제: 개발자가 다른 결함과 동일한 결함을 발견하거나 결함의 개념이 다른 결함과 일치하는 경우 개발자에 의해 결함 상태가 '중복'으로 변경됩니다.
- 연기 됨 : 개발자가 결함의 우선 순위가 그다지 중요하지 않고 다음 릴리스 등에서 수정 될 수 있다고 생각하면 결함 상태를 '지연됨'으로 변경할 수 있습니다.
- 버그 아님 : 결함이 애플리케이션의 기능에 영향을주지 않으면 결함 상태가 '버그가 아님'으로 변경됩니다.
그만큼 필수 필드 테스터가 새로운 버그를 기록 할 때 빌드 버전, 제출 위치, 제품, 모듈, 심각도, 요약 및 재현 설명
위 목록에서 몇 가지를 추가 할 수 있습니다. 선택적 필드 수동 버그 제출 템플릿을 사용하는 경우. 이러한 선택적 필드에는 고객 이름, 브라우저, 운영 체제, 파일 첨부 또는 스크린 샷이 포함됩니다.
다음 필드는 지정되거나 비어 있습니다.
버그 상태, 우선 순위 및 '할당 대상'필드를 추가 할 권한이있는 경우 이러한 필드를 지정할 수 있습니다. 그렇지 않으면 테스트 관리자가 상태, 버그 우선 순위를 설정하고 각 모듈 소유자에게 버그를 할당합니다.
다음 결함주기를 확인하십시오.
위의 이미지는 매우 상세하며 버그 라이프 사이클의 중요한 단계를 고려할 때 이에 대한 빠른 아이디어를 얻을 수 있습니다.
로깅이 성공하면 개발 또는 테스트 관리자가 버그를 검토합니다. 테스트 관리자는 버그 상태를 Open으로 설정하거나 개발자에게 버그를 할당하거나 다음 릴리스까지 버그를 연기 할 수 있습니다.
개발자에게 버그가 할당되어 작업을 시작할 수있는 경우. 개발자는 버그 상태를 수정하지 않음, 재현 할 수 없음, 추가 정보 필요 또는 '수정 됨'으로 설정할 수 있습니다.
개발자가 설정 한 버그 상태가 'Need more info'또는 Fixed 인 경우 QA는 특정 작업으로 응답합니다. 버그가 수정되면 QA에서 버그를 확인하고 버그 상태를 확인 된 종료 또는 다시 열기로 설정할 수 있습니다.
결함 수명주기 구현 지침
결함 수명주기 작업을 시작하기 전에 몇 가지 중요한 지침을 채택 할 수 있습니다.
다음과 같습니다.
- 결함 라이프 사이클에 대한 작업을 시작하기 전에 전체 팀이 결함의 여러 상태를 명확하게 이해하는 것이 매우 중요합니다 (위에서 논의 됨).
- 향후 혼동을 피하기 위해 결함 수명주기를 적절하게 문서화해야합니다.
- 결함 수명주기와 관련된 작업을 할당받은 각 개인은 더 나은 결과에 대한 자신의 책임을 명확하게 이해해야합니다.
- 결함의 상태를 변경하는 각 개인은 해당 상태를 적절하게 알고 있어야하며 특정 결함에 대해 작업하는 모든 사람이 해당 상태의 원인을 이해할 수 있도록 상태 및 해당 상태를 설정하는 이유에 대한 충분한 세부 정보를 제공해야합니다. 아주 쉽게 결함의.
- 결함 추적 도구는 결함 간의 일관성을 유지하기 위해주의해서 다루어야합니다. 따라서 결함 라이프 사이클의 워크 플로에서도 마찬가지입니다.
다음으로 결함 수명주기를 기반으로 한 인터뷰 질문에 대해 논의 해 보겠습니다.
버그 수명주기에 대한 중요한 FAQ 또는 인터뷰 질문
Q # 1) 소프트웨어 테스팅 관점에서 결함은 무엇입니까?
대답: 결함은 애플리케이션의 예상 동작을 실제 동작과 일치하지 않아 애플리케이션의 정상적인 흐름을 제한하는 애플리케이션의 모든 종류의 결함 또는 오류입니다.
Q # 2) 오류, 결함, 실패의 주요 차이점은 무엇입니까?
답변 : 오류 : 개발자가 개발 단계에서 응용 프로그램의 실제 동작과 예상 동작에 불일치가 있음을 발견하면이를 오류라고합니다.
결함: 테스터가 테스트 단계에서 애플리케이션의 실제 및 예상 동작에서 불일치를 발견하면이를 결함이라고합니다.
실패: 고객 또는 최종 사용자가 프로덕션 단계에서 애플리케이션의 실제 및 예상 동작에서 불일치를 발견하면이를 실패라고합니다.
Q # 3) 결함이 처음 발견되었을 때의 상태는 무엇입니까?
대답: 새로운 결함이 발견되면 'New'상태입니다. 새로 발견 된 결함의 초기 상태입니다.
Q # 4) 개발자가 결함을 승인하고 수정했을 때 결함 수명주기에서 결함의 다른 상태는 무엇입니까?
대답: 이 경우 결함의 다른 상태는 신규, 할당 됨, 열림, 수정 됨, 재 테스트 보류, 다시 테스트, 확인 됨 및 닫힘입니다.
여러 YouTube 비디오를 mp3로 변환
Q # 5) 테스터가 개발자가 수정 한 결함에서 여전히 문제를 발견하면 어떻게됩니까?
대답: 테스터는 수정 된 결함에서 여전히 문제를 발견하고 결함이 재 테스트를 위해 개발자에게 할당되면 결함의 상태를 '재 개설'로 표시 할 수 있습니다.
Q # 6) 생산 가능한 결함은 무엇입니까?
대답: 모든 실행에서 반복적으로 발생하고 모든 실행에서 단계를 캡처 할 수있는 결함을 '생산 가능한'결함이라고합니다.
Q # 7) 재현 불가능한 결함은 어떤 유형입니까?
대답: 모든 실행에서 반복적으로 발생하지 않고 일부 인스턴스에서만 생성되고 증거로서 단계를 스크린 샷의 도움으로 캡처해야하는 결함을 '재현 할 수 없음'결함이라고합니다.
Q # 8) 결함 보고서 란 무엇입니까?
대답: 결함 보고서는 애플리케이션의 정상적인 흐름이 예상되는 동작에서 벗어나는 원인이되는 애플리케이션의 결함 또는 결함에 대한보고 정보를 포함하는 문서입니다.
Q # 9) 결함 보고서에는 어떤 세부 정보가 포함됩니까?
대답: 결함 보고서는 다음 세부 정보로 구성됩니다.
결함 ID, 결함 설명, 기능 이름, 테스트 케이스 이름, 재현 가능한 결함 여부, 결함 상태, 심각도 및 결함 우선 순위, 테스터 이름, 결함 테스트 날짜, 결함이 발견 된 빌드 버전 .
그리고 결함이 할당 된 개발자, 결함을 수정 한 사람의 이름, 단계의 흐름을 나타내는 결함의 스크린 샷, 결함 날짜 수정, 결함을 승인 한 사람.
Q # 10) 결함 수명주기에서 결함이 '지연'상태로 변경되는시기는 언제입니까?
대답: 발견 된 결함이 그다지 중요하지 않고 이후 릴리스에서 수정 될 수있는 결함이 결함 라이프 사이클에서 '지연'상태로 이동하는 경우입니다.
결함 또는 버그에 대한 추가 정보
- 소프트웨어 개발 라이프 사이클의 어느 시점에서나 결함이 발생할 수 있습니다.
- 결함이 발견되고 제거되기 전에 전체 품질 비용이 낮아집니다.
- 결함이 도입 된 동일한 단계에서 결함을 제거하면 품질 비용이 최소화됩니다.
- 정적 테스트는 실패가 아니라 결함을 찾습니다. 디버깅이 필요하지 않으므로 비용이 최소화됩니다.
- 동적 테스트에서는 오류가 발생하면 결함의 존재가 드러납니다.
결함 상태
| S. 아니. | 초기 상태 | 반환 된 상태 | 확인 상태 |
|---|---|---|---|
| 1 | 결함 재현 책임자를위한 정보 수집 | 결함이 거부되거나 추가 정보를 요청 함 | 결함이 수정되었으며 테스트 및 종료되어야합니다. |
| 두 | 주가 열려 있거나 새롭습니다 | 상태는 거부되거나 설명됩니다. | 상태가 해결되고 확인됩니다. |
유효하지 않은 중복 결함 보고서
- 때때로 코드가 아닌 테스트 환경이나 오해로 인해 결함이 발생하는 경우 이러한 보고서는 잘못된 결함으로 마감되어야합니다.
- 중복 신고의 경우 1 개는 보관되고 1 개는 중복으로 마감됩니다. 관리자가 일부 잘못된 보고서를 수락했습니다.
- 테스트 관리자는 전체 결함 관리 및 프로세스를 소유하고 결함 관리 도구 교차 기능 팀은 일반적으로 보고서 관리를 담당합니다.
- 참가자에는 테스트 관리자, 개발자, PM, 프로덕션 관리자 및 관심이있는 기타 이해 관계자가 포함됩니다.
- 결함 관리위원회는 각 결함의 유효성을 결정하고 수정 또는 연기시기를 결정해야합니다. 이를 확인하려면 결함을 수정하지 않는 데 따른 비용, 위험 및 이점을 고려하십시오.
- 결함을 수정해야하는 경우 우선 순위를 결정해야합니다.
결함 데이터
- 사람의 이름.
- 테스트 유형
- 문제 요약
- 결함에 대한 자세한 설명.
- 재현 단계
- 라이프 사이클 단계
- 결함이 도입 된 작업 제품.
- 심각도 및 우선 순위
- 결함이 도입 된 하위 시스템 또는 구성 요소입니다.
- 결함이 도입 될 때 발생하는 프로젝트 활동.
- 식별 방법
- 결함 유형
- 문제가있는 프로젝트 및 제품
- 현재 소유자
- 신고 현황
- 결함이 발생한 작업 제품.
- 프로젝트에 미치는 영향
- 결함을 수정하거나 수정하지 않는 것과 관련된 위험, 손실, 기회 및 이점.
- 다양한 결함 수명주기 단계가 발생하는 날짜입니다.
- 결함이 해결 된 방법에 대한 설명과 테스트 권장 사항입니다.
- 참고 문헌
공정 능력
- 소개, 감지 및 제거 정보-> 결함 감지 및 품질 비용 개선.
- Introduction-> 총 결함 수를 줄이기 위해 가장 많은 수의 결함이 도입 된 프로세스의 Praetor 분석.
- 결함 루트 정보-> 총 결함 수를 줄이기 위해 결함의 원인에 밑줄을 긋습니다.
- 결함 구성 요소 정보-> 결함 클러스터 분석을 수행합니다.
결론
이것은 결함 라이프 사이클 및 관리에 관한 것입니다.
결함의 수명주기에 대해 엄청난 지식을 얻었을 것입니다. 이 자습서는 나중에 쉽게 결함을 처리하는 동안 도움이 될 것입니다.
추천 도서
- 결함 기반 테스트 기술이란 무엇입니까?
- 소프트웨어 테스트 수명주기 (STLC) 란 무엇입니까?
- Bugzilla 튜토리얼 : 결함 관리 도구 실습 튜토리얼
- 메소드 및 라이프 사이클이있는 Java 스레드
- 소프트웨어 테스팅은 아이디어에 관한 모든 것 (그리고 아이디어를 생성하는 방법)
- 초보자를위한 심층 이클립스 튜토리얼
- 결함 관리 프로세스 : 효과적으로 결함을 관리하는 방법
- 웹 및 제품 응용 프로그램에 대한 샘플 버그 보고서