더 이상 관련이없는 버그를 닫는 방법

21

저는 현재 중간 규모의 웹 개발자 팀에 있습니다. 우리는 버그 추적을 위해 jira 를 사용하고 있습니다.

레이아웃이 자주 변경되는 제품을 개발 중입니다. 많은 브라우저에서 일부 레이아웃의 버그에 대해 버그가 제기되었습니다. 때로는 우선 순위가 낮은 버그를 처리 할 때까지 레이아웃이 이미 변경되어 더 이상 관련이 없습니다.

우리는 그것을 무엇으로 닫아야합니까?
내가 의미하는 바는 이러한 문제를 어떻게 처리 해야 하는가? Jira는 우리가 사용하는 버그 추적 소프트웨어이지만 이러한 종류의 문제를 일반적으로 처리하는 방법에 더 관심이 있습니다.
중요합니까? ( 나중에 레이아웃으로 돌아갈 수도 있지만, 가능성이 거의 없습니다)

issue-tracking jira

— 벤자민 그렌 바움
소스

8

너무 현지화;)

— yannis

4

그것은 비록 그 가능성이 도구 특정로 SO에 더 적합 할 수있다,이 너무 지역화 동의

— JK.

6

@jk. 저는 질문 자체가 "너무 현지화되어 있지 않다"는 것이 아니라 질문에 대한 제안 / 답변으로 "너무 현지화 됨"을 의미했습니다. 후자를 생각했다면 방금 닫았을 것입니다.

— yannis

2

@YannisRizos doh! 아마도 그것은 대답이었을 것입니다;)

— jk.

6

@jk. 나는 두 번째 질문이 더 흥미 롭다고 생각하지만 (심지어 중요합니까?) 지금은 대답 할 시간이 없습니다 (그리고 내 머리 속에 형성되는 답변이 좋은 것인지 확실하지 않습니다). 첫 번째 질문에 관해서는,이 스레드가 "단어 / 구문 제안"스레드가되면 "비 구조적"으로 닫힐 수 있습니다. 따라서 응답자들은 두 번째 질문을 무시하지 마십시오. 그것은 주제에 관한 흥미로운 질문입니다.

— yannis

26

프로젝트에서보고 된 문제의 상태를 전달하는 수단으로 이슈 트래커를 고려하는 경우 이러한 문제의 미묘한 차이. 이를 위해서는 버그 보고서를 읽고 이해하기 쉽도록 몇 가지 노력을 기울이는 것이 좋습니다.

테스터의 관점에서 보면 상황이 훨씬 덜 혼란스러워집니다. 팀에 테스터가 없다면 상상해보십시오 (또는 아직 ^{1 , 2 , 3을} 고용하십시오 ).

좋아, 그렇다면, 당신이 많이있어 버그가 옛적에 한 번, 테스터는 이전 릴리스의 사본을 보관하지 않는 것이 않을 경우 응용 프로그램 (보조 노트의 이전 버전을 사용하여 재현 할 수 있었다 훨씬 더 열심히 문제를 당신의 오래된 버그보다 팀). 테스터는이를보고 무엇이 잘못되었는지, 무엇이 버그인지를 알 수 있습니다.

이제 여러분은 "레이아웃이 이미 변경되었고 더 이상 관련이 없습니다"라고 말합니다. 즉, 눈에 띄지 않는 테스터의 마음은 더 간단한 진술로 바뀌 었 습니다 . 문제는 사라졌습니다 .

전문 테스터는이 시스템을 블랙 박스 로 편안하게 생각해야합니다 . 이러한 관점에서 문제가 어떻게 발생했는지 정확히 중요하지 않습니다. 레이아웃 변경 또는 흑 마법 또는 전체 재 설계 또는 구체적인 코드 변경 등이 될 수 있습니다.

블랙 박스 관점에서 보면 상황은 매우 간단합니다. 문제가 있었지만 이전 릴리스에서는 여전히 재현 할 수 있습니다. 이제 새로운 릴리스에는 더 이상 그런 문제가 없다고 주장합니다. 테스터의 경우 버그가 수정 되었다는 주장 과 주장이 사실인지를 확인해야 할 필요성이 있습니다.

전문 테스터는 이전 릴리스를 가져 와서 문제가 어떻게 발생하는지 확인한 다음 최신 릴리스를 사용하여 사라 졌거나 아직 없는지 확인합니다.

위에서 설명한 것처럼 버그를 처리하는 가장 정확한 방법은 해결 된 것으로 수정하는 것 입니다. 물론 수정 사항이 의도하지 않은 레이아웃 변경의 부작용으로 발생했다는 의견을 분명히하면 상처를 입지 않습니다.

과거 프로젝트에서 작업했던 사용자 지정 JIRA 중 하나는 "고정 된 설계"라는 결의안으로 인해 많은 결과를 초래 한 다소 심각한 변경 사항을 의도적으로 전달할 수있었습니다. 당신이 묘사 한 것과 같이, 그것은 일반 "고정"대신에 고려 될 수도 있는데, 그것은 의도적 인 코드 변경보다는 오히려 부작용이라는 것을 티켓 리더에게 암시하기 때문입니다.

