소프트웨어 버그 란 무엇입니까? 결함 관리 프로세스 학습

버그 란 무엇입니까?

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

결함이란 무엇입니까?

결함은 원래 비즈니스 요구 사항과의 차이나 편차입니다.

이 두 용어는 매우 희박한 차이를 가지고 있습니다. 업계에서는 고정되어 있어야하며 따라서 일부 테스트 팀 에서 상호 교환이 필요합니다 .

테스터가 테스트 케이스를 실행하면 예상 결과와 모순되는 테스트 결과를 보게 될 수 있습니다. 이 테스트 결과의 변형을 소프트웨어 결함 이라고 합니다. 이러한 결함이나 변형은 이슈, 문제, 버그 또는 인시던트 와 같이 다른 조직에서 다른 이름으로 참조됩니다 .

개발자에게 버그를보고하는 동안 버그 보고서에는 다음 정보가 포함되어야합니다.

• Defect_ID - 결함의 고유 식별 번호입니다.
• 결함 설명 - 결함이 발견 된 모듈에 대한 정보를 포함하여 결함에 대한 자세한 설명.
• Version - 결함이 발견 된 응용 프로그램의 버전입니다.
• 단계 - 개발자가 결함을 재현 할 수있는 스크린 샷과 함께 세부 단계입니다.
• Date Raised - 결함이 제기 된 날짜
• 참고 문헌 - 어디에서와 같은 문서에 대한 참조를 제공합니다. 요구 사항, 디자인, 아키텍처 또는 결함의 이해를 돕기위한 오류 스크린 샷
• Detected By - 결함을 제기 한 테스터의 이름 / ID입니다.
• 상태 - 결함 상태, 나중에 자세히 설명합니다.
• 수정 한 사람 - 수정 한 개발자의 이름 / ID
• 마감일 - 결함이 마감 된 날짜
• 심각도 - 응용 프로그램에 대한 결함의 영향을 설명하는 
• 우선 순위 - 결함 수정 긴급과 관련된 우선 순위 . 심각도 우선 순위는 결함을 고정해야하는 영향의 긴급도를 기준으로 높음 / 보통 / 낮음이 될 수 있습니다.

자원

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

DefectReportTemplate.doc

테스트 관리자로서 다음을 고려하십시오.

팀은 Guru99 Banking 프로젝트를 테스트하는 동안 버그를 발견했습니다.

일주일 후 개발자는 응답합니다.

다음 주에는 테스터가 응답합니다.

위의 경우와 마찬가지로, 결함 통신이 구두로 수행되면 곧 일이 매우 복잡해집니다. 버그를 제어하고 효과적으로 관리하려면 결함 수명주기가 필요합니다.

결함 관리 프로세스

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

발견

발견 단계에서 프로젝트 팀은 최종 고객이 발견하기 전에 가능한 많은 결함을 발견해야합니다. 결함이 발견 된 상태로 변경 될 수 있다고 인정 은 인정 개발자에 의해 허용되는 경우

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

.

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

이 경우, 시험 관리자로서 무엇을 할 것입니까?

 A) 동의 함 테스트 팀에서 결함

 B) Test Manager는 문제의 결함 여부를 판단하기 위해 판사 역할을 수행합니다.

 C) 결함이 아닌 개발 팀의 동의

이 경우 분쟁을 해결하기 위해 해결 절차를 적용해야하며 웹 사이트 문제가 결함인지 여부를 판사로 결정해야합니다.

분류(Categorization)

결함 분류는 소프트웨어 개발자가 작업의 우선 순위를 정하는 데 도움이됩니다. 즉, 이런 종류의 우선 순위는 개발자가 먼저 매우 중요한 결함을 수정하는 데 도움이됩니다.

결함은 대개 시험 관리자에 의해 분류됩니다 -

• 결정적인
• 높은
• 중간
• 낮은

1) 웹 사이트 성능이 너무 느립니다. (High)
2) 웹 사이트의 로그인 기능이 제대로 작동하지 않습니다. (Critical)
3) 웹 사이트의 GUI가 모바일 장치에 올바르게 표시되지 않습니다.(Medium)
4) 웹 사이트가 사용자 로그인 세션을 기억하지 못했습니다. (High)
5) 일부 링크가 작동하지 않습니다. (Low)

다음은 권장 답변입니다.

