私はあなたが「既知の」バグについて話していると思います（この質問はそれ以外では意味がありません）。まあ、答えはこれらの要因に依存します：
1）ユーザーは誰ですか？バグが見つかった場合、どのようにしてバグを受け入れますか？
2）バグの潜在的な影響（損傷）は何ですか？
3）バグを修正するためにソフトウェアの出荷を遅らせることは可能ですか？
4）最も重要なこと：ソフトウェアに何を期待していますか？市場投入までの時間？品質？顧客がバグを見つけるのに十分な期間ソフトウェアを使用しているかどうかを確認しますか？
バグのないソフトウェアなどは存在しないので、常に問題はありません。
その判断の呼びかけ。バグにはさまざまなものがあります。機能が完全に機能しない主要な機能である場合は、最初に修正します。プログラムの有用性にほとんど影響を与えない、またはまったく影響を及ぼさないマイナーなものである場合、それをスライドさせるかもしれません。
ですから、コスト/利益の観点から見てください。
既知のバグが含まれる製品を出荷するときは、バグを修正することによる総コストとリスクが、バグが存在することによって発生するあらゆる問題と悪影響に勝る場合を上回ります。
したがって、リリース前に2週間のテスト期間があり、小さなバグが見つかった場合、問題は...アプリケーションを再テストするためにチームが現在費やす必要のある2週間分のバグを修正することです。 インストール（ソフトウェア作成のステップについてよく忘れられる）？ソフトウェアが遅れた場合、評判や販売にかかる費用はどのくらいですか？人々は怒るのでしょうか？主要な機能を予定どおりに提供できれば、マイナーなバグが発生しても喜んで対応できます。
リスクには、バグの修正だけでなく、新しい問題を引き起こすリスクだけでなく、新しいインストールの作成から生じる可能性があるものも含まれます。
マイナスの影響とは、バグを報告している顧客に対処する時間と労力の両方であり、評判の低下などです。
バグにはさまざまな重大度があります。私がこれまで取り組んだソフトウェア会社では、優先度の順にバグをP0からP4に分類しています。
P0ソフトウェアが機能せず、クラッシュして顧客のビジネスに損害を与える可能性がありますか。 P1設計どおりに機能せず、コア機能で一貫してクラッシュするP2ときどきクラッシュする、またはサイド機能の一部が機能しない可能性がある。 P3ソフトウェアの一部の要素が、設計済みまたは期待どおりのP4化粧品の問題として機能していません。
私は、P4がソフトウェアに与える影響が非常に小さいために修正されない場所で働いてきました。
お使いのソフトウェアにP3/P4の既知の問題がある場合は、出荷しても問題ないと思います。これをリリースノートに記載し、現在作業中であることを通知します。
私が知っていたP0、P1、またはP2の問題があるソフトウェアをリリースすることはありません。
これは「 既知の問題 」と呼ばれます。 Google、Microsoft、Appleなどはすべて、既知および未知の両方のバグを含む製品を出荷しています。それらを最小限に抑えるようにしてください。ただし、完璧になるまで待ちません。速く発送し、頻繁に発送します。
バグのないソフトウェアを出荷することはできません。私ができるアドバイスは、お客様にバグがあるとお客様に言われるよりも、「このバージョンではそれができないので、これを修正するつもりです」と常にお客様に言うほうがよいということです。
経験則としては、「このバグはショッパーですか？」
バグが原因で「ハッピーパスシナリオ」が失敗した場合、絶対はそのバグに同梱されません。
バグによって「ハッピーパスへの正接」シナリオが失敗し、回避策がない場合は、そのバグを同梱しないでください。
バグが文書化されており、既知の回避策がある場合、そのバグを同梱しても問題ないでしょう。
消費者の観点から...決して。私の要点は、ソフトウェアに大きなバグがあることを知っている限り、決して出荷すべきではありません。ただし、自然の力（ビジネス）は、ソフトウェアの生産サイクルがビジネスモデルに悪影響を与える可能性があり、次のような軽微なバグである場合、これを無効にします。
人々が言ったように、それは非常に広い質問です。それは実際に私を興味深い視点に連れて行きます：あなたが主張するいわゆる「バグ」はあなたのテスターによって発見された欠陥だけです。無限に多くの抜け穴があるかもしれません。ある大学院セミナーで尊敬される教授から聞いた興味深い話を思い出しました。スカンジナビア諸国の1人の人々が「手書き認識可能な」タイプの投票マシンを使用したとき、特定の人々は悪意のあるSQLコード（システムは通常の入力として取り込んだ）。
もう1つの決定要因は、欠陥が最後のリリースとどのように関連しているかです。バグが新しいが壊れた機能の一部である場合、非機能性は機能性の低下を表すものではありません。どうぞ、発送してください。
一方、欠陥が原因で既存の顧客に役立つことがわかっている既存の機能が失われた場合は、リリースをブロックする必要があります。そのようなリリースはあなたの顧客にとってdowngradeであり、あなたの利益にも彼らの利益にもならないでしょう。
これには灰色の色合いがある場合があります。中核機能の退行は決して外に出るべきではありません。リリースに関心を示した新機能がリリースに含まれている場合、周辺機能の一部の退行がユーザーをリードする可能性があります。それはそれらの顧客に影響を及ぼします。とにかくデフォルトでオフになっている非常に実験的な機能の欠陥により、リリースが遅れることはありません。
それが「特徴」だと！ ;）
真剣に注意してください。あなたが完璧なテスト設定を備えた完璧なプログラマーでなければ、すべての単一のコードパスを完全にテストし、最終的には存在する可能性がある場合、バグのない製品を出荷することはまずありません。
したがって、実用的になるようにしてください。テストで遭遇したものがすべて修正されている場合は、必要に応じて追加の修正を行う必要があります。
あなたがあなたの顧客に正直である限り、あなたはバグで出荷することができます。既存のすべてのバグについて彼らに伝えることは、あなたがあなたのソフトウェアについて十分な知識を持っていること、そしてそれが実際に十分にテストされていることを示しています（もしそうであれば）。 :)
明らかに、最良のことはバグのある出荷を避けることです。
多くの場合、既知の問題のリストを備えた製品を予定どおりに出荷することは、まったく出荷しないよりも優れています。
プロジェクトに人々に自信を与えるプログラミングの世界の1つは、リリースscheduledがあるかどうか、およびスケジュールholdsがあるかどうかです。
このため、未解決の問題があっても、Ubuntuはリリースを半年ごとに出荷しています。
[〜＃〜] fmea [〜＃〜] と呼ばれるものがあります（失敗モードと影響分析）既知のバグが重要であるかどうかに基づいて決定することは非常に役立ちます。
- 発生
- 重症度
- 検出