메뉴

버그가 거부되는 10 가지 이유와 테스터로서 할 수있는 일!

10 reasons why your bugs are getting rejected

문제를 제거하기 위해 도구를 사용해보십시오

최고의 무료 Windows 10 유지 관리 소프트웨어

나는 그녀를 살려주지 않을 것이다. 그녀는 지난 3 일 동안 7 개의 버그를 거부했다고보고했습니다. 그녀가 개인적인 원한을 직업 검으로 사용하고 있다는 것을 알고 있습니다. ……

한 팀원이 화를 냈고 두 명의 다른 팀원이 다른 개발자와 동일한 경험을 공유하기 위해 합류했을 때 갑자기 토론이 불붙었습니다. 팀 회의는 버그 거부에 대한 토론의 장으로 바뀌 었습니다. 약간의 토론 후, 우리 모두는 미래에 거부 된 버그의 굴욕으로부터 우리 자신을 구하기 위해 간단한 연습을하기로 결정했습니다.

버그가 거부되는 이유

우리 각자는 최근 10 개의 버그에 대한 버그 거부 사유로 메모를 작성하고보고 및 거부했습니다. 이러한 거부 노트 목록은 향후 버그보고 과정과 잘못된 가정이 무엇인지 이해하는 데 유용했습니다.

버그 거부 및 그 뒤에있는 이유

목록을 공개하는 대신 목록의 결과 글 머리 기호를 공유하고 싶습니다. 여기있어 -

# 1) 요구 사항 오해 :

어떤 이유로 든 요구 사항을 제대로 이해하지 못했다면 실제 구현에서 잘못 해석 된 요구 사항을 확실히 찾아 내고 찾지 못할 경우 버그가 발생하여 결국 거부 될 것입니다.

실제 사례 : 레시피를 테스트 한 결과, 소금을 넣지 않아 맛이 나지 않았으나 서빙시 소금을 넣어야한다는 사실을 몰랐습니다. 그렇지 않으면 레시피 외관에 영향을 미칠 수 있습니다.

# 2) 요구 사항 구현 :

이전 논의의 일환으로 특정 요구 사항이 XYZ 방식으로 구현 될 것이라는 것을 알고있었습니다. 그러나 개발 중에 개발자는 XYZ 경로를 따를 수 없다는 것을 알았으므로 ABC 경로를 따랐고 귀하에게 전달되지 않았습니다.

궁극적으로 요구 사항이 논의 된 방식으로 구현되지 않은 경우 버그를보고 할 것입니다.

실제 사례 : 재단사에게 셔츠를 준비해달라고 요청했고 재판을 요청 받았을 때 단추를 찾지 못했다고 거절했다. 재단사가 앞면에 단추를 달면 셔츠의 전체적인 모양에 영향을 미쳐서 앞쪽 테두리 안에 넣었다고 설명하면 확실히 멍청 할 것입니다.

# 3) 명확한 요구 사항 없음 :

사용 가능한 명확한 요구 사항이없는 경우 모든 사람이 자신의 방식으로 요구 사항을 자유롭게 가정 할 수 있으며 이는 개인 수준의 가정으로 이어집니다. 개인적인 가정이 만족스럽지 않다는 것을 알게되면 버그로 표시합니다.

실제 사례 : 선생님이 학생들이 자전거를 그릴 것이라고 예상했을 때 사이클을 그려야합니다. 30 분 후 모든 사람의 그림을 확인했지만 기대에 맞는 사람을 찾지 못했습니다. 모두가 모호한 말을 자신의 방식으로 받아 들였고 결과는 세발 자전거, 아기 자전거, 너무 많은주기, 휠체어로 자전거 타기 등이었습니다.

# 4) 요구 사항 변경 :

대부분의 경우 오해의 또 다른 예입니다. 테스터에게 요구 사항 변경에 대해 알리지 않으면 더 많은 버그가보고되고 궁극적으로 거부됩니다.

실제 사례 : 주문하신 바나나 빵이 아닌 벌꿀 빵을 사용한 샌드위치를 ​​찾으면 절대 거절하실 것입니다. 당신이 전화를하는 동안 당신의 파트너가 주문을 위해 빵 종류를 변경했다는 것을 알고 있었으며 물론 당신과 그것을 공유 할 필요가 없다는 것을 알게되었습니다.

# 5) 범위 이해 :

테스트하는 동안 특정 지점에서 테스트 할 수 없다고 간주되거나 제품 기준에 전혀 포함되지 않는 항목을 테스트하기 시작합니다. 당신은 버그 거부의 피해자가 될 것입니다.

실제 사례 : 방을 쓸어 내야하는데 그게 유일한 초점입니다. 그래도 다른 영역의 엉망진창에 대해 불평하면 분명히 무시 당할 것입니다.

