개발자가 버그 추적 시스템에 버그를 입력해야합니까?

개발 중 (기능 또는 버그 수정 중 하나) 때로는 작업중인 것과 직접 관련이없는 버그가 발견되는 경우가 있습니다. 그 상황에서 어떻게해야합니까? 그냥 고쳐? 나중에 수정해야합니까? 어딘가에 적어? 아니면 버그 추적 시스템에 입력 하시겠습니까?

나는 일반적으로 버그 추적 시스템에 입력하고 프로세스가 자체적으로 진행되도록합니다 (예 : 심사, 할당 등). 그러나 다른 개발자가 버그를 입력하는 것을 본 적이 거의 없습니다. (왜 그런 겁니까?)

버그를 발견 하면 버그 추적 시스템에 버그를 수정하지 않더라도 버그 추적 시스템에 들어 가지 않는 것이 좋습니다 . 이것이 바로 버그 추적 시스템의 목적입니다.

어떤 경우에는 시스템을 다루는 경험이 많은 QA 담당자에게보고하는 것이 더 합리적 일 수 있지만 어떤 경우에도 버그를 추적해야합니다.

개발자가 버그를 입력해서는 안되는 이유가있을 수 있습니다. 버그 추적 시스템이 외부인에게 표시되고보고 된 버그가 너무 많으면 나쁘게 보일 수 있습니다. 버그를 추적 할 수있는 다른 방법으로 해결해야하는 매우 나쁜 이유입니다. 상사에게 물어보십시오.

(물론 여전히 작업중인 코드에 버그가 있고 릴리스 된 내용에 표시되지 않는 경우 시스템에서 버그를 추적 할 필요는 없지만 소스 코드의 TODO 주석은 극단적 인 경우 "이 줄의 끝에 세미콜론을 입력하지 않았기 때문에이 코드는 컴파일되지 않습니다"라는 버그는보고 된 버그가 아닙니다.)

다른 개발자가 버그를 입력하지 않는 이유에 대해서는 물어봐야합니다. 아마해야합니다.

두 경우 모두 버그 추적 시스템에 버그를 입력해야합니다.

• 버그가 작업중인 코드와 직접 관련된 경우

• 버그가 코드와 관련이있을 때 현재 작업하지 않거나 다른 개발자가 작업하는 부분입니다.

이것은 버그 추적 시스템이 버그를 추적하도록 만들어 졌기 때문에 필수적입니다. 모든 버그. 잘못된 것을 발견하면 그냥 고치지 마십시오. 버그 추적 시스템을 통해 문서화하십시오. 나중에 이전 버전의 소프트웨어를 실행하는 고객이 정확히 복제 된 버그를보고하면 해당 버그를 보고서에 연결할 수 있습니다. 연결할 내용이 없으면 이전 개정판에서 버그를 검색하는 데 시간 (또는 동료)이 낭비한 다음 해결을 시도하고 마침내 버그가 이미 마술처럼 해결 된 것을 알게됩니다.

또한 프리랜서가 버전 관리 및 버그 추적 시스템을 모두 사용해야하는 이유도 설명합니다.이 두 도구는 팀만을위한 것이 아닙니다.

결함 추적 시스템에 결함을 입력하지 않는 정당한 이유는 없습니다. 추적없이 적용된 버그 수정을 본 유일한 장소는 프로세스가 근본적으로 손상 되었기 때문입니다. 이 경우 프로세스를 수정하십시오.

들어 가지 않는 이유는 다음과 같습니다.

• 프로세스는 결함보고에 근거하여 측정하고 처벌합니다 –보고하지 말고 처벌받지 마십시오. 이 경우 조직을 떠나십시오
• 프로세스는 부담입니다. 결함을 입력하고 수정 지점에 도달하려면 너무 많은 노력과 시간이 걸립니다. 개발자가 심사 / 수락 / 고정 프로세스를 통해 가벼운 버그를 빠르게 추적 할 수 있도록 프로세스를 변경해야합니다.
• 일부 개발자는 자신이 다른 사람에게 미치는 영향이 무엇인지 신경 쓰지 않는 게으른 / 조잡한 해커입니다. 전문 개발자를 모집하십시오.
• 나는 한 남자 밴드, 요점을 볼 수 없습니다. 2 인 밴드를 위해 일하면 당신은 ....

