ソフトウェアテストと品質

ブログの切れ端

---

ソフトウェアテストと品質

ソフトウェアの「品質」とは何かというのが私の中で明確にできていないので、それを調べて整理していこうと思います。

まずは「品質」という言葉のイメージを馴染みのある用語から整理し、その後ソフトウェアの品質の定義、ソフトウェアテストと品質の関係について整理していきます。

「品質」という言葉のイメージ

自分自身「品質」の定義は明確にできていないものの、「品質が高い」には以下のような具体的なイメージを持っていました。「品質が低い」はこれらの逆です。

• 提供する機能が正しく動く
• 障害の件数、バグの報告件数が少ない
• ユーザにとって使いやすい UI / UX になっている
  • 操作に迷わない
  • レスポンスが早い
  • 演出（アニメーションなど）が楽しい
  • etc

※ざっくりした括りになってしまいますが、GUI を持つソフトウェアを前提としています

製品の「品質」について言及するとき、しばしば「当たり前品質」、「魅力的品質」といった言葉が使われると思います。以下のようなグラフを見たことがある人もいるのではないでしょうか^[1]。

引用元：(2025/03, SHIFT ASIA) 狩野モデルから探る品質のあり方とは

この「当たり前品質」、「魅力的品質」と言った言葉は、誰かが口語で語っているものではなく^[2]、1980 年代に提唱された「狩野モデル」という顧客が製品に求める品質をモデル化したものです。恥ずかしながら学術用語だということを知りませんでした...

狩野モデルでよく言及される「当たり前品質」、「一元的品質」、「魅力的品質」の説明は以下の通りです。

• 当たり前品質・・・あって（充足）も当たり前と受け取られるが、ない（不充足）と不満に感じる品質要素。ソフトウェアを例に挙げれば、「機能通り正しく動く」という品質が当たり前品質に該当します。ソフトウェアが正しく動くことは利用者（ユーザー）にとっては当たり前のことですが、仮に求める機能に不具合があればユーザーの不満を引き起こします。
• 一元的品質・・・あると嬉しいものの、ないと不満につながる品質要素。これは例えば、ソフトウェアの使いやすさなどが該当します。実際、ソフトウェアが正しく動き、使いやすければユーザーの満足度は上がりますが、仮に不具合はなくてもデザインや操作性がイマイチで、UX（ユーザーエクスペリエンス）や UI（ユーザーインターフェイス）が見劣りすれば、結果的にユーザーの不満が高まるでしょう。
• 魅力的品質・・・本来なくても構わないものの、あると嬉しい品質要素。YouTube などの動画配信サービスを例に挙げれば、動画の再生速度を調整する機能などが該当します。ストレスなく動画を観るという本来の品質を満たしている限り、再生速度の調整機能はなくても問題ないと言えますが、なるべく短い時間で動画を見たいという人にはより高い満足度を提供することができます。

引用元：(2025/03, SHIFT ASIA) 狩野モデルから探る品質のあり方とは

上記の説明から、私の「品質」のイメージを狩野モデルに当てはめると以下のようになります。

• 提供する機能が正しく動く → 当たり前品質
• 障害の件数、バグの報告件数が少ない → 当たり前品質
• ユーザにとって使いやすい UI / UX になっている
  • 操作に迷わない → 一元品的質
  • レスポンスが早い → 一元品的質
  • 演出（アニメーションなど）が楽しい → 魅力的品質

"ユーザから見た" ソフトウェアの品質とは何かの全体像が見えてきました。

個人的には「『使いやすい』にも種類があるな」と考えていたのが「一元品的質」、「魅力的品質」という言葉によって整理できたのが良かったです。ちなみに上記のイメージを要件定義の文脈で考えると、以下のように当てはめることができると思います。

• 提供する機能が正しく動く → 機能要求
• 障害の件数、バグの報告件数が少ない → 非機能要求「信頼性要件」
• ユーザにとって使いやすい UI / UX になっている
  • 操作に迷わない → 非機能要求「ユーザビリティ要件」
  • レスポンスが早い → 非機能要求「パフォーマンス要件」
  • 演出（アニメーションなど）が楽しい → 非機能要求「ユーザビリティ要件」

