ソフトウェア品質保証とは？

ソフトウェアの品質は、外部特性と内部特性の両面から評価します。外部品質は、実際の運用条件でどれだけ適切に動作し、利用者の役に立つかを示します。内部品質は、その動作を支えるコードの品質です。利用者が直接体験するのは主に外部の動作ですが、その品質を維持するには、分かりやすく丁寧に書かれたコードが欠かせません。

原寸大の図を開く ↗

ソフトウェア品質

ソフトウェア品質保証とは？

ソフトウェア品質を評価する重要な方法が二つあります。

1. 欠陥管理によるアプローチ
2. 品質属性によるアプローチ

顧客の要求を満たさないものは欠陥とみなせます。要求を誤解すると設計ミスにつながります。機能のロジックの不備、コードの誤り、データの不適切な処理も欠陥の原因になります。欠陥管理では、欠陥を追跡し、重大度ごとに分類して件数を記録します。チームは割り当てられた重大度に応じて対処します。管理図は、開発プロセスの能力を測定するのに役立ちます。

原寸大の図を開く ↗

欠陥管理によるアプローチ

以前のソフトウェア製品品質モデルである ISO/IEC 9126-1 では、品質属性を六つの特性に分類しています。

原寸大の図を開く ↗

品質属性によるアプローチ

1. 機能性 ソフトウェアが提供する重要な機能の全体。

• 合目的性。ソフトウェアの機能は目的に適していますか？
• 正確性。機能は正しく実装されていますか？
• 相互運用性。ソフトウェアはシステム内の他のコンポーネントとどのように連携しますか？
• 標準適合性。適用される法律やガイドラインを守っていますか？
• セキュリティ。データの取引や処理を安全に行えますか？

2. 信頼性 定められた条件の下で一定期間動作する能力。個々のコンポーネントの故障に耐える能力も含みます。

• 成熟性。ソフトウェアはどのくらいの頻度で故障しますか？
• 回復性。故障後にシステムはどの程度まで完全な稼働状態に戻れますか？

3. 使用性 機能がどれだけ使いやすいかを示します。

• 理解性。利用者は機能を容易に理解できますか？
• 習得性。経験の異なる利用者が機能を理解するには、どのくらいの労力が必要ですか？

4. 効率性 一般に、開発時に採用したアーキテクチャとコーディングの方法に左右されます。

5. 保守性 サポート性とも呼ばれ、コードの読みやすさと複雑さに大きく左右されます。欠陥を発見し、修正する能力に関わります。

• 解析性。故障の主な原因をどれだけ簡単に特定できますか？
• 変更性。コードを変更して欠陥を除くには、どのくらいの労力が必要ですか？
• 安定性。変更後もシステムの動作はどれだけ安定していますか？
• 試験性。システムをテストするには、どのくらいの労力が必要ですか？

6. 移植性 システムが環境の変化に適応する能力。

• 環境適応性。仕様の変更にどれだけ容易に適応できますか？
• 設置性。システムをどれだけ容易に導入できますか？
• 標準適合性。機能性の標準適合性に相当します。
• 置換性。特定の環境でシステムのコンポーネントをどれだけ容易に置き換えられますか？

ソフトウェア品質のコスト テストには時間、費用、労力が必要です。ソフトウェア品質にかかるコストを分析すると、その投資に対する効果（ROI）を把握できます。

原寸大の図を開く ↗

ソフトウェア品質のコスト

品質コストには、適合コストと不適合コストがあります。適合コストには以下が含まれます。

1. 予防コスト。品質保証の活動を適切に行うための費用です。チームの研修、コードレビュー、その他の品質保証活動を含みます。
2. 評価コスト。テストの計画と実施にかかる費用です。テストケースの作成と実行を含みます。

不適合コストは以下の種類の不具合から生じます。

1. 内部失敗コスト。初期の社内テストが失敗したときに発生します。単体テストやコンポーネントテストで見つかった欠陥を開発者が修正する工数などが含まれます。
2. 外部失敗コスト。テスト担当者が見逃した欠陥を顧客が発見したときに発生します。特に、顧客が不満を抱いたり障害への対応を上位窓口に求めたりする場合、内部失敗コストより大幅に高くなります。

ソフトウェア障害のコスト ソフトウェア障害には、複数の要因が関わることがあります。

1. 変化への対応が難しくなること。ソフトウェアが古くなるにつれ、既存コードを見直さずに新機能を加えると、コードが増え、保守が難しくなります。やがて、どこを変更すべきか見つけにくくなります。
2. ソフトウェア、処理負荷、データの変化によって性能が低下することがあります。たとえば、メモリリークが発生すると、動作中のメモリ使用量が増加します。修正、アップグレード、置き換えのどれを選ぶか決める前に、問題を計測して原因を調べましょう。
3. 修正によってリグレッションが起こることがあります。特に、変更したコードに他のコンポーネントが依存している場合に注意が必要です。元の問題が解消されたことを確認し、影響を受ける動作をテストしましょう。結果、保守コスト、事業への影響を踏まえて次の対応を決めます。

ソフトウェアテストと品質保証 IT業界ではソフトウェア品質保証とテストが混同されがちです。どちらも高品質のソフトウェアを目指すため、テスト担当者が品質保証の専門家と呼ばれることがあります。
品質保証では、顧客の品質要求を満たし、ソフトウェア開発ライフサイクルの手順に従うために必要なプロセスを整備して実施します。問題を未然に防ぐ取り組みで、主に次の点に焦点を当てます。

1. 欠陥の予防
2. プロセス
3. プロセスの継続的な改善

ソフトウェアテストでは、ソフトウェアを厳密に調べ、欠陥や誤りを見つけます。顧客の要求から外れていて修正が必要な箇所を確認します。テストは製品を対象とする品質管理の活動です。テストで欠陥を見つけ、デバッグで修正します。

品質保証と品質管理 品質保証と品質管理は密接に関係し、それぞれ役割が異なります。品質保証はプロセスを通じた予防に重点を置きます。品質管理は製品の品質上の問題を発見し、対処する活動に重点を置きます。
テストは品質管理の一部です。品質保証と品質管理はいずれも品質マネジメントを支えます。品質保証では、チームが顧客の要求を満たせるようにプロセスを整備し、改善します。

原寸大の図を開く ↗

品質保証と品質管理

品質管理には、製品の特性を検証、管理し、開発が定められた要求を満たすことを確認する活動が含まれます。特に重要なのは製品の検査とテストです。

品質管理チームは、企業の品質基準を満たさない製品やサービスを特定します。問題を見つけた場合は、解消されるまで生産を止めることがあります。

監査とインスペクションの重要性

監査では、組織がソフトウェアテストをどのように実施しているかを体系的に調べます。監査担当者は、文書化されたプロセスを確認し、組織やチームが定められた基準に従っているかを調べます。

インスペクションは、要求、設計、コードなどの作業成果物に対する正式なレビューです。作成者とは別のレビュー担当者が、欠陥や合意済みの基準からの逸脱を探します。一般的なインスペクションには次の活動が含まれます。

1. 計画
2. 概要説明と個人での準備
3. インスペクション会議
4. 修正作業
5. フォローアップ