ソフトウェアのバグの定義。Blizzard Entertainmentは、私の「バグ」はバグではないと主張しています。彼らは正しいですか?[閉まっている]


18

ウィキペプディアによると、

ソフトウェアバグは、コンピュータプログラムまたはシステムのエラー、欠陥、間違い、失敗、または障害を説明するために使用される一般的な用語であり、不正確または予期しない結果を生成したり、意図しない動作をさせたりします。

最近、StarCraft 2で予期しない結果を生成する「バグ」を発見しました:http : //eu.battle.net/sc2/en/forum/topic/2868627470

問題は、StarCraft 2を長時間最小化したままにすると、ゲームが切断されず、タイムアウトが発生しないことです。ただし最初の戦いのは切断され、ゲームデータも失われることがあります(試合の統計情報)。

残念ながら、ブリザードによると:

ゲームは、このような長期間にわたって最小限に抑えられるようには設計されていません。(ブリザード)StarCraft IIは数時間にわたって最小化されることを意図していないため、このような動作をエラーと見なすことはできません。

だから、私の「バグ」は本当にバグですか?


31
確かにバグですが、この状況をサポートされているとは見なさないため、修正しません(つまり、このように動作するように設計されていないため、そのように使用しようとすると、自分で)。そしてもちろん、簡単な回避策があります-それをしないでください。
オデッド

17
記録のために、ブリザードの代表者は状況を非常にうまく処理しませんでした。彼らは「このバグを報告してくれてありがとう。我々のシステムにそれを入力し、開発者がそれが優先順位であると判断したらすぐに修正する」と言うべきだった。暗黙の前提は、それが優先事項になることは決してないということです。私の意見では非常にうまく処理されません。
リウォーク

29
@ Stargazer712 Blizzardはこれを正確に処理しました。修正するつもりのないバグを修正するという期待を設定すべきではありません。
マットベレンジャー

3
TeleShoTTgunに公平を期すために、Blizzardは少なくとも「長期」と見なされるものを定義すべきだったと思います。数分間トイレに行くためにゲームを最小化するかもしれません。そんなに長い時間はないと思いますが、ブリザードはそうですか?このコンテキストでは、30分を超える時間を「長時間」と見なしますが、ブリザードが同意するかどうかはわかりません。
FrustratedWithFormsDesigner

3
古いヴォードビルの行為-「医者、医者、これをやると痛い」-「そんなことしないで!」
サイクロプス

回答:


58

ソフトウェアチームにとって、バグは修正が必要なソフトウェアの問題です。すべてのソフトウェアの問題を修正する必要はありません。

ソフトウェアの更新は高価です。Blizzardは、あなたの問題はエッジケースだと言っています 言い換えれば、あなたが発見したエッジケースの問題は、必ずしも彼らがテストしたものであるか、そうでなければ考慮する必要があるものではありません。問題を解決することは助けになりますが、他の多くの人には役に立たないでしょう。それでも、バグを修正するためのコストは高くなる可能性があります。代わりに、新しい機能にリソースを投資したり、Diablo IIIを完成させることもできます。


3
実際に使用されている定義をキャプチャしたと思います。私は、バグは他のポスターが持っている仕様とは異なる動作であると答えようとしていました。しかし、現実には、欠陥のある動作が仕様の定義内にあるが、ビジネスに重大な影響を与えた場合、会社はそれを修正します。そして、あなたが言ったように、仕様がそれが機能するべきであると言っても、ROIが低い場合、問題の会社はそれを修正しません。素晴らしい答え。
マットライアン

2
@MattRyan:現実の世界(私が見た)では、仕様がビジネスユーザーが「バグ」と呼ぶ誤った動作を引き起こす場合、開発チームは通常、ソリューションを「変更要求」として正式に再分類します。「バグ修正」としてではありません。;)
FrustratedWithFormsDesigner

3
つまり、「バグ」または「不具合」は、正しく実装されていない要件を表します。この場合、ゲームを最小化したままにする必要はありません。
レイ

22

この種のことは、マイクロ波の中、特に1983年のスミス夫人のことを思い出させます。

重要なのは、製品がそのように機能することを期待しているということです。ほとんどの類似製品がそのように機能するためです。つまり、数時間最小化してから開くと機能します(ただし、反対はあなたが思うほど珍しいことではありません)。

スミス夫人は彼女の経験から、猫をオーブンで乾燥させても害を及ぼさないことを知っていました(もちろん注意が必要です)。より正確には、彼女が試したすべてのオーブンで得た経験から。その後、彼女は与えられた電子レンジと同じだと思いました。この仮定は間違っていました。電子レンジは猫を乾燥させるようには設計されていません。どちらも従来のオーブンではありません。彼らは、彼らが熱を発生させるために使用する物理的プロセスの副作用として、たまたまそのプロセスで猫を殺さない。

