테스터가 누가 더 많은 버그를 여는 지 확인하기 위해 경쟁하는 것이 좋습니까?

저는 소프트웨어 개발자입니다. 분석가가 작성한 테스트 케이스를 수행하고 테스트를 수행하는 테스터 팀이 있습니다. 테스터들이 누가 더 많은 버그를 여는 지 알아보기 위해 경쟁하고있는 것 같습니다. 버그 보고서의 품질이 떨어졌습니다. 테스터는 기능 테스트 및 소프트웨어 작동 관련 버그보고 대신 화면 개선, 유용성 또는 멍청한 버그에 대한 버그를 제출했습니다.

이것이 프로젝트에 좋습니까? 그렇지 않다면 어떻게 (소프트웨어 개발자로서) 테스터 팀의 생각과 태도를 바꾸려고 노력할 수 있습니까?

또 다른 문제점은 마감일이 추정되고 변경 될 수 없기 때문에 마감일이 가까워 질수록 테스터는 테스트 케이스를 완료하기 위해 스크램블링하게되므로 테스트 품질이 저하 될 수 있습니다. 이로 인해 고객이받은 최종 제품에 합법적 인 버그가 생길 수 있습니다.

OBS :이 경쟁은 회사의 관행이 아닙니다! 그것은 그들에 의해 조직 된 테스터들 사이의 경쟁이며 상금이 없습니다.

나는 그들이 가장 많은 버그를 찾아서 경쟁하는 것이 좋지 않다고 생각합니다. 그들의 임무는 버그를 찾는 것이 사실이지만, 그들의 임무는 " 가장 많은 버그를 찾는"것이 아닙니다 . 그들의 목표는 가장 많은 것을 찾는 것이 아니라 소프트웨어의 품질을 향상시키는 것입니다. 더 많은 버그를 찾도록 보상하는 것은 최고 품질의 코드가 아닌 대부분의 코드를 작성하여 프로그래머에게 보상하는 것과 같습니다.

게임으로 전환하면 가장 중요한 버그를 찾는 것이 아니라 많은 얕은 버그를 찾는 데 집중할 수 있습니다. 편집에서 언급했듯이 이것은 조직에서 일어나는 일입니다.

그들이 찾은 모든 버그는 공정한 게임이며 모든 버그를 발견해야한다고 주장 할 수 있습니다. 그러나 팀에 리소스가 부족한 경우 테스터가 몇 시간 또는 며칠 동안 실제로 큰 버그를 찾으려고 시스템에 깊이 조사하거나 인쇄상의 오류 및 작은 오류를 찾기 위해 앱을 건너 뛰는 데 몇 시간 또는 몇 일을 집중하고 싶습니까? 페이지에서 객체 정렬 오류

회사가 실제로 게임을 만들고자한다면 개발자에게 버그를 추가 할 수있는 권한을 부여하십시오. "멍청한 벌레"는 부정적인 점을 얻습니다. 잘 작성된 보고서가있는 벌레를 찾기가 어렵습니다. 그러면 인센티브가 "가장 찾기"에서 "일을 잘하는 사람"으로 바뀝니다. 그러나 프로그래머와 QA 분석가가 협력하여 숫자를 인위적으로 채울 수 있으므로 권장하지 않습니다.

결론 : 버그를 발견하여 게임을하지 마십시오. 조직에서 좋은 일을 보상하고 그 자리에 두는 방법을 찾으십시오. 게임 화는 사람들이 목표를 달성 한 것에 대한 보상입니다. QA 분석가가 "가장 많은 버그를 찾는 것"이라는 목표를 갖기를 원하지 않고, 그들의 목표가 "소프트웨어의 품질을 향상"시키기를 원합니다. 이 두 목표는 동일하지 않습니다.

