大規模システムの品質を向上させる「テスト計画」の勘所を解説！

情報システム部門の担当者として、大規模システム開発を担当する機会はあまり多くはないと思います。

しかし、その日は突然やってきます。

今まで小規模改修案件の担当はしたことはあっても、基幹システム更改やWebサービス全面リニューアルなどの大規模システム改修で品質を上げるのは簡単ではありません。
そしてリリースまで持っていくにはどうしたらよいか、右往左往してしまうのではないでしょうか。
規模が大きければ大きいほど、プロジェクトの関係者も増え、

どのように進めたらよいのか？
どのようにコントロールしたらよいのか？
そもそも、どこから手を付けていけばよいのか？
プロジェクト全体でどのように品質を作っていくか？

など疑問はたくさん出てきます。

そこで本記事では、品質を上げるためのテスト計画の立て方を解説していきます。

大規模システムの品質はどう向上させるの？

あなたは、情報システム部門の担当者として、大規模システム開発を担当することになりました。
多くの顧客が利用しているシステムのため、経営者からも高い品質を求められています。
システムの品質が悪ければ、最悪、顧客離れにもつながります。
様々なサブシステムが連携してサービスを提供しているため、開発はマルチベンダーです。

さて、あなたはどのように経営者が満足する品質を作り上げますか？
このような状況を解決するために、どのように品質を作り上げていくかを解説していきます。

開発工程は一般的には以下のような工程で進みます。

【開発工程の進み方】

　要件定義→基本設計→詳細設計→製造（コーディング）↘
受入テスト←総合テスト　←結合テスト　←単体テスト↙

一般的には「要件定義」を情報システム部門で担当し、基本設計から開発ベンダーに委託することが多いと思います。

その後、総合テストまで開発ベンダー主体で進め、最終的に受入テストを情報システム部門で担当します。

実際にシステムを操作して、システムが正常に動作するかを確認することが多いでしょう。
これが小規模改修案件であれば、品質を上げるには受入テストで事細かに確認することで対応可能かも知れません。

しかし、大規模システム開発では受入テストだけで品質を上げるには限界があります。

そのため、プロジェクト全体を通して計画的に品質を上げる対応をする必要があります。つまりテスト計画の立て方が重要なポイントなのです。

そこで作成するドキュメントが「テスト計画書」です。テスト計画書は「全体テスト計画書」と「個別テスト計画書」に分かれます。

「全体テスト計画書」では、プロジェクト全体の品質向上のための計画を記載し、個々のテスト工程（単体テスト・結合テスト・総合テスト・受入テスト）に対して、工程ごとの「個別テスト計画書」を作成します。

5つのテスト技法の基本がわかる！
テスト技入門ガイドブック

なぜテスト計画を立てるの？

システムの品質を上げるために、なぜテスト計画が必要なのでしょうか？

例えば、ちょっとした機能のスマートフォンアプリのテストであれば、いきなりアプリ上で様々な操作をすることで一通りの機能を確認できるかも知れません。

しかし、大規模システム開発ではそうはいきません。
設計、製造、テストで、様々な会社や人が作業を分担して１つの大きなサービスを構築します。

つまり、担当範囲や対応方針を明確に指示する必要があり、品質を確立するために必要な情報を「テスト計画書」で明確にする必要があるのです。

テスト計画を作成するための手法として、ソフトウェアテストの国際規格（ISO/IEC/IEEE29119）では、「テストへの要求事項」をプロジェクト計画などから参照し、「テスト要件」を整理することと記載されています。

　テストへの要求事項（インプット）

• 　　プロジェクト全体の計画や方針
• 　　プロジェクトのコストと時間の制約
• 　　システム要件
• 　　該当する規制基準
• 　　既知のリスク
• 　　開発計画におけるテストの位置づけ　など

テスト要件（アウトプット）

• 　　テスト対象
• 　　テスト範囲
• 　　テストベース
• 　　テストの背景、目的・目標、重点項目
• 　　テストへの期待　など