버그를 바로 고치는 것은 아마도 나쁜 생각 일 것입니다. 첫째, 다른 사람이 동일한 수정 작업을 수행하여 중복 된 노력을 기울일 수 있으며, 따르는 개발 방법론에 따라 다음에 수행 할 작업의 우선 순위 지정 (버그 수정 또는 새로운 기능 구현)이 더 중요합니다. 관리 결정 다음 개발 결정.

결정은 분명하지 않으며 트레이드 오프와 관련이 있습니다.

(일부) 찬성

버그 추적은 특히 대규모 팀의 커뮤니케이션에 필수적입니다. 코드를 여러 번 살펴보면 얻을 수있는 가장 큰 장점 중 하나는 문제를 조기에 감지 할 수 있다는 것입니다. 버그는 버그가 기록되거나 추적되지 않는 동안 손실됩니다.

• 종종 버그는 이미 코드의 일부에있는 동안 이해하기 위해 가장 쉽게 수정됩니다.
• 소규모 팀의 경우에도 버그를 나열하고 버그를 수정하는 과정에서 사기를 현명하게 누릴 수있는 많은 이점이 있습니다. 때로는 한 사람의 프로젝트에서 사기의 이점이 중요합니다.
• 정확한 버그 탐지는 사실 후에 매우 어려울 수 있습니다. 코드에서 버그를 발견하면 나중에 문제가 발생한 위치를 알아 내려고 형사를 찾는 많은 작업을 저장할 수 있습니다.
• 개발자가 버그를 발견 할 때주의를 기울이고 코드를 비판적으로 개선 / 정리 / 읽는 습관을들이는 것이 일반적인 개발에 도움이됩니다.

버그를 발견하면 일반적으로 말하면 좋은 습관이됩니다.

(일부) 단점

버그 추적 시스템에 버그를 입력하는 것은 번거롭고 시간 소모적 일 수 있으며, 대규모 팀에서 작업 할 때 개발 작업을 방해 할 수 있습니다. 다음을 기대할 수 있습니다.

• 입력하기 전에 항목이 중복인지 확인하십시오 (암시적일 수 있음). 대기열에 버그를 입력하여 닫을 것을 권장하지 않습니다
• 보고서에 반복 가능한 테스트 사례 제공
• 버그 세부 사항에 대한 질문으로 나중에 중단을 받아들이고 작성시 수정 사항을 수락 / 확인
• 버그 추적 시스템에서 자주 수집되는 관련없는 정보 (예 : 가장 영향을받는 제품, 버그 우선 순위 등)에 대해 생각해보십시오.

때로는 버그 추적이 시간을 가장 효율적으로 사용하지 않습니다.

이것들은 균형을 맞추기 어려운 두 가지 일반적인 원칙입니다. 좋은 전략을 찾는 것은 약간의 예술입니다. 이와 같은 상황에서는 유연한 휴리스틱을 채택하는 것이 최선의 방법이라고 생각합니다. 주어진 프로젝트, 팀, 작업 환경 및 일반적인 기술에 따라 필요에 따라 조정합니다. 내 전략은 대개 다음과 같은 패턴을 따릅니다.

• 하루 종일 어딘가에서 문제를 볼 때 항상 기록하십시오. 끈적 거리거나, 옆면에있는 파일 일 수도 있습니다. 아마도 당신이 기록하는 것은 파일 이름과 줄 번호 일 것입니다. 문제가 현재 생각을 지나치게 방해하지 않도록하십시오.

• 일을위한 준비 운동의 일환으로 스티커를 다룰 때마다 새로운 업무 일이 시작될 때 시간을 내십시오. 전날부터 감지 된 문제 목록을 살펴 보는 데 10-15 분이 걸리며 다음 중 가장 빠른 방법을 수행하십시오.

  • 문제를 해결하고 커밋하십시오 (아마도 한 개의 라이너 수정 또는 오타에 해당). 버그 보고서없이 커밋 할 수없는 경우 작은 커밋에 대한 보조 프로젝트를 만듭니다. 사이드 프로젝트에 충분한 수정 사항이 누적되면 문서화하고 커밋하는 데 몇 시간이 걸립니다.
  • 버그 추적 시스템에 문제를 기록합니다 (수정하는 데 시간이 오래 걸리지 만 과도한 오버 헤드는없는 명백한 문제)
  • "바쁘지 않을 때 살펴보기"문서에 문제점을 기록하십시오 (보통 "// TODO-이 부분이 깨져서 수정되었습니다"유형 주석을 소스에 추가하십시오). 기능 요청, 버그 보고서, 관리자와의 토론 등을 정기적으로 하루에 한 번씩 (한 달에 한 번 시도) 목록을 살펴보고 적절하게 기록합니다.

