소프트웨어 테스팅의 결함 관리 프로세스
토마스 해밀턴
⚡ 스마트 요약
소프트웨어 테스트에서의 결함 관리 프로세스는 버그를 식별, 분류, 해결, 검증, 종료 및 보고하는 데 사용되는 구조화된 프레임워크입니다. 이를 통해 테스터와 개발자 간의 예측 가능한 의사소통이 가능해지고, 릴리스 품질이 향상되며, 프로젝트 수명 주기 전반에 걸쳐 프로덕션 단계에서의 결함 발생률을 줄일 수 있습니다.
결함관리 프로세스란?
The 불량관리 프로세스 소프트웨어 테스트에서 버그를 식별, 분류, 수정 및 검증하는 체계적인 접근 방식입니다. 이 수명주기는 6가지 핵심 단계로 구성됩니다. 1) 결함 발견, 2) 분류, 3) 개발자에 의한 해결, 4) 테스터에 의한 검증, 5) 종료, 6) 프로젝트 종료 시 결함 보고입니다.
이 글에서는 결함 관리 프로세스를 적용하는 방법을 설명합니다. Guru99뱅크 웹사이트 예시를 통해 초보자 및 중급 테스터가 실제 프로젝트 환경에서 각 단계를 이해할 수 있도록 했습니다.
결함관리 프로세스가 필요한 이유는 무엇입니까?
팀에서 테스트 중에 여러 버그를 발견했다고 상상해 보세요. Guru99번 은행 프로젝트. 체계적인 프로세스가 없으면 테스터와 개발자 간의 의사소통은 구두로 이루어지거나 단편적인 메시지를 통해 진행됩니다.
일주일 후, 개발자는 문제에 대한 다른 이해를 바탕으로 답변을 보냈습니다.
다음 주에 테스터가 다시 답장을 보내면서 혼란은 더욱 가중되었습니다.
결함 관련 의사소통이 구두 또는 비공식적으로 이루어질 경우, 상황은 매우 빠르게 복잡해집니다. 버그를 효과적으로 관리하려면 팀 간 보고 방식을 표준화하는 명확한 결함 수명주기가 필요합니다. track, 그리고 문제를 해결하세요.
1단계) 발견
. 발견 이 단계에서 프로젝트 팀은 최종 고객이 결함을 발견하기 전에 가능한 한 많은 결함을 식별해야 합니다. 결함은 개발 팀에서 인지하고 수용하면 "발견됨"으로 간주되며, 이때 상태가 변경됩니다. 가능.
예시 시나리오에서 테스터들은 84개의 결함을 발견했습니다. Guru99뱅크 웹사이트.
하지만 테스터와 개발자의 의견이 항상 일치하는 것은 아닙니다. 다음 사례를 살펴보세요. 테스트 팀이 다음과 같은 문제점을 발견했습니다. Guru99 은행 웹사이트에서 해당 오류를 보고했지만, 개발팀은 그것이 결함인지 여부에 대해 이의를 제기했습니다.
이러한 경우 테스트 관리자로서 어떻게 해야 할까요?
A) 테스트 팀의 의견에 동의하여 그것이 결함이라고 판단합니다.
B) 심판관의 역할을 맡아 문제가 결함인지 아닌지를 판단하십시오.
C) 개발팀과 마찬가지로 그것이 결함이 아니라는 데 동의합니다.
올바른 접근 방식은 옵션 B입니다. 충돌을 해결하기 위해 해결 프로세스를 적용해야 하며, 테스트 관리자는 해당 문제가 결함에 해당하는지 여부를 결정하기 전에 공정하게 평가해야 합니다.
2단계) 분류
결함 분류는 개발자가 업무 우선순위를 정하여 비즈니스에 가장 중요한 문제를 먼저 해결할 수 있도록 도와줍니다. 분류는 일반적으로 테스트 관리자가 수행하며 심각도와 비즈니스 영향력을 기준으로 합니다.
결함은 일반적으로 네 가지 우선순위 수준으로 분류됩니다. 중요, 높음, 보통, 낮음다음 결함 각각에 올바른 우선순위를 지정해 보세요.
- 웹사이트 성능이 너무 느립니다.
- 웹사이트의 로그인 기능이 제대로 작동하지 않습니다.
- 웹사이트의 GUI가 제대로 표시되지 않습니다. 변하기 쉬운 장치.
- 웹사이트는 사용자 로그인 세션을 기억할 수 없습니다.
- 일부 링크가 작동하지 않습니다.
다음은 권장 답변입니다.
| 그렇지 않습니다. | 기술설명 | 우선 | 설명 |
|---|---|---|---|
| 1 | 웹사이트 성능이 너무 느립니다 | 높음 | 성능 문제는 최종 사용자에게 큰 불편을 초래합니다. |
| 2 | 로그인 기능이 제대로 작동하지 않습니다. | 결정적인 | 로그인은 은행 웹사이트의 핵심 기능입니다. 로그인이 실패하면 전체 사용자 여정이 차단됩니다. |
| 3 | GUI가 모바일 기기에서 올바르게 표시되지 않습니다. | 중급 | 이 결함은 스마트폰으로 웹사이트를 보는 사용자에게 영향을 미칩니다. |
| 4 | 웹사이트는 사용자 로그인 세션을 기억할 수 없습니다. | 높음 | 사용자는 로그인할 수 있지만, 추가적인 거래는 진행할 수 없습니다. |
| 5 | 일부 링크가 작동하지 않습니다. | 높음 | 개발자 입장에서는 간단한 해결책이며, 사용자들은 여전히 사이트의 나머지 부분을 이용할 수 있습니다. |
3단계) 결함 해결
결함 해결 소프트웨어 테스트에서 결함 해결은 단계별로 결함을 수정하는 과정입니다. 결함 해결 과정은 개발자에게 결함을 할당하는 것으로 시작하여, 개발자는 우선순위에 따라 수정 일정을 잡고, 수정 사항을 구현한 후, 최종적으로 테스트 관리자에게 해결 보고서를 제출합니다. 이러한 일련의 과정을 통해 결함을 해결할 수 있습니다. trac왕은 투명하고 책임감 있다.
다음 단계를 따라 결함을 수정할 수 있습니다.
- 과제: 해당 결함은 개발자 또는 기술자에게 할당되며, 상태는 다음과 같이 변경됩니다. 응답.
- 일정 수정: 개발팀이 인수를 받아 결함 우선순위에 따라 수정 일정을 수립합니다.
- 결함을 수정하세요: 개발자들이 결함을 수정하는 동안 테스트 관리자는 trac계획된 일정 대비 진행 상황.
- 해결 방법을 보고하세요: 개발자들은 어떤 결함이 어떻게 수정되었는지 확인하는 보고서를 보냅니다.
4단계) 검증
개발팀이 고정 신고 결함, 테스트 팀 확인 문제가 해결되었다는 뜻입니다.
예를 들어, 개발팀이 61개의 결함을 수정했다고 보고하면 테스트팀은 수정 사항이 원래 오류를 발생시킨 동일한 조건에서 제대로 작동하는지 확인하기 위해 각 결함을 다시 테스트합니다.
5단계) 종료
결함이 수정되고 검증되면 해당 결함의 상태가 변경됩니다. 휴무검증 과정에서 결함이 제대로 해결되지 않으면 개발팀에 다시 조사를 요청하는 알림을 보내야 합니다. '닫힘'은 시스템에서 해당 결함이 더 이상 존재하지 않음을 의미합니다.
6단계) 결함 보고
결함 보고 소프트웨어 테스트에서 결함 보고는 테스트 관리자가 결함 현황을 작성하여 관리팀과 공유하는 과정입니다. 관리팀은 보고서를 검토하고 필요한 경우 피드백이나 추가 지원을 제공합니다. 결함 보고는 의사소통을 개선합니다. trac왕, 그리고 결함 주변의 가시성.
경영진은 프로젝트를 효과적으로 지원하기 위해 결함 현황을 파악할 권리가 있습니다. 따라서 경영진이 지침과 자원을 제공할 수 있도록 결함 현황을 정기적으로 보고해야 합니다.
중요한 결함 지표
원래 시나리오로 돌아가서, 개발팀과 테스트팀이 함께 결함을 검토합니다. 종합적인 결과는 아래와 같습니다.
테스트 실행 품질을 어떻게 측정하고 평가할 수 있을까요?
이것은 모든 사람에게 중요한 질문입니다. 테스트 관리자 답변하고자 합니다. 일반적으로 두 가지 주요 매개변수가 사용됩니다.
위 시나리오에서, 불량률(DRR) 20/84 = 0.238(23.8%)로 계산됩니다.
또 다른 예로, 다음과 같이 가정해 보겠습니다. Guru99 Bank 웹사이트에는 총 64 결함이 있지만 테스트 팀은 다음과 같은 것만 감지합니다. 44 - 의미 20 결함이 발견되지 않았습니다. 결함 누출 비율(DLR) 20/64 = 0.312(31.2%)로 계산됩니다.
요약하자면, 테스트 실행 품질은 아래 두 가지 매개변수를 사용하여 평가됩니다.
DRR 및 DLR 값이 작을수록 테스트 실행 품질이 좋습니다. 허용 범위는 일반적으로 프로젝트 목표에 따라 정의되거나 유사한 프로젝트와 비교하여 설정됩니다. 이 예에서 권장되는 허용 범위는 다음과 같습니다. 5의 % 10 %로현재 실행 결과가 이 범위를 벗어나므로 다음과 같은 조치를 통해 테스트 품질을 개선해야 합니다.
- 개선 팀 구성원들의 테스트 능력.
- 시간을 좀더 보내다 테스트 실행 시, 특히 실행 결과를 검토할 때 그렇습니다.
효과적인 결함 관리를 위한 최고의 사례
체계적인 모범 사례를 따르는 것이 성숙한 결함 관리 프로세스와 혼란스러운 프로세스를 구분하는 핵심입니다. 목표는 단순히 버그를 수정하는 것이 아니라, 버그가 실제 운영 환경으로 유출되는 것을 방지하고 테스터와 개발자 간의 의사소통 오류를 최소화하는 시스템을 구축하는 것입니다.
다음은 초보 및 중급 테스터가 즉시 적용해야 할 모범 사례입니다.
- 결함 템플릿을 표준화하세요: 결함 ID와 같은 필드가 포함된 고정된 결함 보고서 템플릿을 사용하십시오. Descript오류 코드, 재현 단계, 심각도, 우선순위, 환경 및 첨부 파일. 일관성을 유지하면 테스터와 개발자 간의 불필요한 소통을 줄일 수 있습니다.
- 업무 배정 전에 우선순위를 정하세요: 개발자에게 결함을 전달하기 전에 항상 심각도와 우선순위에 따라 분류하십시오. 이렇게 하면 중요한 문제가 사소한 문제에 묻혀 처리되지 않는 것을 방지할 수 있습니다.
- 보고하기 전에 재현해 보세요: 결함을 제기하기 전에 깨끗한 환경에서 최소 두 번 이상 재현해 보십시오. 재현 가능한 결함은 더 빨리 해결되고 불량률을 줄입니다.
- 결함을 받아들이세요 trac킹 툴: 다음과 같은 도구를 사용하십시오. 지라, Bugzilla및 사마귀 중앙집중화하다 trac왕, 역사, 그리고 보도.
- 초기 대응 회의를 진행하세요: QA, 개발 및 제품 팀 간의 우선순위를 조율하기 위해 짧고 집중적인 결함 분류 회의를 진행하세요.
- 누출 및 불량률을 측정하십시오. Track DLR 및 DRR은 매 스프린트 또는 사이클마다 수행됩니다. 누출률이 증가하는 것은 테스트 범위가 불완전하다는 조기 경고입니다.
- 근본 원인 분석을 수행하십시오. 반복적으로 발생하거나 심각도가 높은 결함의 경우, 근본 원인 분석을 실행하여 향후 릴리스에서 동일한 유형의 버그가 다시 발생하지 않도록 하십시오.
- 보고를 통해 피드백 과정을 마무리하세요: 이해관계자들과 주간 결함 현황판을 공유하여 문제를 지속적으로 파악하고 조치를 취할 수 있도록 하세요.
이러한 관행을 일관되게 적용하면 결함 수명 주기가 안정화되고 모든 릴리스의 전반적인 품질이 향상됩니다.