脚注

1. 製造業でよく使われるイメージがありますが、検索してみた印象としてはソフトウェア業界でも使われることがあるようです ↩︎

2. 誰かが言い出だした話し言葉が浸透したものなのかと勝手に思っていました ↩︎

ホワイトボックステスト

codecov の「カバレッジ」の定義

• ホワイトボックステスト
  • プログラムの論理構造の正しさをテストする
• 手法
  • 制御パステスト
  • ステートメントカバレッジ
    • コード内の命令文を少なくとも 1 回実行する
    • 記述されているコードをさらえれば良い。例えば else が書かれていない条件分岐のコードはステートメントカバレッジでは else のときのテストは行わない。
    • そのため、ステートメントカバレッジは、分岐条件の全てはカバーできない場合がある。
  • ブランチカバレッジ
    • 条件分岐のコードに対してそれぞれの判定条件が true / false の結果を少なくとも 1 回ずつ持つようにテストケースを書く。

https://docs.codecov.com/docs/about-code-coverage

https://docs.codecov.com/docs/frequently-asked-questions#how-is-coverage-calculated

ここまで見てきた通り、本節で言及している KA 「ソフトウェア品質 Software Quality」では、

• 「品質は要求の重要な特性の 1 つである」
• ソフトウェア品質制約 Quality of Service Constraints
• 技術的制約 Technology Constraints

のように KA「ソフトウェア要求 Software Requirements」で定義されている概念が使われています。そのため、「ソフトウェア品質 Software Quality」を理解するためには、KA「ソフトウェア要求 Software Requirements」において「ソフトウェア品質」がどのような位置付けかを理解しておく必要があります。ここでは、SWEBOK における「ソフトウェア要求」のさわりだけ説明します。

SWEBOK では、「ソフトウェア要求」を以下の図のように分類しています。この図を見ると、ソフトウェア品質制約

（SWEBOK v4、CHAPTER 01 Software Requirements - 1.2 Categories of Software Requirements - Figure 1.2（p.46）より引用）

上図に示されている各用語の説明を以下に示します。

• ソフトウェア要求 Software Requirements
  • 現実世界の問題を解決するためにソフトウェアが備えるべき特性。
  • SWEBOK v4 内での定義
    • (1) 利用者が問題を解決したり目標を達成したりするために必要となる条件または能力
    • (2) システムあるいはシステム構成要素が、契約・標準・仕様書などの正式な文書を満たすために備えるべき条件または能力
    • (1) または (2) の条件／能力を文書として表現したもの
    • ソフトウェア開発プロジェクトが抱えるニーズと制約の表現（expressions of a software project's needs and constraints）
• ソフトウェアプロジェクト要求 Software Project Requirements
  • 「そのソフトウェアを構築するプロジェクト」に課す制約。コスト・スケジュール・要員配置だけでなく、テスト環境・データ移行・ユーザートレーニング・保守などソフトウェアの開発の進め方についての要求。
• ソフトウェア製品要求 Software Product Requirements
  • 完成したソフトウェアの形態・適合性・機能（form、fit、function）を規定するもの。
  • 「何ができるか / どう振る舞うか」に焦点を当てる。
• 機能要求 Functional Requirements
  • ソフトウェアが提供すべき観測可能な振る舞いを定義する要求。業務ルールや処理手順（例：残高は負にならない、資金移動の手続き、など）を示す。
• 非機能要求 Nonfunctional Requirements
  • 機能以外でシステムが満たすべき水準や、自動化技術の制約を定める要求。性能・精度・信頼性・安全性・セキュリティなどが該当する。
• 技術的制約 Technology Constraints
  • 非機能要求のサブカテゴリ。特定の OS、プログラミング言語、DB エンジン、ブラウザ互換性など、使用を義務 / 禁止する具体的技術やインフラを指定する。
• サービス品質制約 Quality of Service Constraints
  • 非機能要求のサブカテゴリ。性能（応答時間・スループット）・精度・信頼性・可用性・スケーラビリティ・安全性・セキュリティなど、性能や品質の目標値を示す。例えば、「応答時間は 200 ms 以内」、「MTBF 10,000 時間以上」など、達成すべき具体値を定める。