ソフトウェアのバグの定義。 Blizzard Entertainmentは、私の「バグ」はまったくバグではないと主張しています。彼らは正しいですか？
ウィキペディアによると、
ソフトウェアのバグは、コンピュータプログラムまたはシステムのエラー、欠陥、間違い、失敗、または障害を説明するために使用される一般的な用語であり、不正確または予期しない結果を生成したり、その動作を引き起こしたりします意図しない方法。
最近、StarCraft 2に予期しない結果をもたらす「バグ」が見つかりました： http://eu.battle.net/sc2/en/forum/topic/286862747
問題は、StarCraft 2を長時間最小化したままにしておくと、ゲームが切断されなかったり、タイムアウトが発生したりしないことです。ただし、最初のバトル後に切断され、ゲームデータも失われます（一致統計）。
残念ながら、ブリザードによると：
ゲームは、このように長期間にわたって最小化された状態を保つようには設計されていません。 （ブリザード）は、StarCraft IIが何時間も最小化されることを意図していないため、このような動作を誤っていると見なすことはできません。
では、私の「バグ」は本当にバグなのでしょうか？
ソフトウェアチームにとって、バグは修正が必要なソフトウェアの問題です。すべてのソフトウェアの問題を修正する必要はありません。
ソフトウェアの更新は高価です。ブリザードは、問題が Edgeケースであることを通知しています。 言い換えると、発見したEdgeケースの問題は、必ずしもテストしたり、他の方法で気にしたりするものではありません説明します。問題を修正することはあなたを助けるでしょうが、おそらく他の多くの人を助けにはなりません。しかし、バグを修正するためのコストは高くなる可能性があります。代わりに、リソースを新機能に投資したり、Diablo IIIを仕上げたりすることもできます。
これは 電子レンジの猫 を思い出させます。具体的には、1983年のスミス夫人の場合です。
ポイントは、あなたが製品がそのような方法で機能することを期待することです。ほとんどの場合、同様の製品の多くがそのように機能するため、つまり、それらを数時間最小化してから開いた場合、それらは機能します（逆は、ごく普通のことですが）。
スミス夫人は彼女の経験から、オーブンで猫を乾燥させても害はないことを知っていました（もちろん、いくつかの注意が必要です）。より正確には、彼女が試したすべてのオーブンでの経験から。彼女はそれが彼女に与えられた電子レンジと同じであると思いました。この仮定は間違っていました。電子レンジは猫を乾燥させるようには設計されていません。どちらも従来のオーブンではありません。彼らはたまたま、熱を発生させるために彼らが採用する物理的プロセスの副作用として、プロセス中の猫を殺さないだけです。
マイクロ波の生産者として、加熱コイルと多数のセンサーを電子レンジに配置できます。後者は、現在のコンテンツが猫であるかどうかを決定し、電子レンジの代わりにコイルを使用します。
同じように、猫を乾かすのに適した電子レンジを作ることができれば、Blizzardは、最小化された状態を長期間維持するのに適したバージョンのSC2を作ることができます。
個人的に、私はそれを楽しむためだけに猫乾燥可能電子レンジにもっとお金を払うつもりです（私が誇らしげに指摘できる大きな猫乾燥適性ロゴがあると仮定します）。しかし、私は何時間も最小化されたままでいられるゲームを気にしません。
SC2は、特定の要件を満たすように設計されています。あなたの期待はそれらの一部ではありません。 SC2は自由に測定できます。しかし、ブリザードが要件の範囲にそれらすべてを含めるかどうかは、最終的には彼らの選択です。
あなたが本当に議論できることは、それがデザインの失敗だということです。常識では、ユーザーのかなりの部分が設計に混乱したり、設計に不満を感じたりしない限り、それで十分です。十分な数のユーザーがあなたの期待を共有していると述べれば、Blizzardはそれを放棄してデザインに含めるでしょう。これにより問題が実際のバグになり、Blizzardが修正します。
これは、仕様で定義されたソフトウェアが使用されていない場合だと思います。彼らが言うには
ゲームは、そのような長期間にわたって最小化された状態を保つようには設計されていません。
これは、「長期間」と見なされるもののどこかに定義があることを意味します。 「長期間」以上に渡ってプログラムを最小化すると、その仕様を超えてテストされたものを超えて（正式にこれをテスティングしたと仮定して）、何が起こるかは保証されません。もちろん、マニュアルに「このプログラムは10分を超えない時間だけ最小化するようにテストしただけです。これより長く最小化することは自己責任で行ってください！」というマニュアルがあればいいでしょう。
いいえ、これは本当にバグだとは思いません。私のオフィスでは、これは「ユーザートレーニングの問題」と呼ばれます（これはcommunication問題の一種です。この場合、最小化時間の最大期間が通知されなかったため、ユーザー）プログラムを適切に使用していないため。彼らがマニュアルに入れない限り、それはブリザードにとって大いに役立つというわけではない...
バグではありません。バグは、仕様に準拠していない動作です。ユースケースがサポートされていない動作であると仕様に記載されている場合、そのユースケースでの動作は有効であるかどうかにかかわらず、「仕様による」ものです。
このシナリオでは、ゲームまったく機能しているは未定義の動作と見なされる可能性があります。
私がそのプロジェクトの開発チームのリーダーだった場合、それをバグと呼びますが、それはソフトウェアの通常の動作期待を大きく外れているため、マイナーなバグと呼びます。もしそれがまったく取り組むつもりなら、おそらくそれをジュニアプログラマーや新入社員に、他の何よりも学習課題として割り当てるでしょう。
これらのマイナーなバグは追跡することをお勧めします。これらのバグは、広範囲に及ぶ可能性のある問題を示す可能性があるためです。たとえば、発生したデータ保存のバグ。どのようにして起こったのかはマイナーなようですが、データが失われている他のケースがあるかもしれません。バグ報告システムを使用することにより、同様の問題が発生したすべてのケースを見つけ、共通の要素があるかどうかを確認できます。複雑なシステムでは、このようなことを文書化しておくと、より深刻で微妙なバグを見つけるのに役立ちます。
私はここのほとんどの人に反対するつもりです。
元スタークラフト（元）プレーヤーとして、これが（または少なくとも）非常に一般的な動作であることを証明できます。ユーザーは24時間年中無休でゲームを離れ、チャットルームで自分の位置を保持し、再び戻ったときにゲームに参加します。更新されたBattle.netには改善の余地があるため、この必要性を減らすことができると思いますが、それでも多くのことが起こります。
それは、セッションが何らかの形で（形状またはフォームが）期限切れになった場合に、再接続せずにゲームに参加できないことを意味します。セッションの期限が切れた後にゲームに参加できるという事実は、私にとってバグです。ここで厄介なこと、そしてまだ実際に取り上げられていないことは、開発者がユーザーを理解する必要があることです。これはEdgeケースである可能性が非常に高いですが、非常に熱心なゲーマーに喜ばれるように設定する必要があるEdgeケースです。
技術的には、これは設計によるものであり、修正を意図しているものではないと主張することができます。それは私の目にはまだ欠点であり、バグとして分類するかどうかにかかわらず、最終的には彼ら次第です。それはプレイヤーが同意することを意味するものではありません。
とにかく、これまでに投稿されたものとは少し違う答えを出すと思いました。
バグは「ソフトウェアの意図された動作からの逸脱」として合理的に定義できます。
明らかに彼ら（そして彼らはそれが彼らの振る舞いを決定するための彼らのソフトウェアである）がソフトウェアがこのシナリオを処理することを意図していないので、それはバグのこの定義を満たさない。
しかし、私が言うことは、少なくとも、次善の策はこの条件を処理する方法です。
ガベージイン、ガベージアウト（つまり、ユーザーが何か愚かな、悪い、または予期しないことを行い、結果として何か悪いことが起こる）は、動作の標準としては不十分であると考えられています。少なくとも、この状態を処理する方法はよりエレガントである必要があります。
厳密にはバグではありませんが、Edgeケースの扱いが不十分です。
とはいえ、私が彼らだったとしても、修正する価値があるとは思えない（メリットが少なすぎて高額になる）とは言えませんが、将来の参考のために、彼らがより適切に処理できたかもしれないことをチームに伝えます。
バグの定義はソフトウェアの動作とは関係ありません。バグは、ソフトウェアの動作が意図と一致するかどうかに基づいて定義されます。そして、意図は何でしたか？ （ここではプログラマーを扱っているので、最初の文を明確にします。それ自体、バグを構成する可能性のあるソフトウェアの動作はありません）。
一般に、バグはソフトウェア開発者が修正するはずのものであることを覚えておいてください。したがって、バグの定義は、修正したいものに基づいています。たとえば、「50％以上の時間で正しく動作することは、将来のバージョンでリリースする予定の機能です」。 Anythingは、ソフトウェアがその特定の問題に対処することを意図していないふりをすることにより、バグではないと定義できます。したがって、実際には、バグを構成するのは純粋に政治的な考慮事項です。
（余談ですが、これは両方の方法を削減します。バグ修正にお金を払う必要はないが、新しい開発にお金を払う必要があるクライアントにとっては、「今考えただけの機能は実行しません」私が言及したことによって100％暗黙のうちに決定された」とは明らかにバグです。
バグを切り離さないことは考えません。 （設計上、意図的に）切断することになっていて、切断しない場合の唯一のバグです。機能リクエストを送信したものを呼び出します。
とはいえ、戦闘後にデータを失うことはそれがバグかもしれません。私はスタークラフトについてはあまり知りませんが、それは設計によるものではないと思います。