# 6) 테스트 환경 :

애플리케이션 / 제품은 많은 하드웨어 및 소프트웨어 요구 사항의 조합입니다. 주요 및 사소한 요구 사항이 있으며, 적절한 테스트 환경이 사용되지 않거나 테스트 환경에서 무언가 누락 된 경우 애플리케이션 / 제품 충돌 및 심각한 버그가보고됩니다.

다음에 일어나는 일은 – 대부분의 시간 동안 우리가 사용한 테스트 환경에 대한 사소한 세부 정보를 의도하지 않게 제공하기 위해주의를 기울이지 않기 때문에 심도있는 조사가 이루어지기 때문에 개발자의 작업이 늘어납니다. 궁극적으로 버그는 거부됩니다.

실제 사례 : 며칠 전에 친구의 집에서 맛본 그 맛있는 머핀은 굉장했고 레시피를 따른 후에도 머핀은 당신이 가지고있는 머핀에 더 가까워지지 않았습니다.

글쎄, 당신은 신선한 버터를 구할 수 없었기 때문에 오래된 버터를 사용해서는 안되었고, 맛을 더할 것이라고 생각했기 때문에 그램 가루를 추가해서는 안되었고, 오븐처럼 팬에서 요리해서는 안됩니다. 고장났다.

추천 도서 => '테스트 환경'을 효과적으로 준비하는 방법.

# 7) 사용 된 테스트 데이터 :

테스트에 사용 된 테스트 데이터가 요구 사항과 일치하지 않습니다.

실제 사례 : 특수 문자를 추가하려고하면 계산기가 숫자 처리에 유용하다는 것을 알고도 계산기가 예기치 않게 반응하면 부적절하다고 생각합니다. 정말?

추천 도서 => 테스트 데이터 설계 팁 과 테스트 데이터 관리 기술 .

# 8) 중복 버그 :

누군가 이미 동일한 버그를보고했으며 버그를보고하기 전에 동일한 버그를 확인하지 않았습니다. 다시 거절.

실제 사례 : 고객 지원 담당자는 각 가족 구성원으로부터 동일한 제품에 대해 여러 번의 불만 전화를 받으면 기뻐하지 않을 것입니다. 한 번의 전화가 아니었다 고 생각할 것입니다.

자바에서 정렬을 사용하는 방법

# 9) 부적절한 버그 설명 :

개발자가 버그 보고서를 통해 전달하려는 내용을 이해할 수없는 경우 다른 작업도 함께로드되고 버그 보고서에서 적절한 설명과 필요한 세부 정보를 찾지 못한 경우 어떻게 든 거부 될 수 있습니다. 심각한 버그는 Rejected로 표시 될 것으로 예상됩니다.

추천 도서 => 좋은 버그 보고서를 작성하는 방법? 팁과 요령.

실제 사례 : 당신은 차의 잠금을 해제해야하고, 앉아 있어야하고, 시계 방향으로 열쇠를 움직여서 시작해야합니다.…. 차가 시작되지 않았기 때문에 당신은 화가납니다. 휘발유를 확인하라는 지시를받지 않았습니까? 아, 기본적으로 체크해야한다는 것을 확실히 이해한다고 가정 한 매뉴얼의 실수.

# 10) 재현 불가능한 버그 :

버그를보고하는 동안 버그 재현성의 중요성을 깨닫지 못했습니다. 버그가 항상 재현 가능한지 또는 무작위로 나타나는지 확인하는 것만으로도 작업 시간과 거부 된 버그를 하나 더 절약 할 수 있습니다.

실제 사례 : 당신이 심한 감기에 대해 불평을했지만 증상이 보이지 않을 때 의사는 무엇을 확인하겠습니까? 오, 재채기 심하게 , 상황을 더 좋게 만들지 않습니다.

결론

대부분의 경우 인간의 본성은보고 된 버그가 거부 될 때 부정적인 생각을하게합니다. 사실, 개발자는 버그가 유효한 경우 거부 할 특정 이유를 보지 못합니다.

따라서 다음 번에는 버그 수에 초점을 맞추지 마십시오. 궁극적으로 중요한 것은 얼마나 많은 버그를보고했는지가 아니라 제품의 품질을 개선하는 데 어떻게 도움을 주었 느냐가 가장 중요하기 때문입니다.

또한 읽기 => '유효하지 않은 버그'라벨없이 모든 버그를 해결하려면 어떻게해야합니까?

저자 정보 : 이 유용한 기사는 STH 팀원 Bhumika Mehta가 작성했습니다. 그녀는 7 년 이상의 소프트웨어 테스트 경험을 보유한 프로젝트 리더입니다.

즐거운 테스트 되세요! 평소처럼 당신의 견해를 기다리고 있습니다.

추천 도서

^