아니.	기술	우선 순위	설명
1	웹 사이트 실적이 너무 느립니다.	High	성능 버그로 인해 사용자에게 큰 불편을 초래할 수 있습니다.
2	웹 사이트의 로그인 기능이 제대로 작동하지 않습니다.	Critical	이 기능이 작동하지 않으면 로그인은 은행 웹 사이트의 주요 기능 중 하나입니다. 심각한 버그입니다.
삼	웹 사이트의 GUI가 모바일 장치에 올바르게 표시되지 않습니다.	Medium	결함은 스마트 폰을 사용하여 웹 사이트를 보는 사용자에게 영향을줍니다.
4	웹 사이트에서 사용자 로그인 세션을 기억할 수 없습니다.	High	사용자는 로그인 할 수는 있지만 더 이상 거래를 수행 할 수 없으므로 심각한 문제입니다.
5	일부 링크가 작동하지 않습니다.	Low	개발 담당자가 쉽게 수정할 수 있으며 사용자는 이러한 링크가 없어도 사이트에 계속 액세스 할 수 있습니다.

해결(Resolution)

결함이 수락되고 분류되면 다음 단계에 따라 결함을 수정할 수 있습니다.

• 과제(Assignment) : 개발자 또는 다른 기술자에게 수정하도록 할당 하고 상태를 응답으로 변경했습니다 .
• 수정 일정 : 개발자 측에서 이 단계를 담당합니다. 그들은 결함 우선 순위에 따라 이러한 결함을 수정하기위한 스케줄을 작성합니다.
• 결함 수정 : 개발 팀이 결함을 수정하는 동안 Test Manager는 결함 수정 프로세스를 위의 스케줄과 비교하여 추적합니다.
• 해결 방법보고 : 결함이 수정되었을 때 개발자의 해결 방법에 대한 보고서를 받으십시오.

확인(Verification)

개발 팀 이 결함을 수정 하고 보고 한 후에 테스트 팀 은 결함이 실제로 해결 되었는지 확인 합니다.

예를 들어 위의 시나리오에서 개발 팀이 이미 61 개의 결함을 수정했다고보고하면 팀은 이러한 결함이 실제로 수정되었는지 다시 테스트합니다.

폐쇄(Closure, Closed)

결함이 해결되고 검증되면 결함은 닫힌 상태로 변경됩니다 . 그렇지 않은 경우 결함을 다시 확인하기 위해 개발에 통지해야합니다.

보고(Reporting)

경영진은 결함 상태를 알 권리가 있습니다. 그들은이 프로젝트에서 당신을 지원하기 위해 결함 관리 프로세스를 이해해야합니다. 따라서 현재의 결함 상황을보고해야합니다.

중요한 결함 메트릭

위의 시나리오를 역행하십시오. 개발자 및 테스트 팀은보고 된 결함을 검토합니다. 그 토론의 결과는 다음과 같습니다.

 

테스트 실행의 품질을 측정하고 평가하는 방법은 무엇입니까?

이것은 모든 Test Manager가 알고 자하는 질문입니다. 다음과 같이 고려할 수있는 두 가지 매개 변수가 있습니다.

위의 시나리오에서 탈퇴 거부율 (DRR)은 20/84 = 0.238 (23.8 %)이라고 계산할 수 있습니다 .

또 다른 예로, Guru99 Bank 웹 사이트에 총 64 개의 결함 이 있다고 가정 하긴 했지만 테스트 팀은 44 개의 결함 만 감지 합니다. 즉 20 개의 결함이 누락되었습니다 . 따라서 결함 누출 율 (DLR)은 20/64 = 0.312 (31.2 %)입니다.

결론, 테스트 실행의 품질은 다음 두 매개 변수를 통해 평가됩니다.

DRR과 DLR의 값이 작을수록 테스트 실행의 품질이 좋습니다. 허용되는 비율 범위는 무엇입니까 ? 이 범위는 프로젝트 타겟에서 정의되고 받아 들여질 수 있거나 유사한 프로젝트의 메트릭을 참조 할 수 있습니다.

이 프로젝트에서 수용 가능한 비율의 권장 값은 5 ~ 10 %입니다. 이는 테스트 실행의 품질이 낮다는 것을 의미합니다. 이러한 비율을 줄이려면 다음과 같은 대책을 찾아야합니다.

• 회원의 테스트 기술을 향상시킵니다 .
• 실행 테스트, 특히 테스트 실행 결과를 검토하는 데 더 많은 시간 을 할애 하십시오.