소프트웨어 버그의 정의. 블리자드 엔터테인먼트는 "버그"가 전혀 버그가 아니라고 주장합니다. 그들이 맞습니까? [닫은]

Wikipepdia에 따르면

소프트웨어 버그는 컴퓨터 프로그램 또는 시스템의 오류, 결함, 실수, 실패 또는 결함을 설명하는 데 사용되는 일반적인 용어로, 잘못되거나 예기치 않은 결과가 발생하거나 의도하지 않은 방식으로 동작합니다.

최근에 StarCraft 2에서 "버그"가 발견되어 예기치 않은 결과가 발생했습니다. http://eu.battle.net/sc2/en/forum/topic/2868627470

문제는 스타 크래프트 2를 오랫동안 최소화하면 게임 연결이 끊어 지거나 시간 초과가 발생하지 않는다는 것입니다. 그러나 첫 전투 후 연결을 끊고 때로는 게임 데이터를 잃습니다 (경기 통계).

블리자드에 따르면 불행히도 :

게임은 이러한 장기간 동안 최소화되도록 설계되지 않았습니다. (블리자드)는 스타 크래프트 II가 몇 시간 동안 최소화되도록 의도되지 않은 잘못된 행동을 고려할 수 없습니다.

내 "버그"가 실제로 버그입니까?

소프트웨어 팀에게 버그는 수정해야하는 소프트웨어 문제입니다. 모든 소프트웨어 문제를 해결해야하는 것은 아닙니다.

소프트웨어 업데이트 비용이 많이 듭니다. 블리자드는 귀하의 문제가 가장 중요한 사례 라고 말합니다 . 다시 말해, 당신이 발견 한 가장 중요한 경우의 문제는 반드시 그들이 테스트했거나 설명해야 할 것이 아닙니다. 문제를 해결하면 도움이되지만 다른 많은 사람에게는 도움이되지 않습니다. 그러나 버그를 수정하는 비용은 높을 수 있습니다. 대신, 새로운 기능에 리소스를 투자하거나 Diablo III를 완성 할 수도 있습니다.

이런 종류의 전자 레인지 , 특히 1983 년 스미스 부인의 경우에 고양이 를 생각 나게합니다 .

요점은 제품이 그런 방식으로 작동하기 를 기대한다는 것입니다. 대부분의 유사한 제품이 그와 같이 작동하기 때문에, 즉 몇 시간 동안 제품을 최소화 한 다음 열면 작동합니다 (반대가 생각만큼 드물지는 않지만).

스미스 부인은 자신의 경험을 통해 오븐에서 고양이를 건조해도 해를 끼치 지 않을 것임을 알았습니다 (물론 약간의주의를 기울이면). 더 정확하게는 그녀가 시도한 모든 오븐을 가지고 있었다. 그런 다음 그녀는 그것이 주어진 전자 레인지와 동일하다고 가정했습니다. 이 가정은 틀렸다. 전자 레인지는 고양이를 건조 시키도록 설계되지 않았습니다. 전통적인 오븐도 아닙니다. 그들은 열을 발생시키기 위해 사용하는 물리적 프로세스의 부작용으로 프로세스에서 고양이를 죽이지 않습니다.

이제 전자 레인지 생산자로서 가열 코일과 센서 수를 전자 레인지에 넣을 수 있습니다. 후자는 전류 함량이 고양이인지 여부를 결정하고 마이크로파 대신 코일을 사용합니다.

같은 방식으로, 마른 고양이에 적합한 마이크로파를 생산할 수있는 것과 같이, 블리자드는 최소화 된 상태로 장시간 유지하기에 적합한 SC2 버전을 만들 수 있습니다.

개인적으로, 나는 재미를 위해서 고양이 건조 전자 레인지에 더 많은 돈을 기꺼이 지불 할 것입니다 (자랑스럽게 지적 할 수있는 큰 고양이 건조 적합 로고가 있다고 가정). 그러나 몇 시간 동안 최소화 할 수있는 게임은 신경 쓰지 않습니다.