나는 다른 답변에 약간 동의하지 않을 것입니다. 테스터를위한 "버그 찾기"는 개발자를위한 "코드 작성"과 비슷합니다. 미처리 금액은 의미가 없습니다. 테스터의 임무는 가능한 많은 버그를 찾는 것이지 버그를 찾는 것이 아닙니다. 테스터 A가 고품질 구성 요소에서 10 개의 버그 중 5 개를 발견하고 테스터 B가 품질이 낮은 구성 요소에서 263 개의 버그 중 58 개를 발견하면 테스터 A가 더 나은 테스터입니다.

개발자가 특정 문제를 해결하기 위해 최소량의 코드를 작성하고 테스터가 고장난 동작을 올바르게 설명하는 최소 수의 보고서를 작성하려고합니다. 가장 많은 결함을 찾기 위해 경쟁하는 것은 가장 많은 코드를 작성하기 위해 경쟁하는 것과 같습니다. 시스템을 유용하게 활용하기에는 너무 쉬운 일입니다.

테스터가 경쟁하기를 원한다면, 테스터가해야 할 일, 즉 소프트웨어가 설명 된대로 작동하는지 검증하는 것에 기반을 두어야합니다. 따라서 사람들에게 가장 인정받는 테스트 사례를 작성할 수있는 사람을 알아 보거나 더 많은 코드를 다루는 일련의 테스트 사례를 작성하도록 경쟁하게 할 수 있습니다.

개발자 생산성의 더 나은 측정은 작업 완료 횟수와 작업 복잡성입니다. 테스터 생산성의 더 나은 측정은 테스트 케이스 실행 횟수와 테스트 케이스 복잡도입니다. 발견 된 버그가 아니라 최대화하려고합니다.

내 개인적인 경험을 바탕으로 이것은 좋은 것이 아닙니다. 거의 항상 개발자가 복제, 말도 안되거나 완전히 잘못된 버그를 신고합니다. 테스터가 할당량을 충족하기 위해 서두르면서 한 달 / 4 분기 말에 갑자기 이러한 항목이 많이 나타납니다. 이것보다 더 나쁜 점은 코드에서 발견 된 버그의 수에 따라 개발자에게 불이익을 줄 때입니다. 테스트 팀과 개발 팀은이 시점에서 서로 협력하고 있으며 다른 팀을 나쁘게 만들지 않으면 성공할 수 없습니다.

여기서 사용자에 계속 집중해야합니다. 사용자는 테스트하는 동안 얼마나 많은 버그가 제기되었는지 알지 못합니다. 사용자는 소프트웨어를받을 때 소프트웨어가 작동하는 한 20 개의 버그 보고서 또는 20,000 개를 제출해도 상관 없습니다. 테스터를 평가하기위한 더 나은 측정 기준은 사용자가보고했지만 테스터가 합당하게 잡은 버그의 수입니다.

그래도 추적하기가 훨씬 어렵습니다. 특정 사람이 얼마나 많은 버그 보고서를 작성했는지 확인하기 위해 데이터베이스 쿼리를 실행하는 것은 매우 쉬운 일입니다. 이것이 많은 사람들이 "버그 제기"메트릭을 사용하는 주된 이유라고 생각합니다.

버그를 찾아서 게임을 만드는 데 아무런 문제가 없습니다. 사람들에게 동기를 부여하는 방법을 찾았습니다. 이거 좋다 또한 우선 순위를 전달하지 못하는 것으로 밝혀졌습니다. 대회를 끝내는 것은 낭비입니다. 우선 순위를 수정해야합니다.

몇 가지 실제 게임에는 간단한 점수 시스템이 있습니다. 왜 버그를 찾아야합니까?

단순히 버그 수로 게임의 점수를 매기는 대신 버그 보고서 품질을 측정해야합니다. 그런 다음 경연 대회는 버그 수에 관한 것이 아닙니다. 낚시 대회와 비슷할 것입니다. 누구나 우선 순위가 높은 큰 버그를 찾고 있습니다. 버그 보고서의 품질을 점수의 일부로 만드십시오. 개발자에게 테스터에게 버그 보고서의 품질에 대한 피드백을 제공하게합니다.

