横軸にテスト工程でのテストの進捗（工数、項目、日）を、縦軸にテストで発生したエラーの累計件数をとり、テスト対象の信頼性を評価するために使用するグラフ。テスト開始直後は多くのエラーが発生し、テストの進捗にしたがって、エラーが減少して収束すれば、信頼性は安定したとみなせる。この様な事象を記述するモデルとして、ゴンペルツ曲線や遅延S字型NHPPモデルを使用する。

テスト対象を実行しないで確認するテストをいう。静的テストには、例えば、コードのレビューや、静的解析がある。

発生したソフトウェア故障数あるいは発見されたエラー数に基づく確率統計モデル。

テストを実行したとき、どの程度網羅的にテストしたかを表す指標。よく使用されるものにコードカバレッジがある。コードカバレッジは、ソースコードをどの程度網羅したかを表す。命令網羅（C0）は、ソース内のコードステートメントをどの程度実行したかを、分岐網羅（C1）は、分岐をどの程度実行したかを、条件カバレッジ（C2）は、条件をどの程度実行したかを表す。例えばソース内の全ステートメントを実行すると、C0カバレッジ率=100となる。

テスト対象を実行して確認するテスト。

各プロセスに設ける、「関所」のこと。あらかじめ定められている条件を満たさないと通過できず、先に進むことができない。フェーズゲートにより早期に問題点やリスクを把握して、対策する。

開発プロセスが適正に実施されているかどうかを監査し、問題点を見つけ出し、改善点を提示していくプロセスアセスメント手法。成果物を作りこむ「プロセスの品質」をアセスメントし、「成果物（仕様書・設計書やプログラム）の品質」を向上させる。

プロセスで実行される活動を、当事者以外のメンバも把握できるようにすること。情報を共有化して、活動の状況を関係者全員が理解することで、問題を早く発見して、対応、改善に結びつけることを目的とする。見える化の方法はさまざまあるが、表、グラフ､図による方法や、緊急用赤色灯のように音や光で状況を示すこともある。
ITインフラを活用して、情報の電子化、実時間での更新により、情報の共有化・活用を推進すると、効率よく見える化ができる。

対象物が目的に対して、適切かつ必要十分であるかを確認すること。代表的なレビューとして、管理者が、プロセスや計画の予実績を確認・評価するマネジメントレビューや、ソフトウェアの成果物を評価するために行う設計・開発レビューがある。

Plan（計画）、Do（実行）、Check（チェック）、Act（改善）の略語。PDCAを繰り返すことで開発／管理といったプロセスを改善することができる。

Quality：品質、Cost：コスト、Delivery：納期のこと。QCDを測定してプロジェクトの成否を判断する。

ソフトウェア品質の知識体系（Software Quality Body of Knowledge）のガイドとして発行された。ソフトウェア品質に関する知識を、「品質の基本概念」、「品質マネジメント」、「品質技術」の3つのカテゴリに分けて、それぞれをさらに詳細な知識領域、トピックへと詳細化している。ソフトウェア品質に関する辞書として使用できる。