버그 재현에 대한 책임

다른 프로그래머가 만든 라이브러리를 사용하여 프로그램을 개발 중입니다 (동일한 회사에서 일함). 최근에 라이브러리에서 누출이 발견되었으며, 이는 몇 시간 동안 실행 한 후 특정 네트워크 조건에서 발생합니다. 이 누출이 발생하도록 조건 설명과 함께 버그를 신고했습니다. 그 개발자는 "충분하지 않다"고 대답했습니다. "버그를 재현하는 것은 그의 책임이 아닙니다".이 버그를 재현하기 위해 단위 테스트를 작성해야합니다. 그렇지 않으면 아무 것도하지 않습니다.

1. 그가 맞습니까?
2. 이 상황에서 무엇을 할 수 있습니까? 임의의 네트워크 타이밍에 따라 단위 테스트를 생성 할 수 없습니다.

그가 옳은지 당신의 회사를 알지 못하면 실제로 대답 할 수없는 질문 일 것입니다. 그러나 그는 확실히 도움이되지 않습니다.

프로젝트에 문제를 일으키는 경우 그와 함께 버그를 제기 할 것입니다. 프로젝트 관리자와 함께 차단제로 제기하고 적절한 버그를 제기했음을 분명히합니다. 직접 수정하지 않으면 프로젝트에 영향을 미칩니다.

또한 개발자와 대화를 나누고 단위 테스트를 만드는 것이 왜 불가능한지 설명하지만 귀하의 컴퓨터에 표시하는 것이 행복 할 것입니다 (가능한 경우).

그는 버그를 재현 할 수 있도록 충분한 정보를 제공해야한다는 100 %의 권리입니다. 그렇지 않으면 그가 제공 한 수정 프로그램이 실제로 작동하는지 확인할 기회가 없습니다.

그러나 그는 IMHO가 100 % 잘못되어 이것이 단위 테스트의 형태이어야한다고 생각합니다. 실패를 재현 할 수있는 방식으로 테스트 시나리오를 설명 할 수있는 경우 (적어도 적당한 시간 내에 또는 수동 테스트를 통해), 문제가 존재한다는 증거가 있습니다. 이는 동료를 설정해야합니다. 그것을 고칠 책임이 있습니다. 물론 버그를 더 빨리 재현하는 시나리오를 만들 수 있다면 그에게 도움이 될 것입니다. 이상적으로는 자동 테스트를 수행해야하며, 이에 대한 책임이있는 조직에 따라 다릅니다.

양측은 약간의 노력을 기울여야한다.

라이브러리 테스트는 단위 테스트 없이도 일부 문제를 재현 할 수 없기 때문에 단위 테스트 없이도 추가 노력을 기울여야합니다. 때로는 하드웨어이고 때로는 나머지 프로그램 의 올바른 일련의 올바른 동작으로 인해 라이브러리가 나쁜 결과를 생성합니다.

이 모든 것이 결국 라이브러리의 버그는 아니지만 나머지 프로그램 의 잘못된 동작의 결과이기 때문에 약간의 추가 노력을 기울여야 합니다 (예 : 손상된 힙으로 인해 라이브러리가 이상하게 작동 할 수 있음). 따라서 버그 재생과 관련된 비 라이브러리 코드를 최대한 줄이는 것이 좋습니다. 또한 응용 프로그램 코드에 익숙하지 않은 사람보다 더 빠르고 깔끔하게 수행 할 수 있습니다.

라이브러리 작성자가 보고서를 기반으로 버그를 재현 할 수없는 경우 수정하지 않고 많은 시간을 소비 할 것으로 예상하는 것은 합리적이지 않습니다.

그러나 관심의 대상이되는 제품에 대한 작업 시간도 제한되어 있습니다. 불행히도 이것은 버그가 계속 존재한다는 것을 의미하며 버그를 해결하는 작업은 없습니다.

다행스럽게도 이것이 반드시 재난은 아니지만 이상적인 세상에서는 모든 소프트웨어에 버그가 없으며, 그렇지 않습니다. 따라서 미국의 문제에 따라 우선 순위를 정해야합니다.

즉, 수정이 필요한 경우 재현 가능한 테스트 사례를 개발하는 것은 사용자의 책임입니다. 문제가 해결되는지 걱정하지 않을 수 있으며,이 경우 예상 할 수있는 모든 작업을 수행해야합니다. 수정을 원할 수도 있지만, 현재는 재현 할 수 있도록 시간을 할애 할만큼 충분하지 않습니다. 그것은 완벽하게 허용됩니다.

버그를 처리해야 할 때 최선을 다해 버그를보고하는 것은 단순히 좋은 시민권입니다. 프로그램에 필요하지 않으면 그 이상으로 넘어갈 필요가 없습니다. 그리고 나서도 그렇게하고 싶지 않을 수도 있고, 사용할 수있는 다른 라이브러리가 있거나, 적당한 시간 안에 자신의 롤링을 할 수도 있습니다. 기본적으로 귀하에게 어떤 종류의 노력이 필요한지 결정하는 것은 귀하에게 달려 있습니다.

