동일한 문제 / 티켓에 여러 결함을 게시하지 않는 이유는 무엇입니까?

이것이 다음과 같은 개념적 질문을 할 장소인지 확실하지 않습니다 (Stackoverflow는 확실히 아닙니다).

ISTQB 시험 과 유사한 객관식 시험 (단일 답변)에서이 질문을 보았습니다 .

동일한 이슈 / 티켓에서 여러 결함을보고하지 않는 이유는 무엇입니까?

에이. 간결하고 명확하게 보고서를 유지하기 위해.

비. 개발자는 하나의 버그만 수정할 수 있기 때문입니다.

기음. 테스팅 그룹 테스터는 발견 한 버그의 양에 따라 등급이 매겨집니다.

디. 버그 관리 시스템은 여러 버그의이 기능을 지원하지 않습니다.

나의 유일한 의견은 그것이 a정답입니다.

b- 수정-피드백 해결-닫힘 은이 경우를 피해야 하므로 불가능합니다 . c-분명히 틀렸다.

d -Redmine / Trac 플러그인은 여러 필드를 지원합니다.

답안지에 따른 답은 b입니다.

누군가 이유를 설명 할 수 있습니까? 답변에 대한 의견이있는 의견을 환영합니다.

Stack Overflow가 지침을 가지고 있다고 상상해보십시오. 하나의 질문을하는 대신, 같은 질문으로 지난 2 주 동안 겪었던 모든 문제를 마음에 떠올려 질문합니다. upvote와 downvote는 무엇을 의미합니까? 질문의 제목은 무엇입니까? 최상의 답변을받는 방법? 질문에 태그를 지정하는 방법은 무엇입니까?

버그 추적 시스템은 버그를 추적하기 위해 수행됩니다. 버그 추적은 다음을 의미합니다.

1. 버그를 재현하는 방법에 대한 정보와 함께 버그가있을 수 있음을 나타내는 레코드 작성,

2. 실제로 버그가 존재하는지 확인하고 의도적으로 버그가 아니며

3. 버그가 해결되었다고 주장하면서,

4. 버그가 해결되었는지 확인

매우 단순한 모델에서 1과 4는 고객이, 2와 3은 개발자가 수행합니다.

다음 로그를 상상해보십시오.

• Day 1 [고객] "제품 정보"창에서 "제거"버튼을 누르면 응용 프로그램이 중단됩니다. 응용 프로그램을 다시 시작하면 제품이 제거되지 않은 것으로 나타납니다. 예상되는 동작은 제품을 제거하는 것입니다.

• 제 4 일 [개발자] <발행 된 문제>

• 제 5 일 [개발자] <개정 5031에서 해결 된 문제>

• 12 일 [고객] <티켓 마감 : 문제 해결>

로그는 간단하고 명확 합니다. 당신은 쉽게 할 수 이루어졌다 때 무엇을 추적 특정 버전을 볼 때, 버그 추적 시스템은 버전 관리와 통합되어있는 경우 개정, 예를 들어 어떤 버그 등을 해결하는, 당신이 버그가에서 해결 된 것을 확인할 수 있습니다.

정보를 쉽게 찾을 수 있습니다 . 상태를 쉽게 볼 수 있습니다 (복제 되었습니까? 티켓이 닫히면 왜 그렇습니까?). 티켓을 쉽게 필터링 할 수 있습니다 (1 주일 이상 열려 있고 상호 작용 디자이너가 나에게 할당하고 중간 또는 우선 순위가 높은 티켓 만 원한다는 것을 고려하면 플러그인의 UI에만 관련된 티켓을 표시하고 싶습니다).

티켓을 재 할당하거나 버그를 담당 할 사람을 결정하는 것은 쉽습니다.

이제 다음 로그를 상상해보십시오.

• Day 1 [고객] "제품 정보"창에서 "제거"버튼을 누르면 앱이 중단됩니다. 또한 왼쪽 패널의 배경색은 진한 파란색이지만 자주색이어야합니다. 또한“제품 정보”창의 텍스트가 독일어로 잘 번역되지 않았다고 언급했습니다. 예상 되나요? 최종 번역은 언제 가능합니까? BTW,“제품 게시”작업을 위해 보낸 새 아이콘을 받았습니까? “데이터 동기화”창에 표시되지 않습니다.

• 6 일 [개발자] 색상을 자주색으로 변경했습니다.

• 7 일 [개발자] 예, 독일어 번역이 불완전한 것은 정상입니다.

• 제 8 일 [고객] 독일인은 괜찮습니다. 이탈리아어는 어떻습니까? Lucia는 이틀 전에 XML 파일을 보냈습니다.

