버그 재개 및 신규

55

버그가 열리고 수정, 확인 및 종료되었습니다. 한 달 후, 회귀없이 여러 번 반복 한 후 후속 버전에서 다시 나타났습니다.

버그 특성이 동일 하다면 기존 버그 ID 를 다시 열거 나 닫힌 버그에 대한 링크를 사용하여 새 버그 ID를 열 겠습니까?

project-management agile issue-tracking

— 모 라즈
소스

86

특성은 원인과 같지 않습니다. 새로운 버그는 동일한 것으로 보이지만 근본적인 이유가 다를 수 있습니다. 따라서 새로운 버그를 열고 이전 버그를 지적하여 개발자를 돕습니다.

— 딥 베크
소스

23

많은이 +1 있습니다 differnt 한 공유 다른 치료와 질환의 일반적인 증상은.

— FrustratedWithFormsDesigner

버그가 같은 원인을 가진 것으로 판명되면 다시 열었다 고 추론하는 것이 공정합니까?

— KMoraz

@ KMoraz : 그렇게 생각하지만 조사가 그것이 똑같은 원인 이라는 것을 입증 한 후에 고려해야 할 것 입니다. 증상이 잠시 동안 사라 때문에, 그것은의 가능성의 동일한 는 시스템의 다른 부분에 도입 버그,하지만 원래 버그가 코딩 된 것과 동일한 방식으로 코딩 등 유사한 증상을 야기 할 수 있지만, 버그.

— FrustratedWithFormsDesigner

1

@KMoraz 아니오라고 말할 것입니다. 1.0에서 수정되었다고 가정했지만 1.1에는 없었지만 1.2에 다시 나타납니다. 이슈 트래커를 사용하여 한 번에 서버 릴리스와 연결하지 않으면 1.0에서 발견되어 수정 된 기록이 손실됩니다. 새로운 버그를여십시오.

— Andy

1

@ 앤디 아무것도 변경하지 않는다고 생각하지만, 아마도 1.1은 그것을 보았고 아무도 눈치 채지 못했습니다 ...

— joshuahedlund

35

그것이 확인되고 닫히고 잠시 동안 일한 다음 무언가가 변경된 후에 다시 나타나면, 같은 버그가 아닙니다. 이전 버그와 비슷하게 나타날 수 있지만 그 원인은 다를 수 있습니다. 따라서 같은 버그가 아닙니다. 그래서 나는 닫힌 버그에 대한 링크와 함께 새로운 것을 열 것입니다.

— 주 나스 풀 라카
소스

16

항상 새로운 버그를여십시오. 왜? 이전 버그와 동일한 것으로 판명되고 이전 버그에 대한 픽스를 릴리스했다고 가정하십시오. 릴리스 노트에 "Fix Bug XXX"가 기록되어 있습니다. 이슈 추적 및 릴리스 노트를보다 명확하게하는 관점에서, "Fix Bug"라기보다는 새로운 버그 "Fix Bug XXX + 1 (원인 및 버그 XXX와 유사 함)"을 참조하는 것이 좋습니다. XXX (다시) "또는 이와 유사한 것

— 제임스 맥리 오드
소스

2

패치 노트에 버그 ID를 인용하는 것은 매우 우호적입니다.

— 토마스 보니 니

3

@krelp 공급 업체와 협력하여 문제를 해결하는 데 도움이되며 릴리스 정보에서 버그 ID로받은 버그 ID를 추적 할 수 있습니다.

— Darryl Braaten

1

@Krelp 나는 그것이 왜 나쁜 생각인지 궁금해 했으므로 여기에 물었다 : programmers.stackexchange.com/questions/142258/… 아마도 그것에 대한 정보가 있습니까? :)

— Travis Northcutt 2014 년

좋은 지적입니다

— KMoraz

4

일반적으로 새 버그를 엽니 다.