시간이 지남에 따라 모든 종류의 조정이 유용한 것으로 나타났습니다. 예를 들면 다음과 같습니다.

• 좀 더 엄격한 환경에서는 버그보고 작업을 테스트 팀에 오프로드 할 수 있습니다. 테스터가 한 번에 한 시간 씩 저를 만나서 문제 목록을 전달하고 로깅을 수행하도록합니다. 로깅 테스트가 큰 환경에서는 일반적으로 테스터가 생산성을 자유롭게 향상시킬 수 있습니다.
• 일부 팀은 고객 버그 보고서가없는 수정 프로그램을 허용하지 않습니다. 나는 프로젝트를 측면에서 수정으로 가득 채우고 고객이 관련 문제를보고하면 무료 브라우니 포인트를 즉시 수정합니다.
• 일부 팀에서는 코드 덩어리를 "소유"하는 사람이 수정을 수행해야합니다. 코드 "소유자"를 테스트 리더처럼 취급하고 비공식적으로 만나 문제를 전달하기도했습니다.

일반적으로 이러한 유형의 전략을 따르면 점점 더 많은 동료 및 다른 회사 구성원이 귀하의 작업과 품질에 대한 헌신을 존중하기 시작합니다. 충분한 시간이 지나면 원하는대로 전체 프로세스를 최적화하는 데 필요한 존중과 권한을 갖게됩니다. 그러한 기회에주의를 기울이고 적절하게 활용하십시오.

난 그냥 가지고 개발자들이 고정되지 않습니다 그들이 작업하는 것과 것을 관련이없는 버그가 발생하면, 그들은 시스템에 입력해야한다고 생각합니다 일부 그것의 기록. 이렇게하면 QA가 테스트를 시작할 때 (그리고 여전히 수정되지 않은 경우)이 버그를 "알려진 결함"으로 지정하여 동일한 버그를보고하지 않습니다.

버그를 발견 한 다른 개발자는 버그를 수정하려는 경우 자체적으로 버그를 추적하지만,이 경우 두 개발자가 독립적으로 동일한 버그를 찾아 수정해야 할 위험이 있습니다.

버그가 이미 수정 된 경우에도 (문제 추적기에서 버그를 기록하기 전에 발생해서는 안 됨) 추적하는 것이 좋습니다.

이런 식으로 나중에 문제가 다시 발생하면 (회귀가 발생합니다!) 문제를 "이미 해결 된"것으로 인식하고 처음 수정 된 방식을 읽는 것이 상대적으로 쉽습니다.

왜 그런 겁니까? 대부분의 개발자는 제기해야 할 문제와 코드를 작성하고 작성해야하는 문제를 검토하기 때문에 귀찮게하지 않는 것이 더 쉽습니다.

그러나 그것이 옳은 일인지는 프로세스에 달려 있습니다. 품질 보증팀이 있습니까? 추적되지 않는 코드를 변경하면 괜찮다고 생각하십니까? 코드 검토는 어떻습니까? 그 균열에 의해 건너 뛸 것인가? 사업은 어떻습니까? 나중에 같은 버그가 발생하지 않도록 버그를 수정했다는 것을 알아야합니까?

다른 개발자는 어떻습니까? 그들이 다른 방식으로 동시에 고치면 어떻게 되나요? 그들이 나중에 비슷한 버그를 발견하고 당신이 할 수있는 모든 것은 "오, 젠장, 우리가 전에 이런 것을 가졌다는 것을 알고 있습니다. 이제 무엇입니까?"

버그 추적 시스템에서 버그를 기록하는 데는 약 백만 가지 이유가 있습니다. 당신이 확실하다면 당신이 그 문제들 중 어느 것에도 부딪치지 않으면 반드시 귀찮게하지 마십시오. 그러나 당신이 전혀 확신이 없다면 대부분의 사람들이 모르더라도 그것을 기록해야합니다.

프로그래밍은 근본적으로 복잡한 작업입니다. 버그는 복잡합니다. 그래서 두 가지 요인으로 버그를 평가했습니다.

1. 앞으로 그러한 버그가 얼마나 자주 다시 나타날 수 있습니까? 이 추정치가 정확한지 여부를 계속 추정하십시오.
2. 그런 종류의 버그가 다시 나타나면 이해하기 쉬워 집니까? 이 버그를 분석하고 수정하면 정확합니다.