SC2는 특정 요구 사항을 충족하도록 설계되었습니다. 당신의 기대는 그 일부가 아닙니다. 기대치에 따라 SC2를 자유롭게 측정 할 수 있습니다. 그러나 블리자드가 요구 사항의 범위에 모든 것을 포함하는지 여부는 궁극적으로 그들의 선택입니다.

실제로 논쟁의 여지가있는 것은 디자인 실패라는 것입니다. 상식에 따르면 사용자의 상당 부분이 디자인으로 인해 혼란 스럽거나 불만족하지 않는 한 충분합니다. 충분한 사용자가 자신의 기대를 공유한다고 명시하면 블리자드는이를 산출하여 디자인에 포함시킬 것입니다. 이것은 당신의 문제를 실제 버그로 만들 것이며 블리자드는 그것을 고칠 것입니다.

사양에 정의 된대로 소프트웨어를 사용하지 않는 경우라고 생각합니다. 그들은 말한다

게임은 이러한 장기간 동안 최소화되도록 설계되지 않았습니다.

이는 "장기"로 간주되는 어딘가에 정의가 있음을 의미합니다. "장기간"이상으로 프로그램을 최소화하면 프로그램이 사양을 넘어서고 테스트 한 것 (공식적으로 평가했다고 가정)을 넘어서며 어떤 일이 발생하는지 보증하지 않습니다. 물론, 어딘가 매뉴얼이 "10 분을 넘지 않는 기간 동안 만이 프로그램을 최소화하도록 테스트했습니다. 이보다 더 긴 시간 동안 자신의 위험을 최소화하십시오!"라고 말하면 좋을 것입니다.

아니, 나는 이것이 실제로 버그라고 생각하지 않습니다. 내 사무실에서는이를 "사용자 교육 문제"라고합니다 ( 이 경우 통신 문제 의 한 형태입니다. 이 경우 최소화 시간에 대한 최대 기간이 사용자에게 전달되지 않았기 때문에 통신 문제 의 형태 임 ). 프로그램을 올바르게 사용하지 않습니다. 설명서에 넣지 않으면 블리자드에 큰 도움이되지 않습니다 ...

버그가 아닙니다. 버그는 사양을 준수하지 않는 동작입니다. 사양에서 유스 케이스가 지원되지 않는 동작으로 표시되면 해당 유스 케이스에서 유효한 것으로 인식 된 모든 동작은 '디자인에 의한 것'입니다.

이 시나리오에서는 전혀 작동하지 않는 게임이 정의되지 않은 동작으로 인식 될 수 있습니다.

내가 그 프로젝트의 개발 팀장이라면 소프트웨어의 일반적인 운영 기대를 벗어난 버그이기 때문에 버그라고 부를 것입니다. 그것이 전혀 작동하지 않는다면 아마도 주니어 프로그래머 나 신입 사원에게 다른 무엇보다 학습 연습으로 할당 할 것입니다.

이러한 사소한 버그는 잠재적으로 더 많은 문제가 있음을 나타낼 수 있으므로 추적하는 것이 좋습니다. 예를 들어, 발생한 데이터 저장 버그. 발생 방법으로 인해 사소한 것처럼 보이지만 데이터가 손실되는 다른 경우가있을 수 있습니다. 버그보고 시스템을 사용하면 비슷한 문제가 발생한 모든 사례를 찾고 공통 요소가 있는지 확인할 수 있습니다. 복잡한 시스템에서 이런 종류의 문서를 문서화하면 더 심각하고 미묘한 버그를 찾는 데 도움이 될 수 있습니다.

나는 대부분의 사람들과 동의하지 않을 것입니다.

전직 스타 크래프트 (원래) 플레이어 인 나는 이것이 매우 흔한 행동임을 증명할 수 있습니다. 사용자는 24/7에 게임을 떠나 대화방에서 자신의 위치를 ​​유지하고 다시 돌아올 때 게임에 참여합니다. 업데이트 된 Battle.net에 몇 가지 개선 사항이있어이를 필요로하지 않을 것으로 확신하지만 여전히 많이 발생합니다.