• 제 9 일 [개발자] 이제 괜찮습니다.

• 10 일 [고객] "제거"버튼이 좋습니까? 이상한데 내 컴퓨터에서 여전히 정지합니다.

• Day 11 [개발자] 아니요, 이탈리아어 번역은 괜찮습니다.

• 12 일차 [고객] 알겠습니다. 고맙습니다. 그러나 색상에 문제가 있습니다. 진한 자주색으로 변경했지만 기본 창의 상단 패널과 같이 연한 자주색이어야합니다.

• 13 일 [개발자] 아이콘을 업데이트했습니다.

• 14 일 [고객] 아이콘은? 어떤 아이콘?

• 15 일 [개발자] 업데이트를 요청한 아이콘입니다.

• 16 일 [고객] 아이콘 업데이트를 요청한 적이 없습니다.

• 17 일 [개발자] 물론 물었습니다. 이 티켓을 참조하십시오. 제품 공개 아이콘이 업데이트되어야한다고 썼습니다. 난 끝냈어.

  ⁞

• 100 일 [고객] 그렇다면 로그의 항목은 어떻습니까?

• Day 101 [개발자] 당신이 무슨 말을하는지 모르겠습니다. 이 티켓에도 없지만 6199에 있습니다. 해결 된대로 닫습니다. <티켓 마감 : 문제 해결>

• 102 일 [고객] 다시 열게되어 죄송하지만 문제는 해결되지 않습니다. 로그의 항목에 대해 이야기하고 있습니다. 지난 주에 유니 코드 문자가 포함되어있을 때 텍스트가 유효하지 않다고 말했습니다. 기억 나니? <티켓 재개>

• Day 103 [개발자] 나는 막연하게 그런 것을 기억하지만이 티켓의 마지막 세 페이지를 검색 한 후에는 흔적을 찾을 수 없습니다. 문제가 무엇인지 다시 쓸 수 있습니까?

  ⁞

• 460 일 [개발자] 네트워크를 통해 암호화 된 파일에 대해 말한 내용을 검색하는 데 2 ​​시간을 보냈습니다. 정확한 요청을 찾을 수 있는지 잘 모르겠습니다.

• 460 일 [고객] 여러분은 더욱 체계적으로 조직해야합니다. 지난 2 주 동안이 문제에 대해 네 번 알 렸습니다. 왜 모든 것을 잊고 있습니까?

  ⁞

이 로그는 무엇입니까? 43 번 풀 렸고 43 번 다시 열었습니다. 개발자가 멍청해서 460 일 동안 같은 문제를 해결할 수 없다는 것을 의미합니까? 아뇨, 잠깐만 요,이 티켓은 11 명의 개발자에게 할당되었습니다. 거래는 무엇입니까? 특정 문제를 검색하는 방법은 무엇입니까? 실제로 바네사에게 할당되었지만 그녀의 5 명의 동료는이 티켓의 11 개 이슈 중 7 개에 대해 우려하고 있습니다. 티켓은 언제 마감해야합니까? 문제의 절반이 해결 되었습니까? 아니면 11 명 중 10 명입니까?

참고 : 이러한 로그가 존재하지 않는다고 생각할 수 있습니다. 날 믿어, 한번 이상 봤어

귀하의 진술에 의견을 남기기 위해 :

픽스-피드백-해제-폐쇄 된 경우를 피해야합니다.

이것은 제기 된 모든 버그가 동시에 수정 될 것이라고 가정합니다. 두 가지 문제가있는 제품 v1에 대해 티켓이 발생하는 시나리오를 상상해보십시오.

1. 양식 재설정 버튼은 값을 지우지 않고 실제로 양식을 제출합니다.
2. 버튼의 글꼴 크기는 115 % 여야하는 경우 110 %입니다.

둘 다 테스터가 제기하는 것이 맞습니다. 둘 다 구현의 결함이기 때문입니다. 그러나 제품 소유자가 첫 번째 하위 작업을 릴리스 할 차단기 (즉, 제품을 게시하기 전에 수정해야 함)로 결정하지만 두 번째 작업은 사소한 문제입니다 (즉, v1에서 수정 될 수 있음). 1 릴리스).

이 경우 2 번 티켓을 자체 티켓으로 분할하는 것 외에는 선택의 여지가 없습니다. 이렇게하면 서로 독립적으로 구현, 테스트 및 배포 할 수 있으며,이 경우 처음부터 개별 문제가 발생하는 것이 좋습니다.

범위:

이 답변 (및 질문)은 소스 결함이 사양이나 프로그래머의 의도에 따라 수행되지 않는 코드 결함 추적에만 적용 할 수 있습니다.

