답변.

문제의 배경: 잡히기 힘든, 변동성이 큰 버그는 오래전부터 테스트 엔지니어들에게 골칫거리입니다. 이러한 버그는 항상 발생하지 않으며, 종종 잘못 문서화되어 재현 및 분석이 어려워지고, 결과적으로 수정이 복잡해집니다.

문제:

간헐적 버그의 주요 문제는 명확한 재현 시나리오를 설정할 수 없다는 것입니다. 대부분 불안정한 환경, 응답 시간, 데이터 동기화 오류 또는 여러 사용자 간의 충돌 때문일 수 있습니다. 개발자는 안정적으로 잡히지 않는 문제를 해결하기 어렵습니다. 테스터가 동반 조건을 문서화하지 않으면 버그는 해결되지 않은 채 남게 됩니다.

해결책:

보고서 확대 양식 사용: 버그 발생 시간, 환경, 단계, 로그, 비디오/스크린샷 기록.
경향 분석: 어떤 조건에서 버그가 나타났는지? (예: "주간 대량 트래픽 시" 또는 특정 행동 시퀀스에서만 발생.)
개발자와의 긴밀한 상호작용을 통해 환경을 최신 상태로 유지하고 기술적 세부사항을 명확히 합니다.
여러 장치와 운영 체제에서 재현 시도를 여러 번 진행합니다.

주요 특징:

성공적인 시도와 실패한 시도 간의 미세한 차이도 항상 기록하십시오.
발생 빈도와 재현 시도를 명시하십시오.
미디어 자료(스크린샷, 비디오)를 첨부하십시오.

함정 질문.

지원 엔지니어가 버그를 재현할 수 없으면 "비 버그"로 종료할 수 있나요?

아니요. 버그에 의심이 생기면 "reproducibility: low"라는 메모를 추가하여 티켓을 열어두는 것이 좋습니다. 새 데이터를 받아 업데이트합니다.

버그가 간헐적으로 발생할 경우, 항상 코드에 문제가 있나요?

아니요. 네트워크 오류, 환경 구성 문제, 오래된 브라우저 캐시, 외부 서비스의 특성, 주변 장치에서 오류가 발생할 수 있습니다.

버그를 매번 재현할 수 없다면 간헐적 버그의 우선 순위를 낮춰야 하나요?

항상 그런 것은 아닙니다. 결과가 사용자에게 심각한 영향을 미칠 수 있습니다(예: 이중 청구). 따라서 우선 순위는 비즈니스 리스크를 고려해야 합니다.

일반적인 실수 및 안티 패턴

시간, 환경, 버전에 대한 동반 정보 없이 버그를 기록합니다.
비 재현 가능한 불편을 형식적으로 "종료"하려고 시도합니다.
테스트 환경 외부에서 재현되지 않더라도 간헐적 버그를 무시합니다.

실생활 사례

부정적인 사례

테스터가 프로파일 잠금 해제 버그를 발견했지만, 이 버그는 10회 시도 중 1회 미만으로만 나타났습니다. 문서화는 오류 스크린샷으로 제한되었고, 개발자로서 재현할 수 없었기 때문에 버그는 닫혔습니다.

장점:

빠른 태스크 종료.

단점:

실제 사용자의 프로덕션에서 버그가 발생하여 긴급히 수정해야 하여 기업의 명성을 위태롭게 했습니다.

긍정적인 사례

테스터는 모든 조건을 신중하게 기록했습니다: 브라우저, 하루 중 시간, 로그인 방법, 짧은 비디오 및 로그를 첨부하며 개발자와 정기적으로 연락을 유지하여 안정적인 시나리오를 구축했습니다.