前回の続きで今回は「保守性」についてまとめます。「保守性」はどれだけ適切に保守作業を行えるかの度合いです。
解説記事はこちら
ソフトウェアの「品質特性」とは？8つの品質特性と31の品質副特性を詳しく紹介
「保守性(Maintainability)」には5つの品質副特性があります
- モジュール性(Modularity)：構成要素ができる限り独立し、一つの変更が他の構成要素へ影響を与えにくいよう抑えられているか。
- 再利用性(Reusability)：既存の構成要素を他システムへ再利用できるか。
- 解析性(Analysability)：障害発生時の影響範囲や、修正すべき問題箇所などを容易に解析できるか（監視やログ取得のしやすさなど）。
- 修正性(Modifiability)：他の品質を低下させることなく、効率的かつ確実にプログラムを修正できるか。
- 試験性(Testability)：変更したシステムに対して、効率的かつ効果的にテストを行えるか。
今回も、イメージしやすいように例を考えてみます。
| 種類 | 副特性 | 例 | テスト観点の例 |
| ECサイト | モジュール性 | レコメンド機能やレビュー機能を一時的に停止・切り離しても、注文や決済が正常に動作し続けること | レコメンド機能やレビュー機能を無効化した状態で、カート投入から決済完了まで正常に行えるかの確認 |
| 再利用性 | 住所入力フォームなどが、会員登録画面と注文画面で共通の部品として動作し、一箇所の修正が両方に反映されること | 共通部品の設定を一部変更し、関連するすべての画面で意図した通りに一斉に変化するかの確認 | |
| 解析性 | 決済エラーが発生した際、エラーログに「どの処理で」「何のデータが」原因だったかが明確に記録されること | 意図的に不正なデータで決済を行い、出力されたログからコードを追わずに原因の特定が可能かの確認 | |
| 修正性 | 消費税率の変更が、ソースコードの書き換えなしに管理画面で完結すること | 管理画面から税率を変更し、即時サイト全体の表示・計算に反映されるかの確認 | |
| 試験性 | 実際のクレジットカード決済を行わずに、擬似的な成功・失敗をシミュレートできる設定 | テスト用カード番号等を用い、本番決済サービスへの課金発生なしに、注文完了からキャンセルまでの全フローを検証可能か。 | |
| 求人サイト | モジュール性 | 外部サービスとの連携が独立しており、連携先がダウンしてもサイト内での応募や検索が継続できること | 外部連携機能のみを設定でオフにした際に、検索や応募の操作に遅延や停止が生じないかの確認 |
| 再利用性 | 企業ごとに異なる求人票のデザインが、共通のテンプレートエンジンによって管理され、一括更新が可能であること | 共通のデザイン設定（ボタンなど）を変更し、全企業の全求人票に正しく適用されるかの目視確認 | |
| 解析性 | 履歴書アップロード失敗時、ログに「ファイルサイズ超過」や「未対応形式」など、不備の内容が明確に記録されること | 破損ファイル等をアップロードした場合に、エラーやログ画面の情報から原因の特定が可能かの確認 | |
| 修正性 | 新しい検索項目を追加する際、既存の求人データや表示を壊さずに拡張できること | 新しい検索フィルタを有効にした際、既存の検索条件との組み合わせでエラーが発生しないことの確認 | |
| 試験性 | 「書類選考中」から「内定」までの選考ステータスを、テスト用に簡単な操作で用意・再現できること | 少ない手順で「最終面接」のフェーズを用意し、その後の挙動を検証できるか |
試験性テストのテスト観点の例が思いつかず結構悩みました。次回「移植性」に続く。
余談
アイキャッチは、ある日の八芳園アフタヌーンティーです。優雅ですね。
