소프트웨어 테스팅의 결함 관리 프로세스

결함관리 프로세스란?

결함 관리란 버그를 식별하고 수정하는 체계적인 프로세스입니다. 결함 관리 주기는 다음 단계로 구성됩니다. 1) 결함 발견, 2) 결함 분류, 3) 개발자에 의한 결함 수정, 4) 테스터에 의한 검증, 5) 결함 종결, 6) 프로젝트 종료 시 결함 보고서

이 항목에서는 Guru99 Bank 프로젝트 웹 사이트에 결함 관리 프로세스를 적용하는 방법을 안내합니다. 아래 단계에 따라 결함을 관리할 수 있습니다.

불량관리 프로세스

1단계) 발견

발견 단계에서 프로젝트 팀은 다음과 같이 발견해야 합니다. . 결함 가능한, 최종 고객이 발견하기 전에. 결함이 발견되어 상태가 변경된다고 합니다. 접수 개발자가 이를 인정하고 승인한 경우

위 시나리오에서 테스터는 Guru84 웹사이트에서 99개의 결함을 발견했습니다.

발견

다음 시나리오를 살펴보겠습니다. 테스트 팀이 Guru99 Bank 웹사이트에서 몇 가지 문제를 발견했습니다. 그들은 이를 결함으로 간주하고 개발 팀에 보고했지만 충돌이 있습니다.

이런 경우 테스트 관리자로서 어떻게 하시겠습니까?

A) 결함이 있다는 테스트 팀의 의견에 동의합니다.

나) 테스트 매니저는 문제의 결함 여부를 판단하는 심사위원 역할을 맡는다.

다) 하자가 아닌 것은 개발팀의 의견에 동의한다.

옳은
잘못된

이러한 경우 갈등을 해결하기 위한 해결 프로세스가 적용되어야 하며, 귀하는 웹사이트 문제가 결함인지 여부를 결정하는 판사 역할을 맡습니다.

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 %. 이는 테스트 실행 품질이 낮다는 것을 의미합니다. 다음과 같은 비율을 줄이기 위한 대책을 찾아야 합니다.

  • 개선 회원의 테스트 기술.
  • 시간을 좀더 보내다 테스트 실행, 특히 테스트 실행 결과를 검토하기 위해 사용됩니다.

자주 묻는 질문

버그는 코딩 오류의 결과/결과입니다.

A 소프트웨어 테스팅의 결함 최종 사용자의 요구 사항이나 원래 비즈니스 요구 사항에서 소프트웨어 응용 프로그램의 변형 또는 편차입니다. 소프트웨어 결함은 실제 요구 사항을 충족하지 않는 소프트웨어 프로그램으로 인해 부정확하거나 예상치 못한 결과를 초래하는 코딩 오류입니다. 테스터는 테스트 사례를 실행하는 동안 이러한 결함을 발견할 수 있습니다.

이 두 용어는 매우 얇은 차이를 가지고 있습니다. 업계에서는 둘 다 수정이 필요한 결함이므로 일부에서는 같은 의미로 사용됩니다. 지원 팀.

테스터가 테스트 케이스를 실행할 때 예상 결과와 모순되는 테스트 결과가 나타날 수 있습니다. 테스트 결과의 이러한 변형을 소프트웨어 결함이라고 합니다. 이러한 결함이나 변형은 문제, 문제, 버그 또는 사건과 같이 여러 조직에서 다른 이름으로 참조됩니다.

소프트웨어 테스팅의 버그 보고서는 소프트웨어 응용 프로그램에서 발견된 버그에 대한 자세한 문서입니다. 버그 보고서에는 설명, 버그 발견 날짜, 버그를 발견한 테스터 이름, 수정한 개발자 이름 등과 같은 버그에 대한 각 세부 정보가 포함되어 있습니다. 버그 보고서는 향후 유사한 버그를 식별하여 방지할 수 있도록 도와줍니다.

  • 결함_ID – 결함에 대한 고유 식별 번호입니다.
  • 결함 Descript이온 – 결함이 발견된 모듈에 대한 정보를 포함하여 결함에 대한 자세한 설명입니다.
  • 버전 - 결함이 발견된 애플리케이션의 버전입니다.
  • 단계 – 개발자가 결함을 재현할 수 있는 스크린샷과 함께 자세한 단계가 제공됩니다.
  • 제기된 날짜 – 결함이 제기된 날짜
  • 참조- 결함을 이해하는 데 도움이 되도록 요구 사항, 설계, 아키텍처 또는 오류의 스크린샷과 같은 문서에 대한 참조를 제공합니다.
  • 탐지 대상 – 결함을 제기한 테스터의 이름/ID
  • 상태 - 결함의 상태, 나중에 자세히 설명하겠습니다.
  • –에 의해 수정됨 문제를 해결한 개발자의 이름/ID
  • 휴관일 – 결함이 종결된 날짜
  • 심각도 결함이 애플리케이션에 미치는 영향을 설명합니다.
  • 우선 이는 결함 수정 긴급성과 관련이 있습니다. 심각도 우선순위는 결함을 수정해야 하는 영향의 긴급성에 따라 높음/보통/낮음이 될 수 있습니다.

LINK 비디오에 접근할 수 없는 경우

자료 :

샘플 결함 보고 템플릿 다운로드