マイクロ波のプロデューサーとして、加熱コイルと多数のセンサーをマイクロ波に配置できます。後者は、現在のコンテンツが猫であるかどうかを判断し、マイクロ波の代わりにコイルを使用します。

同じ方法で、猫を乾かすのに適した電子レンジを作ることができたので、Blizzardは長時間にわたって最小化された状態を保つのに適したバージョンのSC2を作成できました。

個人的には、猫の乾燥機能を備えた電子レンジの楽しみのために、もっとお金を払うつもりです(前に大きな猫乾燥機能のロゴがあると仮定すると、誇らしげに指摘できます)。しかし、私は何時間も最小化されたままにできるゲームを気にかけません。

SC2は、特定の要件を満たすように設計されました。あなたの期待はそれらの一部ではありません。期待に応じてSC2を自由に測定できます。しかし、Blizzardがそれらすべてを要件の範囲に含めるかどうかは、最終的には彼らの選択です。

あなたが本当に議論できるのは、それが設計の失敗だということです。常識では、ユーザーのかなりの部分がデザインに混乱したり、デザインに不満を抱いたりしない限り、それで十分であると規定されています。十分なユーザーがあなたの期待を共有していると述べれば、Blizzardはそれを譲り渡してデザインに含めるでしょう。これにより、問題が実際のバグになり、Blizzardが修正します。


いい答え、恐ろしい比phor。私は誰かが実際にそれをするのに十分な愚かさではなかったことをとても幸せです!
ドリュー

11

これは、仕様で定義されているとおりに使用されていないソフトウェアのケースだと思います。彼らが言う

ゲームは、このような長期間にわたって最小限に抑えられるようには設計されていません。

これは、「長期」と見なされるもののどこかに何らかの定義があることを意味します。「長期間」以上プログラムを最小化すると、仕様を超え、テスト対象を超えて(正式にテストされたと仮定して)、何が起こるかを保証しません。もちろん、どこかでマニュアルが「このプログラムを最小化するのは10分を超えないようにテストしただけです。これ以上長くするのはご自身の責任で行ってください!」

いいえ、これは本当にバグだとは思いません。(私はの形だと思います私のオフィスでは、これは「ユーザートレーニングの問題」と呼ばれることになる通信ユーザーであるため、最小化時には最大期間がユーザーに伝えなかったためなぜならこの場合には、問題を)プログラムを適切に使用していない。彼らがマニュアルにそれを入れない限り、それはブリザードのために大いに役立つというわけではありません...


3
ミッションクリティカルなシステムの場合、「このシステムはn時間動作し続ける必要がある」という要件があり、システムがn時間動作することを外部でテストおよび文書化します。また、m> n時間のテストを行ってもシステムが機能していることを内部で文書化する場合があります。ミッションクリティカルではないゲームの場合、ほとんどの人はおそらくこの問題に遭遇することはないので、必ずしも公式に外部からキャプチャする必要はありません。
トーマス・オーエンズ

8

バグではありません。バグとは、仕様に準拠しない動作です。ユースケースがサポートされていない動作であると仕様書に記載されている場合、そのユースケースでの動作は「有効」または「無効」と見なされます。

このシナリオでは、まったく動作するゲームは未定義の動作として認識される可能性があります。


これは大規模な回避です。私はそれを聞くたびにそれを軽deします。なぜなら、「仕様」が不完全な場合にのみ出てくるからです。
ショーンマクミラン

2
@SeanMcMillan:このようなものがなければ、機能クリープは私たち全員を殺すでしょう。いずれにせよ、それは回避されていません。これは、サポートされていないと特に指摘されているシナリオだからです。
スティーブンエバーズ

1
@SnOrfus:指摘されています。事後に。「x分を超えるアプリケーションの最小化はサポートされていません」と明示的に述べられている仕様があると本当に信じていますか?明らかに、それはバグです。
ThomasX

問題は、実際のソフトウェアを記述するのに十分な仕様がないことです。「仕様に一致する」という目標は、優れたソフトウェアを生み出すものではなく、ソフトウェアの何かが悪い場合に「私のせいではない」という言い訳にすぎません。修正する価値はないかもしれませんが、「仕様」が理由ではありません。
ショーンマクミラン

@ThomasX私が作業しているプロジェクトは200〜400ページの仕様であり、実際にはランタイム用に定義された境界があることを考慮してください。はい、そうです。
スティーブンエバーズ

5

私がそのプロジェクトの開発チームのリーダーだった場合、それをバグと呼びますが、それはソフトウェアの通常の動作の期待から大きく外れているため、マイナーなものです。もしそれが全く取り組むつもりなら、おそらく私はそれをジュニアプログラマーまたは新入社員に他の何よりも彼らの学習演習として割り当てるでしょう。

