ソフトウェア製品の品質を評価する方法

Question

私には製品 X があり、バグ修正、機能拡張、新規開発などを含めて毎月クライアント C に納品しています。毎月、製品の品質を「保証」するよう求められます。

このために、私たちは実施したテストから収集された次のような多数の統計を使用します。

• 再オープン率 (再オープンされたバグの数/テストされた修正されたバグの数)
• 新規バグ率 (テスト中に発見された、回帰を含む新規バグの数/テストされた修正されたバグの数)
• 新しい機能強化ごとに、新しいバグ率 (この機能強化で見つかったバグの数/工数)

その他さまざまなフィギュア。

理由には触れませんが、毎回すべてをテストすることは不可能です。

そこで、私の質問は次のとおりです。

ソフトウェアに残っているバグの数と種類を推定するにはどうすればよいですか?製品が良好であることを確認するには、どのようなテスト戦略に従う必要がありますか?

これが少し未解決の質問であることは承知していますが、単純な解決策がないことも承知しています。

ありがとう。

Answer 1

アプリ内のバグの数を正確に見積もることはできないと思います。正式な証明を可能にする言語とプロセスを使用しない限り、本当に確信を持つことはできません。おそらく、バグの数を見積もるよりも、プロセスをセットアップしてバグを最小限に抑えることに時間を費やしたほうがよいでしょう。

あなたができる最も重要なことの 1 つは、優れた QA チームと優れた作業項目追跡を用意することです。毎回完全な回帰テストを行うことはできないかもしれませんが、前回のリリース以降にアプリに加えた変更のリストがあれば、QA 担当者 (または担当者) は、次の部分にテストを集中させることができます。影響を受けると予想されるアプリ。

もう 1 つ役立つのは単体テストです。コードベースをより多くカバーすればするほど、ある領域での変更が他の領域に誤って影響を与えていないという確信が高まります。何かを変更して、それがアプリの別の部分に影響を与えることを忘れてしまうことがあり、単体テストで問題がすぐに示されたため、これは非常に便利だと思いました。単体テストに合格したからといって、何も壊れていないことは保証されませんが、加えた変更が機能しているという確信を高めるのに役立ちます。

また、これは少し冗長で明らかですが、優れたバグ追跡ソフトウェアを使用していることを確認してください。:)

Answer 2

問題は、誰が統計情報の提供を要求するかということです。

技術者ではない人であれば、統計を偽造してください。「偽の」というのは、あなたが言及した種類の「必然的に無意味だが実際の数字を提供する」ことを意味します。

CS の経験のない技術者であれば、停止問題について説明する必要があります。停止問題は決定不可能であり、残りのバグを数えて分類するよりも簡単です。

ソフトウェアの品質に関する指標やツールは数多くあります (コード カバレッジ、循環的複雑さ、コーディング ガイドラインとそれを適用するツールなど)。実際には、できる限り多くのテストを自動化し、自動化されていないテストを人間のテスターに​​できるだけ多く実行してもらい、祈ることです。

Answer 3

シンプルにすることが最善の方法だと思います。バグを重大度別に分類し、重大度の降順に対処します。

こうすることで、可能な限り最高品質のビルドを引き渡すことができます (複雑な統計ではなく、残っている重大なバグの数が製品の品質を評価する方法です)。

Answer 4

アジャイル手法のほとんどは、このジレンマにかなり明確に対処しています。すべてをテストすることはできません。また、リリースする前に無限にテストすることもできません。したがって、手順はバグのリスクと可能性に依存することになります。リスクも可能性も数値です。両方の積により RPN 番号が得られます。数が 15 未満の場合は、ベータ版が出荷されます。10 未満に下げることができた場合は、製品を出荷し、将来のリリースでバグが修正されるようにプッシュします。

リスクを計算するにはどうすればよいですか?

クラッシュの場合は、クラッシュの場合は5ですが、5未満の数字を回避できます。バグにより機能が低下する場合は 4

確率を計算するにはどうすればよいですか?

実行するたびにそれを再生成できますか。その場合は 5 です。提供された回避策を実行してもクラッシュが発生する場合は、5 未満です

そうですね、他にこの制度を利用している人がいるかどうか知りたいのですが、その効果を知りたいと思っています。

Answer 5

紐の長さはどのくらいですか?結局のところ、高品質の製品とは何でしょうか?バグはある程度のイエスの兆候を示しますが、他の多くの要因が関係しており、単体テストのカバレッジは IMO の重要な要素です。しかし、私の経験では、製品が品質とみなされるかどうかに影響を与える主な要因は、解決しようとしている問題をよく理解しているかどうかです。多くの場合、製品が解決しようとしている「問題」が正しく理解されておらず、開発者は実際の問題ではなく、頭の中で具体化した問題の解決策を考え出すことになり、その結果「バグ」が作られてしまうのです。 。私は反復の強力な支持者です アジャイル そうすれば、製品は常に「問題」にアクセスでき、製品がその目標から大きく逸脱することはありません。

Answer 6

私が聞いた質問は、ソフトウェアのバグをどのように見積もればよいでしょうか?というものでした。品質を確保するにはどのようなテクニックを使用すればよいでしょうか?

フルコースを実行するのではなく、いくつかのアプローチを紹介します。

ソフトウェアのバグを推定するにはどうすればよいですか?

履歴から始めます。テスト中に (できれば) 見つかった数がわかり、事後に見つかった数もわかります。これを使用して、バグを発見する効率を見積もることができます (DDR - 欠陥検出率はこれの名前の 1 つです)。一定期間、DDR が一貫している (または改善している) ことを示すことができれば、製品がリリースされた後に見つかるであろうリリース後の欠陥の数を推測することで、リリースの品質についてある程度の洞察を得ることができます。

良好な品質を確保するにはどのようなテクニックを使用すればよいですか?

バグの根本原因分析により、バグのある特定のコンポーネント、バグのあるコードを作成した特定の開発者、完全な要件が欠けていると実装が期待と一致しないという事実などが指摘されます。

プロジェクトレビュー会議を開催して、何が良かったのかをすぐに特定して、それらを繰り返すことができ、何が良くなかったのかを特定し、二度と繰り返さない方法を見つけます。

これらが良いスタートになることを願っています。幸運を！

Answer 7

単体テストに重点を置くべきだというのがコンセンサスのようです。バグ追跡は製品の品​​質を示す良い指標ですが、それはテスト チームとしてのみ正確です。単体テストを採用すると、コード カバレッジの測定可能な指標が得られ、回帰テストが提供されるため、先月以降何も問題が発生していないと確信できます。

私の会社はシステム/統合レベルのテストに依存しています。回帰テストが不足しているために、多くの欠陥が導入されているのがわかります。開発者による要件の実装がユーザーのビジョンから逸脱する「バグ」は、Dan と rptony が述べたように、アジャイル手法によって最もよく対処できる別個の問題のようなものだと思います。