반대로, 각 GUI 티켓은 사실상 "재 설계"(디자인 결함), "개정 된 사양"또는 "기능 요청"(기능 누락)이기 때문에 GUI 결함 티켓에 여러 사양이 포함되는 것이 일반적입니다.

결함 추적의 중요한 목적 중 하나는 여러 역할 (프로그래머, 테스터, 고객 및 관리자) 간의 의사 소통 및 조정입니다.

코드 품질이 높은 프로젝트 (예 : 사용자 친화성에 비해)에서 결함 추적은 여러 측면으로 구성 될 수 있으며, 그 중 하나 는 향상 및 고객 지원 요청 추적과 별도로 코드 결함 추적에 중점을 둡니다 .

코드 결함 추적 시스템의 목적은 다음과 같습니다.

• 독립적으로 재현 가능한 결함을 독립 적이고 명확하게 추적 할 수 있도록합니다.
• 각 결함의 근본 원인에 대한 최상의 근사 (일대일 대응)를 제공합니다.

그렇게하는 동안 다음과 같은 바람직한 특성을 최대화해야합니다.

• 시간이 지남에 따라 결함 수가 증가함에 따라 효율적으로 확장됩니다.
• 이동 표적 증후군을 예방하십시오.

면책 조항 :이 문구는 내 개인적인 경험에서 비롯된 것입니다. 인증 시험 목적으로 불충분하거나 부정확 할 수 있습니다.

독립적이고 명확한 추적은 다음을 의미합니다.

1. 각 유효한 결함은 모호하지 않고 해결 되거나 해결되지 않을 수 있습니다 .

   • 이유 1 : 관리를 단순화하기 위해
     • 예 : "해결되지 않은 티켓 수"를 메트릭으로 사용할 수 있습니다.
   • 이유 2 : 실행 가능한 항목으로 변환
     • 예 : 해결되지 않은 경우 할당 된 프로그래머가 책임을집니다. 문제가 해결되었지만 닫히지 않은 경우 지정된 테스터 (검증 자)에 책임이 있습니다.
   • 결과 :이 방법에서는 부분적으로 해결 된 결함을 몇 가지 종속 결함으로 나눌 가치가 있습니다.

2. 독립적으로 재현 가능한 결함은 독립적으로 추적해야합니다.

   • "독립적으로 재현 가능한"은 서로 다른 상태를 가질 수 있음을 의미합니다. 하나는 고정 된 반면 다른 하나는 깨진 채로있을 수 있습니다.
   • 이유 : 결함 추적과 근본 원인 분석 간의 불일치를 최소화합니다.
     • 코드 결함으로 추적 될 수있는 각 근본 원인은 최소한 하나의 코드 변경이 필요하다고 생각됩니다.
     • 두 개의 결함이 독립적으로 재현 가능한 경우 여러 코드 변경이 필요합니다.
     • 두 개의 결함이 독립적으로 재현 가능한 경우, 한 테스트를 통과했다고해서 다른 테스트가 통과한다는 의미는 아니기 때문에 둘 다 테스트 (확인)되어야합니다.
   • 예 2 : 처음에 두 증상이 동일한 근본 원인을 갖고 동일한 티켓으로 분류되어 나중에 독립적으로 재현 가능한 것으로 나타난 경우 두 티켓으로 나누어야합니다.

몇 달 후에 시스템을 사용하는 다른 사람의 관점에서 살펴보십시오. 그들은 프로그램에서 버그를 발견합니다. 그들은 구글을 ​​둘러보고 문제가있는 지원 티켓이 있다는 것을 알게됩니다. 그리고, 폐쇄되었습니다! 대박! 최신 버전으로 수정되었습니다! 그래서 그들은 업데이트 ... 버그가 여전히 있습니까? 이 바보 같은 개발자들에게 무엇이 문제입니까?!?

사실은 없습니다. 버그 보고서를 제출 한 사람에게 문제가있는 것으로 나타났습니다. 그들은 같은 티켓에 두 개의 버그를 제출했습니다. 하나는 쉽게 고칠 수 있었고 빨리 고쳐졌고 다른 하나는 그렇지 않았습니다. Fix-feedback-resolved-closed 와 같은 것을 사용하더라도 , 특히 외부 관찰자에게 무슨 일이 일어나고 있는지 명확하지 않을 수 있습니다.

각 버그에 자체 티켓을 부여하는 것이 훨씬 낫습니다. 관련이 있지만 명백하게 구별되는 여러 버그가있는 경우 대부분의 버그 추적 시스템에는 하나의 버그를 다른 버그에 연결할 수있는 기능이 있습니다. (그렇지 않은 경우 보고서에 "버그 # 12345도 참조하십시오.") 넣을 수 있습니다.