버그를 다음 유형 중 하나로 분류합니다.

1. 나중에 다시 나타나고 이해하기 쉽다.
2. 나중에 다시 나타나지만 이해하기 어렵다
3. 나중에 다시 나타나지 않고 이해하기 쉽다
4. 나중에 다시 나타나지 않지만 이해하기 어렵다

사례 1의 경우, 요리 책 또는 FAQ는 팀에서 향후 이러한 버그를 수정하는 좋은 장치입니다.

사례 2의 경우 다른 프로그래머가 그러한 버그를 다시 견뎌야하는 경우 노력을 낭비하기 때문에 팀에게는 정교하고 이해하기 쉬운 기록이 필요합니다. 예를 들어 : 메모리 누수.

사례 3에서는 쉬운 버그를 수정하는 데 너무 많은 시간을 소비하지 않기 때문에 기록 할 내용이없는 것이 큰 문제는 아니라고 생각합니다. 예를 들어 HTML에서 요소의 id에 대한 오타가 있습니다.

사례 4에서 이러한 버그는 딜레마를 만듭니다. 그러한 버그를 설명하기 위해 정교하고 이해하기 쉬운 기록을 작성하는 데 약간의 시간이 필요합니다. 그러나이 기록은 앞으로 거의 사용되지 않습니다. 그러나 기록이 없으면 그러한 버그가 나타나는 것이 다시는 힘들 것입니다. 예를 들어, 이러한 버그는 누군가의 컴퓨터에있는 컴퓨터 바이러스로 인해 나타납니다.

물론 입력해야합니다. 또는 그것이 정상적인 과정이라면 적어도 품질 보증 담당자에게보고하십시오.

버그를 직접 수정하더라도 수정 내용이 실제로 작동하고 회귀가 없는지 테스트하기 위해 변경 기록을 원할 것입니다. 어떤 시점에서 사용자가 버그를보고 할 수도 있으며 시스템에 있고 수정 된 것으로 표시되면 지원 담당자가 이미 해결되었다고 말할 수 있습니다.

실제로 당신은 그것들을 시스템에 기록해야하고, 그것이 연습되지 않는다면 시작하는 것이 좋습니다.

과거에는 제품 팀의 일원이었고 신제품 베타 버전을 사용하고 있었고 때때로 버그를 발견 한 적이 있는데 그 시점에서 우리는 모듈을 다루는 각 사람에게 메모하고 메일을 보냈습니다. 버그 추적 시스템이지만 우리는 그것들을 밀어 넣을 생각하지 않았습니다). 나중에 며칠이 지났을 때 다른 우선 순위로 인해 우편물에있는 품목이 무시되기 시작했고 결국 잠 못 이루는 밤이되었습니다.

그런 다음 언젠가는 너바나! 버그처럼 보이는 것을 발견하여 버그가 아닌 것으로 보일 수있는 경우에도 버그 추적기를 사용하지 않는 이유는 무엇입니까 (프로세스에 대한 생각이 잘못되었거나 결함이 있음). 적어도 목록에서 목록을 작성하고 테스트 할 수 있으며 모든 피드백 중 중요한 이유 또는 반대 측면에서 완벽하고 그 이유는 1 ... 2 ...로 인해 작동하는 방식입니다. .

이제 당신은 목록과 응용 프로그램의 일부를 오해 한 사람들을 위해 그들의 생각을 명확히 할 수있는 피드백을 얻습니다. 상생의 상황.

이미 테스트 된 코드 (특히 릴리스 된 경우)를 절대적으로 가정하십시오.

이에 대한 여러 가지 이유가 있습니다.

메모리 -시스템은 버그를 잊어 버리지 않을 것입니다. 개발자라면 누구나 그렇습니다.

측정 항목 -발견, 종료 및 소요 된 시간은 캡처하기 쉬운 측정 항목으로 코드의 품질이 어떻게 진행되고 있는지 알려줍니다.

긴급 성 -세계에서 개발자에게는 가장 중요한 것처럼 보이지만이 문제를 해결하는 데 소요되는 시간은 최종 사용자가 먼저 원하는 것에 더 잘 소비 할 수 있습니다 (메모리 참조).

복제 -이미 발견되어 다른 사람이 검사 / 수정중인 것 같습니다. 또는 급박 한 규칙에 어긋 났을 수 있습니다. 물론 다시 발견했다는 사실이 완료되어서는 안된다는 것을 의미하는 것이 아니라, 이제는 더 시급히 해결해야 할 의미가 있습니다.