그러나 먼저 조사를 수행 할 수 있다면 소스 코드에서 이력을 확인합니다 .

팀 환경에서 작업하는 경우 누군가 시스템에 이전 코드가있을 수 있습니다 (예 : 원래 수정 사항을 체크인 한 후 최신 정보를 얻지 않음)하고 변경 한 후 diff를 수행하지 않고 체크인했습니다. 나쁜 습관은 물론 "항상"일어난다.

버그가 수정 된 파일의 기록을 살펴보면 가능한 빨리이를 확인하거나 제거 할 수 있습니다.

— 사네 원코
소스

1

... ", 변경을 한 다음 DIFF을하지 않고 체크인 (즉, 그들은 원래의 수정이 체크인 한 후이 최신하기하지 않았다)"즉, 소스 제어 시스템이 고장 일 경우

— JoelFan

@JoelFan-반드시 그런 것은 아닙니다. 때로는 자동 병합이 제대로 작동하지 않고 때로는 수동 병합도 제대로 작동하지 않습니다. 또는 그들이 diff 등을 할 때 변화를 놓친 경우 일 수 있습니다. 내가 말하는 것은 이것이 인간의 실수 냄새가 있고 소스 제어 기록을 2 분 점검 하면 많은 비용을 절약 할 수 있다는 것입니다 시비 걸다, ...을 들볶다.

— Sane Wonko

1

소스 제어 시스템이 고장난 경우이를 알고 싶기 때문에 기록을 확인하는 것이 좋습니다.

— mjfgates

2

그런 일이 발생하면 all the time고장난 SCM이 아니라 개발 팀입니다.

— Daenyth

1

이전 버그가 동일한 근본 원인이 아닐 수 있으므로 새 버그를 열 겠다는 이전 포스터의 제안에 동의합니다.

추가 권장 사항은 버그를 다루는 단위 및 통합 테스트를 항상 추가하여 향후 버전에서 문제가 고객에게 전달되기 전에 즉시 파악하도록하는 것입니다. 클라이언트에게 더 나쁜 것처럼 보이는 것은 같은 버그가 다시 나타나는 것을 보는 것입니다.

— 마이크 파크힐
소스

1

최선의 비유가 아님-두 사람의 증상이 동일하다고해서 질병 / 원인이 동일하다는 의미는 아닙니다.

위키 백과에서 :

소프트웨어 버그는 컴퓨터 프로그램 또는 시스템의 오류, 결함, 오류 또는 결함으로 인해 잘못되거나 예기치 않은 결과가 발생하거나 의도하지 않은 방식으로 작동합니다. 대부분의 버그는 .....

버그는 코드의 결함이며 증상 / 효과가 있습니다. 버그는 증상이 아닙니다. 버그는 코드의 오류입니다. 증상이 동일하기 때문에 반드시 동일한 결함이 증상을 유발한다는 것을 의미하지는 않습니다.

내 이해는 동일한 코드 조각으로 인해 버그가 발생했다는 것을 확신 할 때 버그를 다시 열어야한다는 것입니다. 코드가 모든 테스트 시나리오 / 테스트 사례에서 올바르게 작동하지만 이전에 생각하지 않은 새로운 테스트 사례 또는 테스트 사례에서는 그렇지 않을 수 있습니다. 이런 종류의 시나리오는 일반적이지 않을 수 있습니다.

다른 시나리오는 동일한 결함이 새로운 결함, 즉 동일한 코드의 다른 부분이나 해당 코드에 영향을 미치는 다른 시스템의 새로운 버그로 인해 발생한다는 것입니다.

따라서 가장 안전한 방법은 동일한 증상이 발생할 때 새로운 버그를 여는 것입니다. 동일한 이전 코드가 버그를 담당하는 것으로 확인되면 새 버그를 닫고 이전 버그를 다시여십시오. 그렇지 않은 경우 새 버그를 유지하고 이전 버그에 연결하십시오.

— 버그 봇
소스