defect management process
결함 관리 프로세스 소개 :
더 집중된 프로세스와 테스트는 시장에서 버그가 적은 소프트웨어를 허용합니다.
결함 예방 결함 수를 줄이는 데 훨씬 더 효율적이고 효과적이며 소프트웨어 프로세스의 초기 단계에서 발견 된 결함을 수정하는 데 매우 비용 효율적입니다. 대부분의 조직은 결함 발견 , 결함 제거 그리고 프로세스 개선 통칭하여 결함 관리 프로세스 .
리더 북이되는 방법
학습 내용 :
결함 관리 프로세스 (DMP)의 목표
이 프로세스의 다양한 목표는 다음과 같습니다.
- 결함 방지
- 조기 발견
- 영향 최소화
- 결함의 해결
- 프로세스 개선
결함 관리 프로세스를 살펴보기 전에 먼저 실제로 결함이나 버그는 무엇입니까?
결함 관리 수명주기
시스템이 실제 비즈니스 요구 사항과 다른 출력을 제공하는 경우 (예 : 실제 또는 원래 비즈니스 요구 사항에서 벗어난 경우) 시스템 / 소프트웨어에 결함이 있다고 말할 수 있습니다.
테스트 팀이 테스트 케이스를 실행하면 실제 테스트 결과가 예상 결과와 다른 상황이 발생합니다. 이 변형은 결함 .
기본적으로 소프트웨어 결함은 소프트웨어 요구 사항을 충족하지 않는 조건입니다. 결함은 시스템에서 예상치 못한 또는 잘못된 동작을 생성하는 오류 또는 결함입니다.
프로젝트를 적절하게 처리하려면 개발 및 릴리스 처리 방법을 알아야하지만 그와 함께 결함 처리 방법도 알아야합니다.
테스트 팀이 결함을 구두로보고하고 개발 팀이 결함의 상태를 구두로 업데이트하면 어떻게 될까요? 이러한 결함에는 실제로 수정되고 예상대로 작동하는 것과 같은 모든 결함이 포함되지만 수정되었지만 여전히 작동하지 않음, 거부, 연기되고 프로세스가 진행되기 때문에 프로세스가 더 복잡해질 것입니다.
위의 경우 결함이 많아지고 구두로 의사 소통이 이루어지면서 조만간 최악의 상황이 될 것이다. 결함을 효과적으로 제어하고 처리하려면 적절한 결함 수명주기가 필요합니다.
결함 수명주기는 프로세스가 균일하고 표준화되도록합니다. 결함은 라이프 사이클에서 다른 상태에 도달합니다. 결함이 발견되면 수명 동안 다양한 단계를 거치며 일반적으로 다음과 같이 알려져 있습니다. 결함 수명주기 .
일반적으로 결함 수명주기는 테스트 팀에서 결함을 발견하거나 제기 한 단계에서 시작하여 결함이 재현 불가능하거나 개발 팀에서 거부되지 않도록하여 종료 될 때 끝납니다. 결함이 발생하는 상태의 수는 프로젝트마다 다릅니다.
추가 읽기 :
노트 : 아래주기는 조직마다 약간 다릅니다.
아래의 결함 수명주기에는 가능한 모든 상태가 포함됩니다.
- 테스트 팀은 애플리케이션에서 결함을 발견 할 때마다 ''상태로 결함을 제기합니다. 새로운 ”.
- QA 리드가 새 결함을 검토하고 결함이 유효한 경우 결함 상태는 ' 열다 ”및 개발 팀에 할당 할 준비가되었습니다.
- QA 리드가 해당 개발자에게 결함을 할당하면 결함 상태가 ' 할당 됨 ”. 개발자는이 단계에서 결함을 분석하고 수정해야합니다.
- 개발자가 결함이 정품이 아니거나 유효하지 않다고 생각하면 개발자는 결함을 거부합니다. 결함 상태는 ' 거부 됨 ”및 테스트 팀에 다시 할당되었습니다.
- 기록 된 결함이 두 번 반복되거나보고 된 결함의 결과와 재현 단계가 비슷하면 하나의 결함 상태가 ' 복제 ”.
- 현재 릴리스에 특정 결함을 수정하기위한 몇 가지 문제 나 장애물이있는 경우 현재 릴리스가 아닌 향후 릴리스에서 결함이 처리 된 다음 ' 지연됨 ”또는“ 연기 됨 ”.
- 개발자가 테스트 팀의 '복제 단계'에 언급 된 단계에 따라 결함을 재현 할 수없는 경우 개발자는 결함을 ' 재현 불가” . 이 단계에서 테스트 팀은 개발자에게 자세한 재현 단계를 제공해야합니다.
- 개발자가 결함을 재현하기 위해 QA에서 제공 한 재현 단계에 대해 명확하지 않은 경우 개발자는 ' 추가 정보 필요 ”. 이 경우 테스트 팀은 개발 팀에 필요한 세부 정보를 제공해야합니다.
- 결함이 이미 알려져 있고 현재 프로덕션 환경에 존재하는 경우 결함은 ' 알려진 결함 ”.
- 개발자가 필요한 사항을 변경하면 결함이 ' 결정된 ”.
- 개발자는 이제 결함을 테스트 팀에 전달하여 확인하므로 개발자는 상태를 ' 재시험 준비 ”.
- 결함에 더 이상 문제가없고 제대로 확인되면 테스터는 결함을 ' 닫은 ”.
- 테스터가 결함을 발견 한 경우 다시 테스트하는 동안 결함이 여전히 재현 가능하거나 부분적으로 수정 된 경우 결함은 ' 재개 ”. 이제 개발자는이 결함을 다시 조사해야합니다.
잘 계획되고 제어 된 결함 수명주기는 릴리스 또는 모든 릴리스에서 발견 된 총 결함 수를 제공합니다. 이 표준화 된 프로세스는 코드 작성 방법, 테스트가 얼마나 적절하게 수행되었는지, 결함 또는 소프트웨어가 출시 된 방법 등에 대한 명확한 그림을 제공합니다. 이렇게하면 테스트에서 결함을 찾아 생산의 결함 수를 줄일 수 있습니다. 단계 자체.
결함 관리 프로세스
결함 관리 프로세스는 아래에 자세히 설명되어 있습니다.
# 1) 결함 방지 :
결함 예방 나중 단계에서 결함을 찾아 수정하는 대신 테스트 초기 단계에서 결함을 제거하는 가장 좋은 방법입니다. 이 방법은 테스트 초기 단계에서 발견 된 결함을 수정하는 데 필요한 비용이 매우 낮기 때문에 비용 효율적입니다.
그러나 모든 결함을 제거 할 수는 없지만 적어도 결함의 영향과 동일한 수정 비용을 최소화 할 수 있습니다.
결함 예방과 관련된 주요 단계는 다음과 같습니다.
- 중요한 위험 식별 : 테스트 중 또는 이후 단계에서 발생할 경우 더 많은 영향을 미칠 시스템의 중요한 위험을 식별합니다.
- 예상되는 영향 추정 : 각 중요 위험에 대해 위험이 실제로 발생하면 재정적 영향이 얼마나 될지 계산합니다.
- 예상되는 영향 최소화 : 모든 중요한 위험을 파악한 후에는 시스템에 해로울 수있는 가장 큰 위험을 감수하고 위험을 최소화하거나 제거하십시오. 제거 할 수없는 위험의 경우 발생 가능성과 재정적 영향을 줄입니다.
# 2) 제공 가능한 기준 :
산출물 (시스템, 제품 또는 문서)이 사전 정의 된 이정표에 도달하면 산출물이 기준이라고 말할 수 있습니다. 이 프로세스에서 제품 또는 결과물은 한 단계에서 다른 단계로 이동하고 결과물이 한 단계에서 다른 단계로 이동하면 시스템의 기존 결함도 다음 단계 또는 단계로 이월됩니다.
예를 들어, 코딩, 단위 테스트 및 시스템 테스트의 시나리오를 고려하십시오. 개발자가 코딩 및 단위 테스트를 수행하면 테스트 팀이 시스템 테스트를 수행합니다. 여기서 코딩과 단위 테스트는 하나의 이정표이고 시스템 테스트는 또 다른 이정표입니다.
따라서 단위 테스트 중에 개발자가 몇 가지 문제를 발견하면 이러한 문제가 마일스톤 기한을 충족하기 전에 식별되므로 결함으로 간주되지 않습니다. 코딩 및 단위 테스트가 완료되면 개발자가 시스템 테스트 용 코드를 넘겨 주면 코드가 다음과 같다고 말할 수 있습니다. '기준' 다음 이정표를 준비합니다. 여기서는 '시스템 테스트'입니다.
이제 테스트 중에 문제가 식별되면 이전 마일스톤 (예 : 코딩 및 단위 테스트)이 완료된 후 식별되므로 결함이라고합니다.
.eps 파일이란?
기본적으로 결과물의 변경 사항이 완료되고 가능한 모든 결함이 식별되고 수정 될 때 결과물이 기준이됩니다. 그런 다음 동일한 결과물이 작업 할 다음 그룹으로 전달됩니다.
# 3) 결함 발견 :
시스템에서 모든 결함을 제거하고 시스템을 결함없는 시스템으로 만드는 것은 거의 불가능합니다. 그러나 프로젝트에 비용이 많이 들기 전에 결함을 조기에 식별 할 수 있습니다. 발견 된 결함은 공식적으로 개발팀의주의를 끌었고, 분석 후에 결함 개발팀도 결함으로 받아 들였다는 것을 의미한다고 말할 수 있습니다.
결함 발견과 관련된 단계는 다음과 같습니다.
- 결함 찾기 : 시스템의 주요 문제가되기 전에 결함을 식별합니다.
- 결함보고 : 테스트 팀이 결함을 발견하자마자 그들의 책임은 분석 및 수정이 필요한 식별 된 문제가 있음을 개발 팀에 알리는 것입니다.
- 결함 확인 : 테스트 팀이 결함을 개발 팀에 할당하면 개발 팀은 결함을 인식하고 유효한 결함 인 경우 계속해서 수정해야 할 책임이 있습니다.
# 4) 결함 해결 :
위의 과정에서 테스트 팀은 결함을 확인하고 개발 팀에보고했습니다. 이제 여기에서 개발 팀은 결함 해결을 진행해야합니다.
결함 해결과 관련된 단계는 다음과 같습니다.
- 위험 우선 순위 지정 : 개발팀은 결함을 분석하고 결함 수정 우선 순위를 정합니다. 결함이 시스템에 더 많은 영향을 미치는 경우 결함 수정을 최우선으로합니다.
- 결함 수정 : 우선 순위에 따라 개발팀이 결함을 수정하고, 우선 순위가 높은 결함을 먼저 해결하고, 우선 순위가 낮은 결함을 마지막에 수정합니다.
- 해결 방법보고 : 테스트 팀이 결함이 수정 될 때와 결함이 어떻게 수정되었는지 (예 : 구성 파일 중 하나를 변경하거나 일부 코드를 변경하여) 인식하도록하는 것은 개발 팀의 책임입니다. 이것은 테스트 팀이 결함의 원인을 이해하는 데 도움이 될 것입니다.
# 5) 프로세스 개선 :
결함 해결 프로세스에서 결함의 우선 순위가 지정되고 수정되지만 프로세스 관점에서 우선 순위가 낮은 결함이 중요하지 않으며 시스템에 큰 영향을 미치지 않는다는 의미는 아닙니다. 프로세스 개선 관점에서 확인 된 모든 결함은 심각한 결함과 동일합니다.
이러한 사소한 결함조차도 프로세스를 개선하고 향후 시스템 장애에 영향을 미칠 수있는 결함 발생을 방지하는 방법을 배울 수있는 기회를 제공합니다. 시스템에 미치는 영향이 적은 결함을 식별하는 것은 큰 문제가 아닐 수 있지만 시스템 자체에서 이러한 결함이 발생하는 것은 큰 문제입니다.
프로세스 개선을 위해 프로젝트의 모든 사람은 결함이 발생한 위치를 되돌아보고 확인해야합니다. 이를 바탕으로 유효성 검사 프로세스, 기본 문서, 검토 프로세스를 변경하여 비용이 적게 드는 프로세스 초기에 결함을 포착 할 수 있습니다.
결론
결함 관리 프로세스는 특정 테스트 또는 개발 활동뿐만 아니라 전체 소프트웨어 개발 프로세스 중에 따라야합니다.
테스트 단계에서 결함이 발견되면이 단계에서 결함이 발견되면 시스템에 존재하는 다른 결함이 발생하고 아직 발견되지 않은 경우 시스템 오류를 일으킬 수있는 다른 결함은 어떻습니까?
따라서 검토 프로세스, 정적 테스트, 검사 등과 같은 모든 프로세스는 강화되어야하며 프로젝트의 모든 사람은 프로세스에 대해 진지하게 생각하고 필요한 곳에 기여해야합니다. 조직의 고위 경영진도 결함 관리 프로세스를 이해하고 지원해야합니다.
테스트 접근 방식, 검토 프로세스 등은 프로젝트 목표 또는 조직 프로세스에 따라 선택해야합니다.
결함 관리 프로세스에 대한이 유익한 기사가 여러분에게 큰 도움이되기를 바랍니다.