근본 원인 분석 -해결하기 가장 쉬운 버그는 없었던 버그입니다. 팀이이 버그를보고 그것이 어떻게되었는지 알아 내야 할 수도 있습니다. 이것은 책임있는 사람을 처벌하지 않고 (도움이되지 않는) 미래에 상황을 피할 수있는 방법을 찾는 것입니다.

넓은 영향 분석 -하는 저렴한 버그 찾기는 당신이 그것을 발견하기 전에 대해 알고 하나입니다. 이 버그를 살펴보면 (특히 근본 원인 분석을 수행 한 후)이 문제가 코드의 다른 위치에 존재할 수 있다는 것이 금방 알 수 있습니다. 결과적으로 팀은 더 당황스러운 순간에 추악한 머리를 갖기 전에 그것을 찾기로 선택할 수 있습니다.

이 작업에 소요되는 시간은 코드의 성숙도와 품질 수준에 크게 좌우됩니다. 근본 원인 분석은 데모 코드를 다루는 소규모 팀에게는 과잉 일 수 있지만 비즈니스 핵심 개발에 대한 대규모 팀은 교훈을 효과적이고 효율적으로 학습해야합니다.

경험상 개발자가 도구를 사용하지 않는 데는 두 가지 이유가 있습니다.

1. 버그 처리 도구 및 / 또는 프로세스가 개발에 너무 무거운 것으로 인식
2. 개발자는 현재 작업중인 것보다 버그를 수정해야한다는 정신적 인 문제를 발견했습니다.

항목 1은 더 좋고 간단한 시스템이 필요할 수 있음을 의미합니다. 또는 대안 적으로 기존 시스템에 대한 더 강력한 정당화가 이루어질 수 있습니다.

항목 2는 현재 작업 할당에 대한 개발 책임자에게 유용한 경고 신호 여야합니다.

나는 주로 FrustratedWithFormsDesign에 동의하지만 전체 문제가 두 영역으로 나뉘어져 있으면 더 분명하다고 생각합니다.

• 버그보고.
• 오류 수정.

이것들은 종종 같은 것으로 취급되며 그것들을 분리하면 거의 확실히 도움이 될 것입니다.

버그 리포팅 (Bug Reporting) : 모든 사람들이 말하는 것처럼 시스템에 넣습니다.

버그 수정 :-매주 또는 2 주 (개발 일정 등에 따라 조정 됨) 모두가 프로젝트에 참여하여 수정 대상, 수정 대상 등을 결정합니다. 모두 같은 페이지에 있고 필요한 것이 무엇인지 알 수 있습니다. 완료하십시오. 민첩한 개발에서 이것은 스프린트 계획 회의입니다.

사람들 이 사용 하고 싶은 좋은 도구 도 큰 차이를 만듭니다. Pivotal Tracker가 마음에 들며 개인 프로젝트에서 수행하거나 수정하려는 작업을 추적하기 위해 사용하기 시작한 '실제 유용한 도구'테스트를 통과했습니다!

무언가를 본다면 무언가를 말하십시오!

현재 작업을 중단하고 싶지 않기 때문에 자체 모듈에 대한 버그 보고서를 입력하기도합니다. 그리고 나는 재현하는 모든 단계가 포함되도록 할 수 있습니다 :-)

그리고 다른 사람이 알려진 버그로 무언가를 나열한 것을 볼 때 더 좋습니다. 그들은 다른 누군가도 그것을 발견했다는 것을 알고 싶어합니다.

저는 이것이 최선의 실천에 관한 질문 보다 정치적 질문 이라고 생각합니다 .

• 버그 입력은 sombody를 비난합니까?
• 고객이 버그 입력을 읽고 추가 오류가 있음을 알 수 있습니다. 이것이 회사의 평판 문제입니까?
• 이것이 실제로 버그 또는 당신이 모르는 기능입니까?
• 누가 버그 수정을 할 것인가?

제 생각에는 트래커 시스템에 사소한 버그를 추가하는 것이 좋지만 경영진은 이에 대처하는 방법을 결정해야합니다.

사소하지 않은 경우에는 다른 사람과상의하지 않고 문제를 해결해서는 안됩니다.

• 이것은 실제로 버그이며 기능이 아닙니다.
• 다른 사람이 수정 프로그램을 테스트하고 수정 프로그램에 다른 버그가 없는지 확인 (회귀)