これらの小さなバグは潜在的にはるかに広範囲に及ぶ問題を示している可能性があるため、追跡することをお勧めします。たとえば、発生したデータ保存のバグ。どのように発生したかにより、マイナーなように見えますが、データが失われている他のケースがあるかもしれません。バグ報告システムを使用すると、同様の問題が発生したすべてのケースを見つけて、共通の要素があるかどうかを確認できます。複雑なシステムでは、この種のものを文書化することで、より深刻で微妙なバグを見つけることができます。


5

私はここでほとんどの人に反対するつもりです。

元スタークラフト(オリジナル)プレイヤーとして、これは非常に一般的な動作である(または少なくともそうであった)ことを証明できます。ユーザーは24時間年中無休でゲームを終了し、チャットルームでのポジションを保持し、再び戻ったときにゲームに参加します。更新されたBattle.netには、この必要性を軽減するいくつかの改良点があると確信していますが、それでも多くのことが起こります。

セッションが何らかの形(形状または形式)で期限切れになった場合、再接続せずにゲームに参加させられないことは、はるかに理にかなっています。セッションの有効期限が切れた後にゲームに参加できるという事実は、私にとってバグです。ここで気がかりなこと、そしてまだ実際に育てられていないことは、開発者がユーザーを理解する必要があるということです。これは非常に良いケースかもしれませんが、非常に熱心なゲーマーにとっては喜ばしい設定である必要があるエッジケースです。

技術的には、設計によるものであり、修正を意図しているものではないと主張することができます。私の目にはまだ障害があります。バグとして分類するかどうかは最終的には彼ら次第です。それはプレイヤーが同意するという意味ではありません。

とにかく、私はこれまでに投稿されたものとは少し異なる答えを出すと思った。


1
実際にStarcraftをプレイした場合、実際には長時間画面を最小化します。私はそれがバグであるかどうかの問題は無関係だと思うが、それはそれが処理すべきもののようであり、そうしなければ本当にバグになるだろう。
psr

合意-これはバグとして分類する必要がありますが、すべて優先度が非常に低いものです。彼らは「長時間にわたってゲームを最小化したままにすることはサポートされていません」と言うかもしれませんが、正確に何が長い期間を構成するのでしょうか?10分間最小化した場合、同じ問題が発生しないことをどのように知るのですか?少なくとも、ユーザーがそのようなアクションをサポートするつもりがない場合にx分以上最小化されたままになった場合にユーザーを切断するゲームタイムアウトを設計および実装する必要があります。
ギャビンコーツ

4

バグは「ソフトウェアの意図された動作からの逸脱」として合理的に定義できます。

明らかに彼らは(そしてそれは彼らのソフトウェアであり、彼らはそれがどのように振る舞うべきかを決定するようになります)ソフトウェアがこのシナリオを処理することを決して意図しなかったので、バグのこの定義を満たしません。

しかし、私が言うことは、少なくとも、次善の策は、この状態を処理する方法です。

ガベージイン、ガベージアウト(つまり、ユーザーが馬鹿なこと、悪いこと、予期しないことを行い、結果として悪いことが起こること)は、粗末な動作基準と見なされています。少なくとも、この状態を処理する方法はよりエレガントでなければなりません。

したがって、厳密にはバグではなく、エッジケースの処理が不十分です。

私が彼らだったら、それは私が修正する価値があるとは思わないだろう(あまりにも少ない利益のために高価だ)が、将来の参考のためにそれを彼らがよりうまく処理したかもしれないものであるとチームに言及するかもしれない。


1

バグの定義は、ソフトウェアの動作とは関係ありません。 バグは、ソフトウェアの動作が意図と一致するかどうかに基づいて定義されます。そして、その意図が何であったかを誰が言うのでしょうか?(ここではプログラマーを扱っているため、最初の文を明確にします-それ自体がバグを構成する可能性のあるソフトウェアの動作はありません)。

一般的に、バグはソフトウェア開発者が修正すべきものであることに留意してください。したがって、バグの定義は、修正する内容に基づいています。たとえば、「時間の50%以上を正しく動作させることは、将来のバージョンでリリースする予定の機能です」。 ソフトウェアがその特定の問題に対処することを意図していないふりをすることによって、何でもバグではないと定義できます。したがって、実際には、バグを構成するのは純粋に政治的な考慮事項です。

(余談ですが、これは両方の方法を削減します。バグ修正の費用を支払う必要はないが、新しい開発の費用を支払う必要のあるクライアントにとっては、「考えたばかりの機能は実行しませんが、私が言及したことによって100%暗示されていると判断された」は明らかにバグです。


適切に文書化されていないものをバグと宣言するのはOpenBSDではありませんか?
カナギーク

1

バグを切断しないとは考えません。(設計、意図により)切断することになっていて、そうしない場合の唯一のバグです。あなたが機能リクエストを提出したものを呼び出します。

とはいえ、戦闘後にデータを失うことはバグかもしれません。私はスタークラフトについてあまり知りませんが、それは仕様によるものではないと思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.