テスト計画の立て方とは？　品質を上げるための勘所

情報システム部門の担当者として、大規模システム開発を担当する機会はあまりないと思います。しかし、その日は突然やってきます。今まで小規模改修案件の担当はしたことはあっても、基幹システム更改やWebサービス全面リニューアルなどの大規模システム改修で品質を上げるのは大変です。そしてリリースまで持っていくにはどうしたらよいか、右往左往してしまうのではないでしょうか。規模が大きければ大きいほど、プロジェクトの関係者も増え、どのように進めたらよいのか？どのようにコントロールしたらよいのか？そもそも、どこから手を付けていけばよいのか？

プロジェクト全体でどのように品質を作っていくか？疑問はたくさんあります。そこで品質を上げるためのテスト計画の立て方を解説していきます。

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

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

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

【開発工程の進み方】

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

一般的には「要件定義」を情報システム部門で担当し、基本設計から開発ベンダーに委託することが多いと思います。その後、総合テストまで開発ベンダー主体で進め、最終的に受入テストを情報システム部門で担当します。実際にシステムを操作して、システムが正常に動作するかを確認することが多いでしょう。これが小規模改修案件であれば、品質を上げるには受入テストで事細かに確認することで対応可能かも知れません。しかし、大規模システム開発では受入テストだけで品質を上げるには限界があります。

そのため、プロジェクト全体を通して計画的に品質を上げる対応をする必要があります。つまりテスト計画の立て方が重要なポイントなのです。そこで作成するドキュメントが「テスト計画書」です。テスト計画書は「全体テスト計画書」と「個別テスト計画書」に分かれます。「全体テスト計画書」では、プロジェクト全体の品質向上のための計画を記載し、個々のテスト工程（単体テスト・結合テスト・総合テスト・受入テスト）に対して、工程ごとの「個別テスト計画書」を作成します。

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

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

システムの品質を上げるために、なぜテスト計画が必要なのでしょうか？例えば、ちょっとした機能のスマートフォンアプリのテストであれば、いきなりアプリ上で様々な操作をすることで一通りの機能を確認できるかも知れません。しかし、大規模システム開発ではそうはいきません。設計、製造、テストで、様々な会社や人が作業を分担して１つの大きなサービスを構築します。つまり、担当範囲や対応方針を明確に指示する必要があり、品質を確立するために必要な情報を「テスト計画書」で明確にする必要があるのです。

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

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

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

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

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

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

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

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

ここで、プロジェクト全体の品質を向上・コントロールするための勘所を解説していきます。大規模システム開発では、単体テスト・結合テスト・総合テスト・受入テストと段階を踏んで品質を積み上げていく必要があります。基本的な考え方は、テストの粒度を小さいものから大きなものに徐々に上げていきます。イメージは以下の段階となります。

単体テストの細かい粒度のテストから、品質を積み上げていき、最終的な業務単位の大きなテストにまで粒度を引き上げていきます。そのためにテスト工程毎に「テスト計画書」を作成し、テストの方針を決めます。なぜなら、どの工程でどのようなことを確認するのか、役割分担を最初に決めなければ、各工程でバラバラな方針を立ててしまうからです。大きな観点での漏れや、逆に冗長過ぎる確認を行うことで無駄なコストが発生する可能性もあります。

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

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

主特性	副特性	定義
機能適合性	機能完全性	機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。
	機能正確性	正確さの必要な程度での正しい結果を，製品又はシステムが提供する度合い
	機能適切性	明示された作業及び目的の達成を，機能が促進する度合い。
性能効率性	時間効率性	製品又はシステムの機能を実行するとき，製品又はシステムの応答時間及び処理時間，並びにスループット速度が要求事項を満足する度合い。
	資源効率性	製品又はシステムの機能を実行するとき，製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い。
	容量満足性	製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。
互換性	共存性	その他の製品に有害な影響を与えずに，他の製品と共通の環境及び資源を共有する間，製品が要求された機能を効率的に実行することができる度合い。
	相互運用性	二つ以上のシステム，製品又は構成要素が情報を交換し，既に交換された情報を使用することができる度合い。
