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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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