上記の要件をまとめるために「テスト計画書」を作成します。
「テスト計画書」は当該テスト工程の担当者が参照するだけでなく、他の関係者も確認します。
どのようなテストを行うのか、共通認識をプロジェクト全体で持つことができるのです。

テストに習熟した専門のエンジニアが、
お客様に必要なテスト計画・設計を立案します！
バルテスのテスト計画･設計支援サービス

品質特性を活用した全体テスト計画の勘所

ここで、プロジェクト全体の品質を向上・コントロールするための勘所を解説していきます。
大規模システム開発では、単体テスト・結合テスト・総合テスト・受入テストと段階を踏んで品質を積み上げていく必要があります。

基本的な考え方は、テストの粒度を小さいものから大きなものに徐々に上げていきます。
イメージは以下の段階となります。

単体テストの細かい粒度のテストから、品質を積み上げていき、最終的な業務単位の大きなテストにまで粒度を引き上げていきます。

そのためにテスト工程毎に「テスト計画書」を作成し、テストの方針を決めます。

なぜなら、どの工程でどのようなことを確認するのか、役割分担を最初に決めなければ、各工程でバラバラな方針を立ててしまうからです。
大きな観点での漏れや、逆に冗長過ぎる確認を行うことで無駄なコストが発生する可能性もあります。

そこでお勧めする手法が「全体テスト計画」時点で「品質特性」を基に各工程の役割を整理することです。

最初に工程別の役割分担を整理することで、大きな観点の漏れや冗長過ぎる観点を調整できます。
具体的な役割分担の決め方として、「ISO/IEC25010ソフトウェアの品質モデル」に定義されている「品質特性」を利用することができます。

「品質特性」とは、9つの特性で定義され、各々の特性に対して計40の副特性が定義されています。

主特性	副特性	定義
機能適合性	機能完全性	機能がニーズをどれだけ網羅しているか（例：利用者の目的を叶えた機能が搭載されているか）
	機能正確性	機能を誤りなく正確に提供できるか（例：処理や出力が仕様どおりか）
	機能適切性	利用目的にふさわしい機能内容か（例：機能の実現に不要な手順がないか）
性能効率性	時間効率性	応答時間や処理時間が適切か（例：画面遷移の速度は許容範囲内か）
	資源効率性	ITリソースを無駄なく効率的に使えているか（例：CPU負荷は許容範囲内か）
	容量満足性	入力値やデータ量の許容範囲が十分か（例：想定されるデータ量を処理できるか）
互換性	共存性	他ソフトウェアに悪影響を与えたり、悪影響を受けたりせずに動作するか（例：同じPC上で、他アプリケーションを同時に起動しても問題なく動作できるか）
	相互運用性	他ソフトウェアや他機器と連携できるか（例：旧バージョンで作成されたファイルを新バージョンで開き、編集できるか）
インタラクション容易性、対話性	適切度認識性	自分のニーズに合うソフトウェアだと直感的に認識できるか
	習得性	ユーザーが使い方をストレスなく効率的に習得できるか
	運用操作性	運用者が操作しやすいか
	ユーザーエラー防止性	ユーザーの誤操作を防止できるか
	ユーザーエンゲージメント、利用者関与性	ユーザーが楽しみながら使い続けたいと感じられるか
	インクルーシビティ、包摂性	多様な背景・文化・言語を持つユーザーが公平に利用できるか
	ユーザ支援性	幅広い範囲の特性及び能力の違いがあっても、目的達成できるよう支援されているか
信頼性	無障害性	システムの信頼性はユーザーにとって満足か（例：障害発生時に停止しないか）
	可用性、アベイラビリティ	ユーザーが使いたい時に利用できるか（例：機能を24時間利用できるか）
	障害許容性、耐故障性	障害の発生をどこまで許容できるか（例：障害発生時に機能制限付きで動作を維持できるか）
	回復性	障害発生前の状態に戻せるか（例：データベース操作のロールバックが行えるか）