게임 밸런스를 미세 조정하는 것은 간단한 작업이 아니므로이 작업을 올바르게 수행하는 데 시간을 할애해야합니다. 목표를 명확하게 전달하고 재미 있어야합니다. 또한 비즈니스 요구가 변화함에 따라 조정할 수있는 것도 될 것입니다.

버그를 찾는 것이 그들의 일입니다. 그들이 일을 덜 효율적으로하지 않는 한 (예를 들어, 여러 개의 오타를 10 개 입력하지 않고 버그를 열어서) 그들이하는 일을 정확하게 수행하도록 권장합니다. 나는 많은 단점을 볼 수 없습니다.

이것은 @CandiedOrange의 답변 에 대한 확장입니다 .

보다 유용한 목표로 관심을 돌리기 시작하려면 비공식적이고 비공식적 인 것을 고려하십시오. 예를 들어 개발자는 작은 토큰과 트로피를 구입할 수 있습니다.

적어도 하나 이상의 중대한 버그가보고 된 경우 매일 테스터의 책상에 "Bug of the Day"토큰을 남겨 두십시오. 일주일에 한 번 더 크고 더 나은 "Bug of the Week"토큰 또는 트로피를 제공하는 개발자 행렬로 행사를 개최하십시오. 케이크로 "달의 버그"트로피를 더욱 극적으로 전달하십시오. 각 토큰이나 트로피에는 개발자가 왜 테스트에서 버그가 발견되었다고 생각하는지에 대한 인용이 수반되어야합니다. 인용의 사본은 테스터가 모두 읽을 수있는 곳에 두어야합니다.

테스터들이 버그를 찾는 것에서 트로피와 토큰을 모으는 것까지주의를 바꾼다는 희망이 있습니다. 이를위한 최선의 전략은 인용을 읽고 테스트에 대한 접근 방식이 개발자가 중요하게 생각할 버그를 가져올 가능성에 대해 생각하는 것입니다.

중요하지 않은 버그 보고서는 무시하십시오. 모든 것이 비공식적이고 비공식적이므로 언제든지 종료하거나 변경할 수 있습니다.

이것이 프로젝트에 좋습니까?

없음 . 귀하는 필요한 기능을 목표로하지 않는 품질이 낮은 보고서를 생성하고 테스터가 문제를 복잡하게 만들고 실제로 "추정 된 작업을 완료하기 위해 스크램블링"하는 결과를 발견했다고 스스로 지적했습니다. "하고 있습니다.

그렇지 않다면 어떻게 (소프트웨어 개발자로서) 테스터 팀의 생각과 태도를 바꾸려고 노력할 수 있습니까?

프로젝트 관리자와 함께 문제를 제기하십시오. 그들은 이런 종류의 일을 그들의 일의 일부로 간주해야합니다. 당신의 PM이 그것을 처리 할 수 ​​없거나 의지 할 수 없다면, 당신은 자신 만의 대처 전략을 개발하는 데 어려움을 겪고 있습니다. (다른 질문이 될 것입니다)

이런 식으로 진행된다면 어떻게 될지 (또는 이미 어떻게 될지) 반드시 품질이 낮아지는 것은 아니라고 생각합니다. 비록 그것이 품질 대 수량 비율을 감소시킬 것이라고 생각하지만. 이것이 나쁜 것인지 아닌지에 달려 있습니다. 그것은 경우에 따라

화면 개선, 유용성 또는 멍청한 버그에 대한 버그보고

당신이 정말로 원하지 않는 것입니다. 이것이 테스터에게 명확하다면, 나는 당신이보고 싶지 않은 일을하지 말고 명확하게 말하십시오. 해당 보고서 중 하나가 다시 나타나면이를 수행하십시오.

그들이 경쟁하는 이유는 아마도 일하는 동안 재미를 느끼기 때문일 것입니다.