— 모기
소스

2

디자인에 의해 고쳐진 것은 그와 완전히 반대되는 것을 의미합니다. 내 마음에, 디자인에 의해 수단 "의도적"(그것은 "실수로"의 반대입니다).

— TRiG

"고정"이면 충분합니다. 의도적이거나 다른 변경의 부작용인지 여부는 전혀 중요하지 않습니다. 그러나 "Fixed by Design"이 혼란 스럽다는 @TRiG에 동의합니다.

1

@TRiG 글쎄, 내가 주석에서 정확한 세부 사항을 더 잘 설명한다고 지적한 이유입니다. 고정 설계는 약간 광범위합니다. 내가 본 프로젝트에서 그것은 많은 결과를 낳는 다소 중대한 변화, 의도적이거나 그렇지 않은 변화를 전달하는 데 사용되었다. 또한 질문 텍스트 나 내 대답이 "실수로 수정"(어떤 실수?)을 의미하지는 않습니다. 여기서 "의도하지 않은"은 훨씬 더 적합합니다.

— gnat

1

모든 대답은 좋지만, 이것은 답답해 보입니다. 모두 감사합니다.

— Benjamin Gruenbaum

6

"Redesign by Redesign"은 어떻습니까?

— penguat

47

'폐기 됨'과 같은 문제를 해결합니다. JIRA의 기본 해상도 옵션은 아니지만 쉽게 추가 할 수 있습니다.

— 크리스
소스

+1 당신이 적어도 그것을 추가 할 수 없다면 버그가 아닌 것으로 선택하고 그 이유를 언급하십시오

— tgkprog

9

JIRA (및 다른 버그 추적기 사용)를 통해 사용자 지정 해상도 를 지정할 수 있으므로 "이벤트에 의한 추월"또는 "무의미한"해상도를 설정하거나 원하는 방식으로 클로저를 표현할 수 있도록 유사하게 설정할 수 있어야합니다

상관이 있나? 고객에 따라 트래커의 공개 된 이슈 수에 대해 지나치게 우려하고 있기 때문에 예라고 대답 할 수 있으므로 문제를 완전히 삭제하지 않고는 더 이상 관련이 없기 때문에 폐쇄되었다고 말할 수있는 것이 유용합니다. .

고객이 이슈 번호에 관심을 갖지 않아도 더 이상 관련이없는 오래된 공개 이슈를 정리하면 브라우저의 혼란을 줄이는 데 유용합니다.

— jk.
소스

1

"Over Taken By Events"는 너무 길어서 (imho), 검색하기 쉽고 공간이 적게 들기 때문에 (단어 등에서) 한 단어 (무의미하거나 쓸모없는)로 갈 것입니다. 쓸모없는 버그의 양을 아는 것은 한 번에 대량으로 들어 왔을 때 유용했으며 통신 문제를 지적했습니다. 우리의 테스터는 개발자가 작업 한 내용에 속도를 맞추지 못하고 일주일 정도 일이 벗겨지고 쓸모없는 소음을 일으킨다는 메모를 놓쳤습니다. 그래서, 우리의 복근을 되돌아 봅니다. 버그는 커뮤니케이션 프로세스에서 구멍을 찾아 수정하는 데 도움이되었습니다.

— yannis

3

우리가 실제로 약어 OBE를 사용하지만, 내가 사용하는 실제 단어가 여기에서 가장 흥미로운 생각, 요점은 무엇인가 당신을위한 작품을 선택하는 것입니다

— JK합니다.

3

@YannisRizos : 버그를 이용한 메타 버그 수정. 얼마나 멋진가요?

— Jörg W Mittag 12

@YannisRizos 검색은 유효한 해상도가 어쨌든 드롭 다운 (JIRA)

— jk

2

@Yannis. 나는 것 그 이상 잠을 잃게 추월 한 단어이어야한다.

— TRiG

5

우리는 FogBugz를 사용하지만 여기에 동일하거나 유사한 것이 적용됩니다.

우리는 단지 "해결됨 (고정)"을 사용하고 해상도에서 "고정 12345"와 같은 내용을 편집합니다.

FogBugz는 "case \ d +"와 일치하고 관련 사례에서 두 개를 함께 연결하지만 Jira가 그렇게하지 않으면 링크를 추가하는 것이 간단해야합니다.

이 때문에는 "너무 지역화"변종보다 IMO 더 나은 했다 가 고정되어 있기 때문에,이 기능은 제거되지 않은 실제 버그, 그냥 "폐기"보다.

— 이즈 카타
소스

3

<깨끗한 이야기를 깨우고 다시 확인하여 수정했습니다.

— yannis

1

Jira는이 접근 방식도 가능합니다. 해결 의견에 문제 번호를 언급하면 Jira가 해당 문제를 하이퍼 링크로 바꿉니다.

— Marjan Venema