세션이 어떤 방식, 모양 또는 형식으로 만료 된 경우 다시 연결하지 않고 게임에 참여할 수 없게하는 것이 훨씬 더 합리적입니다. 세션이 만료 된 후에 게임에 참여할 수 있다는 사실은 나에게 버그입니다. 여기서 혼란스럽고 아직 제기되지 않은 것은 개발자가 사용자를 이해해야한다는 것입니다. 이것은 엣지 케이스 일 수 있지만, 매우 헌신적 인 게이머에게는 엣지 케이스로 설정해야합니다.

기술적으로 그들은 디자인에 의한 것이라고 주장 할 수 있으며, 고치려는 의도가 아닙니다. 그것은 여전히 ​​내 눈의 결함이며, 버그로 분류할지 여부에 따라 궁극적으로 그들에게 달려 있습니다. 그렇다고 플레이어가 동의한다는 의미는 아닙니다.

어쨌든, 나는 지금까지 게시 된 것과 약간 다른 대답을 할 것이라고 생각했습니다.

버그는 "소프트웨어의 의도 된 동작과의 편차"로 합리적으로 정의 될 수 있습니다.

분명히 그들은 (그리고 그것들이 어떻게 동작해야 하는지를 결정하기 위해 그들의 소프트웨어이기 때문에) 소프트웨어가이 시나리오를 처리하도록 의도하지 않았기 때문에 버그의이 정의를 충족시키지 못합니다.

그러나 내가 말하고자하는 것은 적어도 차선책은이 조건을 처리하는 방법입니다.

쓰레기, 쓰레기는 (즉, 사용자가 어리 석거나 나쁘거나 예상치 못한 일을하며 결과적으로 나쁜 일이 발생 함)은 열악한 행동 표준으로 간주되었습니다. 나는 적어도이 조건을 처리하는 방식에서보다 우아해야한다고 말하고 싶습니다.

따라서 버그는 엄격하지 않지만 에지 사례를 제대로 처리하지 못합니다.

그것은 내가 그들이라면 내가 고칠 가치가 있다고 생각할만한 것이 아니라고 말했다.

버그의 정의는 소프트웨어의 동작과 관련이 없습니다. 버그는 소프트웨어의 동작이 의도와 일치하는지 여부에 따라 정의됩니다. 그리고 누가 의도를 말해야합니까? (여기서 프로그래머를 다루기 때문에 첫 번째 문장을 분명히 할 것입니다. 그 자체로는 버그를 구성 할 수있는 가능한 소프트웨어 동작이 없습니다).

일반적으로 버그는 소프트웨어 개발자가 해결해야하는 문제입니다. 따라서 버그의 정의는 그들이 고치려는 것에 기초합니다. 예를 들어, "시간의 50 % 이상 올바르게 작동하는 것은 향후 버전에서 출시 할 예정인 기능"입니다. 아무것도 소프트웨어를 척에 의해 버그가 아닌 것으로 정의 할 수는 특별한 문제가 해결하기위한 내용을 담고되지 않았다. 따라서 실제로 버그를 구성하는 것은 순전히 정치적 고려 사항입니다.

(제외 적으로, 이것은 두 가지 방법을 모두 삭감합니다. 버그 수정에 비용을 지불 할 필요는 없지만 새로운 개발에 대해서는 비용을 지불해야하는 고객에게 "방금 생각했지만 지금은 어떤 기능도하지 않습니다 "내가 언급 한 것들에 의해 100 % 암시 된 것으로 결정되었습니다"는 분명히 버그입니다.)

버그 연결을 끊지 않는 것이 좋습니다. 의도적으로 (의도적으로) 연결을 끊어야하지만 버그가 아닌 경우에만 버그입니다. 기능 요청을 제출 한 내용을 전화하겠습니다.

즉, 전투 후 데이터 손실 말했다 - 그 버그 수 있습니다. 스타 크래프트에 대해 많이 몰랐지만 의도적으로는 그렇지 않은 것 같습니다.