既知のバグを含む製品をいつ出荷できますか？

既知のバグを含む製品をいつ出荷できますか？

私はあなたが「既知の」バグについて話していると仮定します（そうでなければ、質問は無意味です）。さて、答えはこれらの要因に依存します：

1）ユーザーは誰で、バグが見つかった場合にどのように受け入れますか？

2）バグの潜在的な影響（損傷）は何ですか？

3）バグを修正するためにソフトウェアの出荷を遅らせることは可能ですか？

4）最も重要なこと：ソフトウェアに何を期待しますか？市場投入までの時間は？品質？顧客がバグを見つけるのに十分な時間ソフトウェアを使用しているかどうかを確認しますか？

バグのないソフトウェアなどは存在しないため、常に大丈夫でなければなりません。

その判断の呼び出し。バグは多くのことがあることを忘れないでください。機能の主要部分が完全に機能しない場合は、最初に修正します。プログラムの有用性に最小限の影響を与えるか、実際の影響を与えないマイナーなものであれば、スライドさせてください。

したがって、コスト/利益の観点から見てください。

バグを修正する総費用とリスクが、そこに存在するバグから生じるどんな問題やマイナスの影響よりも大きい場合、既知のバグを持つ製品を出荷します。

したがって、リリース前に2週間のテスト期間があり、小さなバグが見つかった場合、問題は...チームがアプリケーションとインストールの再テストに費やす必要がある追加の2週間に相当するバグを修正することです（ソフトウェアを作成する際のステップを忘れることが多い）？ソフトウェアが遅れている場合、評判や販売のコストはいくらですか？人々は怒りますか？主要な機能を時間通りに提供できれば、彼らは小さなバグを抱えて生きることができるでしょう。

リスクには、バグを修正するだけでなく、新しいインストールを作成することから生じる可能性のある問題でも、新しい問題を引き起こすリスクが含まれます。

マイナスの影響は、バグを報告する顧客に対処する時間と労力の両方、および評判の損傷などです。

バグにはさまざまな重大度があります。私が働いたソフトウェア会社では、優先度がP0からP4の順にバグを分類しています。

P0ソフトウェアは機能しない/クラッシュせず、顧客のビジネスに損害を与える可能性があります。P1設計どおりに機能せず、コア機能で一貫してクラッシュしますP2時々クラッシュするか、サイド機能の一部が機能しない場合があります。P3ソフトウェアの一部の要素が、設計/予想されるP4化粧品の問題として機能していません。

P4がソフトウェアにそれほど影響を与えないため、P4が修正されない場所で働いてきました。

お使いのソフトウェアにP3 / P4の問題が知られている場合、出荷しても大丈夫だと思います。これをリリースノートに記載し、作業中です。

私が知っていたP0、P1、またはP2の問題があるソフトウェアをリリースしたことはありません。

「既知の問題」と呼ばれます。Google、Microsoft、Appleなどはすべて、既知および未知のバグを含む製品を出荷しています。それらを最小化しようとしますが、完全になるまで待たないでください。早く出荷し、頻繁に出荷します。

バグなしでソフトウェアを出荷することはできません。私が提供できるアドバイスは、お客様にバグがあるとお客様に言われる状況よりも、お客様に「このバージョンではそれができませんが、これを修正する予定です」と言う方が良いということです。

「機能」の場合！;）

真剣な注意として、あなたが完璧なテストセットアップを備えた完璧なプログラマーでない限り、すべてのコードパスを完全にテストし、最終的に存在する可能性のあるものでなければ、バグのない製品を出荷することはありえません。

したがって、テストで遭遇したすべてが修正された場合は、実用的であり、余分なものは必要に応じて修正する必要があります。

顧客に正直である限り、バグとともに出荷できます。既存のすべてのバグについて彼らに伝えることは、あなたがあなたのソフトウェアについての十分な知識を持っていることを彼らに示し、それは実際に十分にテストされています（そうであれば..）:)

明らかに、最良の方法は、バグのある出荷を避けることです。

製品をすべて出荷しないよりも、既知の問題のリストを使用して時間どおりに出荷する方が良い場合がよくあります。

プロジェクトの人々の信頼を与え、プログラミングの世界では、物事の一つは、彼らが解放しているかどうかで、スケジュールとスケジュールがするかどうかを保持しています。

これが、未解決の問題がまだある場合でも、Ubuntuが半年ごとにリリースを出荷する理由です。

いい経験則は、「このバグは目玉ですか？」

バグによって「ハッピーパスシナリオ」が失敗する場合、絶対にそのバグを同梱しないでください。

バグによって「ハッピーパスへの接線シナリオ」が失敗し、回避策がない場合は、そのバグとともに出荷しないでください。

バグが文書化されており、既知の回避策がある場合は、おそらくそのバグとともに出荷しても問題ありません。

消費者の観点から...決して。私のポイントは、あなたがソフトウェアに大きなバグがあることを知っている限り、決してそれを出荷すべきではないということです。ただし、ソフトウェアの生産サイクルがビジネスモデルに害を及ぼす可能性のある段階にあり、それらが軽微なバグである場合、自然の力（ビジネス）はこれを無効にします：（i）ソフトウェアのセキュリティを侵害します

人々が言っ​​たように、それは非常に広範な質問です。実際に私は興味深い視点に立ちます。あなたが主張するいわゆる「バグ」は、テスターに​​よって発見された障害だけです。無限のさらなる抜け穴がある可能性があります。ある大学院セミナーで尊敬されている教授から聞いた興味深い話を思い出してください。スカンジナビアの国の1人が「手書き認識可能な」タイプの投票マシンを使用したとき、特定の人々は悪意のあるSQLコード（システムは通常の入力として取り込みました）。

FMEA（障害モードと影響分析）と呼ばれるものがあります。既知のバグが重要であるかどうかに基づいて判断することは非常に便利です。

1. 発生
2. 重大度
3. 検出

別の決定要因は、欠陥が最後のリリースにどのように関係するかです。バグが新しいが壊れた機能の一部である場合、非機能性は機能の退行を表すものではありません。さあ、出荷してください。

一方、欠陥が原因で既存の顧客に役立つと知られている既存の機能が失われる場合、リリースをブロックする必要があります。このようなリリースは顧客にとってダウングレードであり、あなたの利益にも彼らの利益にもなりません。

これにはグレーの濃淡が含まれる場合があります。コア機能のリグレッションは決して外に出るべきではありません。周辺機能のリグレッションは、リリースに関心を示した新しい機能が含まれている場合、ユーザーを導く可能性があります。それらの顧客に影響します。とにかくデフォルトでオフになっている非常に実験的な機能の欠陥により、リリースが遅れることはありません。