私は製品 X を持っており、これをクライアント C に毎月提供しています。これには、バグ修正、機能強化、新しい開発などが含まれます。) 毎月、製品の品質を「保証」するように求められます。
このために、以下のようなテストから得られた多くの統計を使用します。
など、さまざまなフィギュア。
説明しない理由により、毎回すべてをテストすることは不可能です。
だから、私の質問は：
ソフトウェアに残っているバグの数と種類を見積もるにはどうすればよいですか? 製品が優れていることを確認するために、どのようなテスト戦略に従う必要がありますか?
これが少し未解決の問題であることは承知していますが、単純な解決策がないことも知っています。
ありがとう。
問題は、統計情報の提供を誰に要求するかです。
技術者でない場合は、統計を偽造してください。「偽物」とは、あなたが言及した種類の「必然的に意味のない、しかし実数を提供する」ことを意味します。
CS のバックグラウンドを持たない技術者の場合は、停止の問題について説明する必要があります。停止の問題は判断できず、残りのバグを数えて分類するよりも簡単です。
ソフトウェアの品質に関する多くの指標とツールがあります (コード カバレッジ、循環的複雑度、コーディング ガイドラインとそれらを実施するツールなど)。実際には、できるだけ多くのテストを自動化し、人間のテスターに自動化されていないテストをできるだけ多く実行させてから、祈ることがうまくいきます。
アプリのバグの数を実際に見積もることはできないと思います。正式な証明を可能にする言語とプロセスを使用しない限り、本当に確信を持つことはできません. バグの数を見積もるよりも、バグを最小限に抑えるためのプロセスの設定に時間を費やす方がよいでしょう。
あなたができる最も重要なことの 1 つは、優れた QA チームと優れた作業項目の追跡を行うことです。毎回完全な回帰テストを行うことはできないかもしれませんが、前回のリリース以降にアプリに加えた変更のリストがあれば、QA 担当者 (または担当者) は、そのテストを次の部分に集中させることができます。影響を受けると予想されるアプリ。
役立つもう1つのことは、単体テストです。カバーしたコードベースが多ければ多いほど、ある領域での変更が別の領域に誤って影響を与えていないという確信が持てるようになります。何かを変更すると、それがアプリの別の部分に影響を与えることを忘れることがあり、単体テストで問題がすぐに示されるため、これは非常に便利です。単体テストに合格しても、何も壊れていないことは保証されませんが、行った変更が機能しているという確信を高めるのに役立ちます。
また、これは少し冗長で明白ですが、優れたバグ追跡ソフトウェアがあることを確認してください。:)
シンプルにするのが一番だと思います。バグを重大度で分類し、重大度の低い順に対処します。
このようにして、可能な限り最高品質のビルドを引き渡すことができます (いくつかの複雑な統計とは対照的に、残っている重大なバグの数は、製品の品質を評価する方法です)。
アジャイル方法論のほとんどは、このジレンマに明確に対処しています。すべてをテストすることはできません。また、リリースする前に無限にテストすることもできません。したがって、手順はバグのリスクと可能性に依存することです。リスクも可能性も数値です。両方の積によって RPN 番号が得られます。数が 15 未満の場合は、ベータ版を出荷します。10 未満にできる場合は、製品を出荷し、将来のリリースで修正されるようにバグをプッシュします。
リスクの計算方法は？
クラッシュの場合は 5 クラッシュであるが回避策を提供できる場合は 5 未満です。バグによって機能が低下する場合は 4 です。
可能性を計算する方法は？
実行するたびに再現できますか? 5 です。提供された回避策でもクラッシュする場合は 5 未満です。
さて、私は他の誰かがこのスキームを使用しているかどうかを知りたいと思っており、これに関する彼らのマイレージを知りたいと思っています.
私が聞いた質問は、ソフトウェアのバグをどのように見積もるのですか？品質を確保するためにどのようなテクニックを使用しますか？
フルコースを通過するのではなく、ここにいくつかのアプローチがあります。
ソフトウェアのバグを見積もるにはどうすればよいですか？
履歴から始めて、テスト中に（うまくいけば）何個見つけたか、そして事後に何個見つかったかを知っています。これを使用して、バグを見つけるのにどれだけ効率的かを見積もることができます（DDR-欠陥検出率はこれの1つの名前です）。一定の期間、DDRが一貫している（または改善している）ことを示すことができれば、製品がリリースされた後に検出されるリリース後の欠陥の数を推測することで、リリースの品質に関する洞察を提供できます。
品質を確保するためにどのようなテクニックを使用しますか？
バグの根本原因分析により、バグのある特定のコンポーネント、バグのあるコードを作成する特定の開発者、完全な要件がないと実装が期待と一致しないという事実などがわかります。
プロジェクトレビュー会議では、何が良かったのか、何が悪かったのかをすばやく特定し、それらを二度と行わない方法を見つけます。
うまくいけば、これらはあなたに良いスタートを与えるでしょう。幸運を！
単体テストに重点を置くべきだというのがコンセンサスのようです。バグ追跡は製品の品質を示す良い指標ですが、正確なのはテスト チームだけです。単体テストを使用すると、コード カバレッジの測定可能なメトリックが得られ、回帰テストが提供されるため、先月から何も壊れていないことを確認できます。
私の会社は、システム/統合レベルのテストに依存しています。回帰テストが不足しているため、多くの欠陥が導入されています。開発者の要件の実装がユーザーのビジョンから逸脱する「バグ」は、ダンとrptonyが述べたように、アジャイル方法論によって最もよく対処される別の問題のようなものだと思います。
ひもの長さはどれくらいですか? 最終的に高品質の製品を作るものは何ですか? バグはイエスの兆候を示しますが、他の多くの要因が関係しています。IMO では、単体テストのカバレッジが重要な要因です。しかし、私の経験では、製品が品質と見なされるかどうかに影響を与える主な要因は、解決されている問題をよく理解することです. 多くの場合、製品が解決しようとしている「問題」が正しく理解されておらず、開発者は実際の問題ではなく、頭の中で具体化した問題の解決策を発明することになり、「バグ」が作成されます。 . 私は、反復的なアジャイル開発の強力な支持者です。この方法では、製品は常に「問題」にアクセスし、製品は目標から遠く離れることはありません。