누가 버그 티켓을 복제합니까?

팀원 중 한 명이 방금 별도의 버그 티켓을 가져 와서 별도로 할당했지만 티켓은 중복되었습니다!

중복 티켓을 해결하는 가장 좋은 방법은 무엇입니까? 이것은 일반적으로 품질 관리 리소스에 의해 수행됩니까? 저는 비 기술적 인 사람들이 "흐름"을 방해한다고 말하는 몇 곳에서 일했지만, 기술적 인 비전문가는 개발자에 대한 접근이 제한적인 상황 (즉 기본적으로 항상)에서 할 수있는 일입니다.

실제로 모든 사람은 복제본을 피하기 위해 합리적인 노력을 기울여야하지만 개발자는 일반적으로 그렇게하는 것이 가장 좋습니다. 많은 사람들이 버그를 발견 할 수 있지만 일반적으로 해당 코드 영역을 담당하는 한 명의 개발자 또는 소규모 팀으로 필터링됩니다. 또한 두 가지 증상이 동일한 근본 원인을 갖는지 확인하기 위해 종종 코드가 필요합니다. 모든 버그 추적기는 중복을 매우 쉽게 처리 할 수 ​​있습니다. 당신은 그들이 때때로 팝업 걱정할 필요가 없습니다.

다른 한편으로, 만약 그들이 항상 발생한다면 , 당신은 테스터의 노력을 복제하고 테스트 자원을 어떻게 할당하는지 재평가하고 싶을 것입니다.

한 티켓에서 코드 변경 사항을 제출 한 다음 "이것은 중복이며 코드는 버그 # xxx입니다"라는 메모로 다른 티켓을 해결하십시오.

이것은 항상 일어난다.

이는 계획 프로세스 중에 수행해야합니다. 버그를 처음에 분류하고 우선 순위를 정할 때 해당 순위를 정하는 사람은 기본 백 로그에 복제본이 없는지 확인해야합니다.

긍정적 인 측면도 참고하십시오. 동일한 버그가 두 번 독립적으로 발견되면 재현하기가 쉬워야합니다. 개발자와 고객 모두 :-( 따라서 수정하는 것이 우선 순위가 높습니다.

버그 우선 순위를 정해야하는 사람이 한 명이며 관리자 나 해당 작업을 수행하는 한 사람의 복제본도 제거합니다. 버그를 고른 다음 전체 버그 목록을 검토하여 비슷한 버그를 확인하는 대신보다 효율적이어야합니다.

복제본을 피하지 않는 가장 나쁜 경우는 버그를 수정 한 후 다음 사람이 버그로 인해 재현 할 수없는 버그를 재현하는 데 많은 시간을 낭비하는 것입니다.