セキュリティ	機密性	許可されたデータだけにアクセスできるか
	インテグリティ	不正なアクセスやシステムエラーにより、権限のないデータの変更や削除を防止できるか
	否認防止性	事実を否認されないように対策されているか
	責任追跡性	操作や事象を後から追跡できるか
	真正性	偽りなく本物であると証明できるか
	対攻撃性	不正アクセスやサイバー攻撃に対して正常に動作し続けられるか
保守性	モジュール性	構成要素ができる限り独立し、他の構成要素への影響を抑えられているか（例：モジュールAの変更がモジュールBに影響しないか）
	再利用性	既存の構成要素を他システムへ再利用できるか（例：バージョンアップにともない、設定ファイルの引き継ぎが行えるか）
	解析性	影響範囲や修正箇所、問題箇所などを解析できるか（例：ログを見て、障害の原因をすぐに特定できるか）
	修正性	品質を保ちつつ効率的にプログラムを修正できるか（例：コードが読みやすく、どこを直せばよいかすぐに判断できるか）
	テスト可用性、試験性	品質を保ちつつ効率的にテストを行えるか（例：明確な合否基準を設定できるか）
柔軟性	適応性	H/W、S/W、周辺ソフトや機器などが異なる場合でも、設定や手順によってどれだけ適応できるか
	拡張性	負荷やデータ量の減少や増大に、リソース追加や構成変更、設定調整などにより性能や処理能力を調整し問題なく対応できるか
	インストール性、設置性	所定の場所へ効率的に配置・削除できるか
	置換性	別のソフや機器との置き換えが行いやすいか
安全性	運用制約性	危険な操作や想定外の操作を防ぐ制約が設けられているか
	リスク識別性	潜在的な危険やリスクを事前に識別・警告できるか
	フェールセーフ	障害発生時に安全な状態に移行できるか
	危険警告性	危険な状況になりそうな場合、利用者が回避できるタイミングで事前に警告できるか
	統合時安全性	他の部品や機能と組み合わせて動作しているときに、想定外の状態が発生しても危険にさらされないようになっているか

上記の品質特性をどの工程で検証するかを組み立てていき、プロジェクト全体で過不足なく、バランスを取ることが大事です。

例えば、以下のように各テスト工程で重点を置く品質特性（大きな観点）を決めていきます。

【重点を置く品質特性】

• 単体テストでは、設計書通りに正確に動作する「機能正確性」
• 内部結合テストでは、モジュールを結合させて機能の集合を確認する「機能完全性」
• 総合テストや受入テストでは、システムの目的が達成されるかを確認する「機能適切性」

機能面以外でも、処理速度や負荷などの性能効率性、システム運用が適切に行われるかを確認する保守性を決めていきます。

どの環境で動作させるかの移植性などのシステム全体の観点を、工程別の確認事項としてプロジェクトの最初（全体テスト計画）に整理することで、個々のテスト工程での検証観点が明確になります。

システムによっては、検証対象外の特性もあるかと思います。その場合は対象の特性を「検証対象外」と明確にすることも大事です。

情報システム部門の担当者が、開発側のテスト方針を「品質特性」により指示や調整を行います。

そして開発側での品質の積み上げ方を明確にしてもらいます。

その方針を持って、最終的に受入テストで必要な確認をしていけばよいのです。このような作業を繰り返していけば、品質を「積み上げる」ことが可能となります。

また、副次的な効果として、「コストの最適化」にも役に立ちます。

「品質特性」ごとにどの工程で検証するのかを最初に決めるため、複数の工程で同じようなテストを実施するケースを防ぐことができます。

結果的に無駄なテストコストを掛けずに進めていけます。

まとめ

本記事では、大規模システム開発での品質の「積み上げ方」の勘所を説明しました。

品質は誰か一人の力で上げられるものではありません。

品質は様々なステークホルダと協力し、分担することで、一歩ずつ「積み上げていく」ものです。

すべてを自分一人で抱え込むのではなく、チーム全体で協力することを論理的に組み立ててみてはいかがでしょうか。

当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。