使用性	適度認識性	製品又はシステムが利用者のニーズに適切であるかどうか
	習得性	明示された利用状況において，有効性，効率性，リスク回避性及び満足性をもって製品又はシステムを使用するために明示された学習目標を達成するために，明示された利用者が製品又はシステムを利用できる度合い。
	運用操作性	製品又はシステムが，それらを運用操作しやすく，制御しやすくする属性をもっている度合い。
	ユーザーエラー防止性	利用者が間違いを起こすことをシステムが防止する度合い。
	ユーザインタフェイス快美性	ユーザインタフェースが，利用者にとって楽しく，満足のいく対話を可能にする度合い。
	アクセシビリティ	製品又はシステムが，明示された利用状況において，明示された目標を達成するために，幅広い範囲の心身特性及び能力の人々によって使用できる度合い。
信頼性	成熟性	通常の運用操作の下で，システム，製品又は構成要素が信頼性に対するニーズに合致している度合い。
	可用性	使用することを要求されたとき，システム，製品又は構成要素が運用操作可能及びアクセス可能な度合い。
	障害許容性	ハードウェア又はソフトウェア障害にもかかわらず，システム，製品又は構成要素が意図したように運用操作できる度合い。
	回復性	中断時又は故障時に，製品又はシステムが直接的に影響を受けたデータを回復し，システムを希望する状態に復元することができる度合い。
セキュリティ	機密性	製品又はシステムが，アクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。
	インテグリティ	コンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを，システム，製品又は構成要素が防止する度合い。
	否認防止性	事象又は行為が後になって否認されることがないように，行為又は事象が引き起こされたことを証明することができる度合い。
	責任追及性	実体の行為がその実体に一意的に追跡可能である度合い。
	真正性	ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。(本人確認)
保守性	モジュール性	一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように，システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。
	再利用性	一つ以上のシステムに，又は他の資産作りに，資産を使用することができる度合い。
	解析性	製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること，欠陥若しくは故障の原因を診断すること，又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。
	修正性	欠陥の取込みも既存の製品品質の低下もなく，有効的に，かつ，効率的に製品又はシステムを修正することができる度合い。
	試験性	システム，製品又は構成要素について試験基準を確立することができ，その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。
移植性	適応性	異なる又は進化していくハードウェア，ソフトウェア又は他の運用環境若しくは利用環境に，製品又はシステムが適応できる有効性及び効率性の度合い。
	設置性	明示された環境において，製品又はシステムをうまく設置及び／又は削除できる有効性及び効率性の度合い。
	置換性	同じ環境において，製品が同じ目的の別の明示された製品と置き換えることができる度合い。

上記の品質特性をどの工程で検証するかを組み立てていき、プロジェクト全体で過不足なく、バランスを取ることが大事です。例えば、以下のように各テスト工程で重点を置く品質特性（大きな観点）を決めていきます。

【重点を置く品質特性】

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

機能面以外でも、処理速度や負荷などの性能効率性、システム運用が適切に行われるかを確認する保守性を決めていきます。どの環境で動作させるかの移植性などのシステム全体の観点を、工程別の確認事項としてプロジェクトの最初（全体テスト計画）に整理することで、個々のテスト工程での検証観点が明確になります。システムによっては、検証対象外の特性もあるかと思います。その場合は対象の特性を「検証対象外」と明確にすることも大事です。

情報システム部門の担当者が、開発側のテスト方針を「品質特性」により指示や調整を行います。そして開発側での品質の積み上げ方を明確にしてもらいます。その方針を持って、最終的に受入テストで必要な確認をしていけばよいのです。このような作業を繰り返していけば、品質を「積み上げる」ことが可能となります。また、副次的な効果として、「コストの最適化」にも役に立ちます。「品質特性」ごとにどの工程で検証するのかを最初に決めるため、複数の工程で同じようなテストを実施するケースを防ぐことができます。結果的に無駄なテストコストを掛けずに進めていけます。

まとめ

「テスト計画の立て方とは？　品質を上げるための勘所」と題しまして、ご紹介しました。大規模システム開発での品質の「積み上げ方」の勘所を説明してまいりました。品質は誰か一人の力で上げられるものではありません。品質は様々なステークホルダと協力し、分担することで、一歩ずつ「積み上げていく」ものです。すべてを自分一人で抱え込むのではなく、チーム全体で協力することを論理的に組み立ててみてはいかがでしょうか。

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