잠자는 개들이 지금 거짓말을하게하는 경향이 있습니다. 당신은 문제를 제기했고 그에게 배정되었습니다. 아마도 뛰어난 버그를 추적하고 추적하는 프로세스가 있습니까?

이 과정을 적극적으로 진행하려면 문제를 재현 할 수있는 테스트 도구가 있는지 관리자에게 문의하십시오.

개발자의 입장에서-필요한 정보를 제공했다면 아무것도하지 않는 것이 심각합니다. 그러나 작업량이 많을 수 있으므로 문제를 추적하는 데 필요한 시간을 할애 할 수 없습니다.

당신은 버그를 발견했다.

두 사람이 친한 친구 였으면 도움이 될만한 일을했지만 오히려 문제를 뒤로 밀고 싶을 것입니다.

자세한 내용을보고하고 메모리 누수에 대한 주장을 뒷받침하여 더 많은 것을 할 수 있습니다. 여전히, 당신은 자신의 책임이 있고 자신의 일을 끝내야합니다.

가능한 한 많은 정보를 버그 추적기에 로그인하고 계속 진행하십시오.

나중에이 사람을 다시 보게되면. 친근하고, 공통 관심사에 대해 이야기하고, 좋은 관계가 문제를 해결하는 데 훨씬 더 효과적이라는 것을 이해 한 다음 주장을 뒷받침하기 위해 제공 할 수있는 모든 사실을 이해하십시오.

종종 비슷한 상황에서 내가 겪은 것은 모든 버그가 수정되어야한다는 가정이며, 그것이 훌륭 할지라도, (버그를 작성하지 않기로 결정하지 마십시오!) 궁극적으로 비현실적입니다. 버그이기 때문에 버그를 수정하기에 알맞은 크기의 프로젝트 (찾을 수 있다면!) 프로젝트 관리 및 코딩 방법론, 패턴 및 실습 등이 있습니다.

그래서, 도서관 소유자의 방어에서 말하고 싶은 한 가지는 (그리고 큰 프로젝트에서 일한 경우였습니다) 데브 타임은 비용이 들고 유한 자원이므로 보고서 처리 방법에 대한 결정 , 누가 조사하고 어떤 테스트가 생성 / 필요하며 궁극적으로 수정이 이루어 졌는지 여부는 비즈니스 영향에 근거한 것입니다. 장기 실행 프로세스가 실패한 경우 한 번에 한 번 다시 시작하면 어떤 영향을 미치며 대신 자동화 할 수 있습니까 (아마도 방어적인 프로그래밍 수단이되어서는 안됩니까?) ?

또한 매우 드물게 발생하는 코드의 비트에서 한 명의 사용자가 예측할 수없는 문제를 버그 보고서로 볼 수 있습니다. 코드와 관련하여, 한 컴퓨터에서만, 비정상적인 타이밍에서만 가능합니다. 조건은 가능한 한 많은 시간을 찾아 수정해야 할 강력한 이유가 없습니다. 그러나 사용자가 철저히 조사하고 시간을내어 초기 테스트보다 신뢰할 수있는 테스트 사례 / 응용 프로그램 또는 근본적으로 더 자세한 문제 설명을 제공하기를 원할만큼 충분히 강력한 비즈니스 사례라면 다른 전체 게임 일 수 있습니다. .

이것은 아마도 도서관 소유자가 그것을 그렇게 생각하지 않았고 강력한 비즈니스 사례가있는 경우 (예 : 코드 비용이 비싸거나 법규 준수 요구 사항, 보안 허점이 있거나 일부 다른 주요 노크 효과) 이제 경영진에 발을 들여 싸워야 할 때입니다.

당신은 '이 누출이 발생하도록 조건에 대한 설명과 함께 버그를 제기했습니다.'라고 언급했습니다.

설명이 버그를 재현하기에 충분하다고 확신하는 경우 이미 정확한 조건을 알고 있습니다. 이제 조건을 알고 나서 단위 테스트를 작성할 수 없다면, 관련 컴포넌트 중 일부를 조롱 할 수 없거나 코드의 일부가 너무 단단하게 결합되어 실제 단위 테스트를 생성 할 수 없습니다.

단위 테스트를 만들 수 있도록 라이브러리 소유자에게 코드를 리팩터링하도록 요청해야합니다. 단위 테스트 생성을 중단시키는 라이브러리의 내용을 명확하게 설명해야합니다. 그렇지 않으면 코드를 리팩터링해야합니다. 그렇지 않으면 현재 코드로는 단위 테스트가 불가능하다는 것을 인정합니다. 두 가지 방법으로 이깁니다.

이것이 작동하지 않으면 다음과 같은 옵션이 있습니다.

• 더 많은 증거로 버그를 재현 할 수 있습니다.
• 더 높은 권한을 부여하고 증거를 평가하도록 요청하십시오.
• 모의 환경이있는 프로토 타입 응용 프로그램에서 라이브러리를 사용하여 버그를 재현하기 위해 코딩하십시오. 그렇게하면 최소한 버그가 있음을 증명할 수 있습니다.