ソフトウェア開発において、品質とは何を意味しているのだろうか？今日の使われ方として、Mike Bria氏(リンク)は次のように述べている：日常より多く見られる使われ方としては、「品質」は「価値があること」のかわりに「欠陥がないこと」を示している。
次に彼は、以下のような考えを述べた(リンク)：
「品質」は、私達の消費者のための機能的/審美的なユーティリティの尺度として使用されるべきであり、欠陥の尺度として使われるべきではありません。実際 に、欠陥がおおむねないことが前提とされるべきです。プロフェッショナルであるということには、当然このことが含まれるはずです。 ですから：ここで私が提案するのは、ソフトウェアのプロフェッショナルとして、そしてビジネスマンとして、「欠陥がないこと」を表すために「品質」という言葉を使うのをやめましょう。
Mikeは、より欠陥が少ないという見方の品質ではなく、消費者の使用に適したものとしての品質に焦点があっていれば、私達は人々に脆弱ではないコードを 書くようにすると考えている。彼は、欠陥がほとんどないという意味で品質が高いとユーザが言うような製品があるとは考えられない。けれども、それはまさに 私達がソフトウェアで甘んじて受け入れていることである。
Agile Testing: A Practical Guide for Testers and Agile Teams(参考記事・英語)の共著者であるLisa Crispin氏は、「私は欠陥を測ることがずっと好きではなかったので、それをどう呼ぶかを考えるのは難しいです。」とコメントしている。
Christian Vest Hansen氏は、Robert Glass氏(リンク)の著書を引用し、品質について次のように述べている：
...次の特性の集合です：移植性、信頼性、効率性、使いやすさ、テスト容易性、分かりやすさ、そして変更容易性。
これらの各特性の重要度の位置付けはプロジェクトにより異なるかもしれませんが、品質はこれら中の一つだけになるはずがありません。あるプロジェクトでは移植性は全く気にしないかもしれません。そして信頼性だけのある製品は、高品質の製品とは考えられません。
James Bach氏(リンク)は、従来の品質の考え方はソフトウェア開発に埋め込まれた誤った考えであると思っている：「製品の品質は開発チームによって製品に組み込まれて いる。彼らはユーザの要求を満たすために規律のある工学プラクティスに従ってソースコードを設計することによって、品質を生み出す。」代わりに彼は、新し い考えを提案している：
製品は、天候の影響を受けやすい庭園のように、動的に配置されるものです。高品質の製品では、長い期間をかけて上手に手入れをしたり雑草を取ることが必要 となります。本当の庭師と同様に、私達の作物を育てる際、私達は全能でもなければ全てを知っているわけでもありません。進めていくにつれて、私達は条件や 製品の状態をレビューします。私達は問題を予期して対策を講じようとしたり、発生した問題を解決するために対応します。私達の技術で出来ることと出来ない ことを理解しようとし、それを受けて私達の顧客の期待に対処します。私達は製品が常に腐敗しやすく、顧客の好みは様々であることを知っています。私達は、 ほぼ完璧な作物が、腕の悪いシェフによって後で台無しになることがあることも知っています。品質は、かなりの程度、私達の手を離れたところにあるのです。
長年の間、機能したものや失敗したもの（あるいは機能していたが、その後動かなくなったもの）を見た結果として、私は品質は短命であると考えています。時 には、それは十分かもしれません。十分より、より優れているかもしれません。しかし、それはだんだんなくなっていくのです；自然の何かのように、必ず次第 になくなっていくのです。
最後に、JB Rainsberger氏(リンク)は次のように述べている：「私達が客観的に測定可能な品質を追いかけるのをやめたとき、私達はもう一度特定の人々を満足させよう とします。それは私達がもっと適切でもっと有益なソフトウェアを届ける助けになると、私は推測しています。」
品質が何を意味するのかについて、明確な同意はないと思われるだろう。その代わり、品質は欠陥の尺度ではないということは一致している。著者らは、私達はありのままを言う必要があると言う点で意見が同じであり、私達は欠陥を欠陥として認めるべきである。