소프트웨어 테스팅의 결함 관리 프로세스
결함관리 프로세스란?
결함 관리란 버그를 식별하고 수정하는 체계적인 프로세스입니다. 결함 관리 주기는 다음 단계로 구성됩니다. 1) 결함 발견, 2) 결함 분류, 3) 개발자에 의한 결함 수정, 4) 테스터에 의한 검증, 5) 결함 종결, 6) 프로젝트 종료 시 결함 보고서
이 항목에서는 Guru99 Bank 프로젝트 웹 사이트에 결함 관리 프로세스를 적용하는 방법을 안내합니다. 아래 단계에 따라 결함을 관리할 수 있습니다.
1단계) 발견
발견 단계에서 프로젝트 팀은 다음과 같이 발견해야 합니다. . 결함 가능한, 최종 고객이 발견하기 전에. 결함이 발견되어 상태가 변경된다고 합니다. 접수 개발자가 이를 인정하고 승인한 경우
위 시나리오에서 테스터는 Guru84 웹사이트에서 99개의 결함을 발견했습니다.
다음 시나리오를 살펴보겠습니다. 테스트 팀이 Guru99 Bank 웹사이트에서 몇 가지 문제를 발견했습니다. 그들은 이를 결함으로 간주하고 개발 팀에 보고했지만 충돌이 있습니다.
이런 경우 테스트 관리자로서 어떻게 하시겠습니까?
나) 테스트 매니저는 문제의 결함 여부를 판단하는 심사위원 역할을 맡는다.
다) 하자가 아닌 것은 개발팀의 의견에 동의한다.
이러한 경우 갈등을 해결하기 위한 해결 프로세스가 적용되어야 하며, 귀하는 웹사이트 문제가 결함인지 여부를 결정하는 판사 역할을 맡습니다.
2단계) 분류
결함 분류는 소프트웨어 개발자가 작업 우선순위를 정하는 데 도움이 됩니다. 이는 이러한 종류의 우선순위가 개발자가 매우 중요한 결함을 먼저 수정하는 데 도움이 된다는 것을 의미합니다.
결함은 일반적으로 테스트 관리자에 의해 분류됩니다.
다음과 같이 간단한 연습을 해보자
아래의 결함 우선순위를 드래그 앤 드롭하세요.1) 웹사이트 성능이 너무 느립니다. |
|
2) 홈페이지 로그인 기능이 제대로 작동하지 않습니다. |
|
3) 웹사이트의 GUI가 올바르게 표시되지 않습니다. 모바일 장치 |
|
4) 웹사이트가 사용자 로그인 세션을 기억하지 못합니다. |
|
5) 일부 링크가 작동하지 않습니다 |
|
추천 답변은 다음과 같습니다.
그렇지 않습니다. | 상품 설명 | 우선 | 설명 |
---|---|---|---|
1 |
웹사이트 성능이 너무 느립니다 |
높은 |
성능 버그는 사용자에게 큰 불편을 초래할 수 있습니다. |
2 |
홈페이지 로그인 기능이 제대로 작동하지 않습니다 |
결정적인 |
로그인은 뱅킹 웹사이트의 주요 기능 중 하나입니다. 이 기능이 작동하지 않으면 심각한 버그입니다. |
3 |
웹사이트의 GUI가 모바일 장치에서 올바르게 표시되지 않습니다. |
중급 |
이 결함은 스마트폰을 사용하여 웹사이트를 보는 사용자에게 영향을 미칩니다. |
4 |
웹사이트가 사용자 로그인 세션을 기억하지 못했습니다. |
높은 |
사용자가 로그인할 수는 있지만 더 이상 거래를 수행할 수 없기 때문에 이는 심각한 문제입니다. |
5 |
일부 링크가 작동하지 않습니다 |
낮은 |
이는 개발 담당자가 쉽게 해결할 수 있는 방법이며 사용자는 이러한 링크 없이도 사이트에 계속 액세스할 수 있습니다. |
3단계) 결함 해결
결함 해결 소프트웨어 테스팅은 결함을 수정하는 단계별 프로세스입니다. 결함 해결 프로세스는 개발자에게 결함을 할당하는 것으로 시작하고, 개발자는 우선 순위에 따라 결함이 수정되도록 예약한 다음, 결함이 수정되고, 마지막으로 개발자가 테스트 관리자에게 해결 보고서를 보냅니다. 이 프로세스는 결함을 쉽게 수정하고 추적하는 데 도움이 됩니다.
다음 단계에 따라 결함을 해결할 수 있습니다.
- 할당: 개발자 또는 기타 기술자에게 수정하도록 지정하고 상태를 다음으로 변경했습니다. 응답.
- 일정 수정: 이 단계는 개발자 측에서 담당합니다. 결함 우선순위에 따라 이러한 결함을 수정하기 위한 일정을 만듭니다.
- 결함을 수정하세요: 개발팀이 결함을 수정하는 동안 테스트 관리자는 위 일정과 비교하여 결함 수정 프로세스를 추적합니다.
- 해결 방법 보고: 결함이 수정되면 개발자로부터 해결 방법에 대한 보고서를 받습니다.
4단계) 검증
개발팀 이후 고정 and 신고 결함, 테스트 팀 확인 실제로 결함이 해결되었다는 것입니다.
예를 들어 위 시나리오에서 개발 팀이 이미 61개의 결함을 수정했다고 보고하면 팀에서는 이러한 결함이 실제로 수정되었는지 여부를 확인하기 위해 다시 테스트합니다.
5단계) 종료
결함이 해결되고 확인되면 결함 상태가 다음과 같이 변경됩니다. 닫은. 그렇지 않은 경우 개발팀에 통지를 보내 결함을 다시 확인하십시오.
6단계) 결함 보고
결함 보고 소프트웨어 테스팅에서 결함 관리 프로세스 및 결함 상태에 대한 피드백을 위해 테스트 관리자가 결함 보고서를 준비하고 관리 팀에 보내는 프로세스입니다. 그러면 관리팀에서 결함 신고 내용을 확인하고 피드백을 보내거나 필요한 경우 추가 지원을 제공합니다. 결함 보고는 결함을 더 잘 전달하고, 추적하고, 자세히 설명하는 데 도움이 됩니다.
경영진은 결함 상태를 알 권리가 있습니다. 이 프로젝트에서 귀하를 지원하려면 결함 관리 프로세스를 이해해야 합니다. 그러므로 현재의 결함 상황을 보고하여 피드백을 받아야 합니다.
결함관리 프로세스가 필요한 이유는 무엇입니까?
귀하의 팀은 Guru99 Banking 프로젝트를 테스트하는 동안 버그를 발견했습니다.
일주일 후 개발자가 응답합니다 –
다음 주에 테스터가 응답합니다.
위의 경우처럼, 결함에 대한 의사소통을 구두로 하면 곧 상황이 매우 복잡해집니다. 버그를 제어하고 효과적으로 관리하려면 결함 수명 주기가 필요합니다.
중요한 결함 지표
위의 시나리오를 되돌립니다. 개발자와 테스트 팀은 보고된 결함을 검토했습니다. 그 토론의 결과는 다음과 같습니다
테스트 실행 품질을 측정하고 평가하는 방법은 무엇입니까?
이것은 모든 사람이 묻는 질문이다. 테스트 관리자 알고 싶어합니다. 다음과 같이 고려할 수 있는 매개변수가 2개 있습니다.
위의 시나리오에서 다음을 계산할 수 있습니다. 탈북 거부율 (DRR)은 20/84 = 0.238(23.8%).
또 다른 예는 Guru99 Bank 웹사이트에 총 금액이 있다고 가정합니다. 64 결함이 있지만 테스트 팀은 감지만 합니다. 44 결함, 즉 놓친 것 20 결함. 따라서 결함 누출률(DLR)은 20/64 = 이라고 계산할 수 있습니다. 0.312 (31.2 %).
결론적으로 테스트 실행의 품질은 다음 두 가지 매개변수를 통해 평가됩니다.
DRR과 DLR의 값이 작을수록 테스트 실행 품질이 좋아집니다. 비율 범위는 무엇입니까? 허용? 이 범위는 프로젝트 대상에서 정의 및 허용될 수 있으며 유사한 프로젝트의 측정항목을 참조할 수도 있습니다.
이 프로젝트에서 권장되는 허용 비율 값은 다음과 같습니다. 5 ~ 10 %. 이는 테스트 실행 품질이 낮다는 것을 의미합니다. 다음과 같은 비율을 줄이기 위한 대책을 찾아야 합니다.
- 개선 회원의 테스트 기술.
- 시간을 좀더 보내다 테스트 실행, 특히 테스트 실행 결과를 검토하기 위해 사용됩니다.
자주 묻는 질문
LINK 비디오에 접근할 수 없는 경우