ITシステムの品質確保の考え方は？

ITシステムにおける品質とは、想定したことが想定通り動作する度合いのことをいいます。仮に、仕様通り作成されたシステムでも、操作方法が使いにくかったり、エラー処理が複雑だったりするものは、ユーザの満足度が低下します。この状態では、高品質のシステムとは言えません。ここでは、ITシステムにおける品質に関して、開発者側とユーザ側での対応を解説します。

開発者は、ユーザの満足度を高めるために品質特性を考えて、企画・設計・開発・テストを進めます。品質特性とは、ソフトウェアの品質を評価する基準のことで、ISO/IEC 9126(JIS X 0129)に定義されています。ISO/IEC 9126(JIS X 0129)では、以下の6つの特性と、それぞれの品質特性をさらに細分化した21の副特性が定められています。以下が6つの品質特性です。

◆ 機能性(Functionality) 　目的から求められる必要な機能の実装の度合いで、想定条件の下で要求仕様を満たす能力 ◆ 信頼性(Reliability) 　想定条件の下で機能が正常動作し続ける度合いで、障害の起こりにくさの度合い ◆ 使用性(Usability) 　ソフトウェアの想定動作に関して、利用者に対する分かりやすさ、使いやすさの度合い ◆ 効率性(Efficiency) 　与えられた条件で、目的達成のために使用する時間や資源の度合い ◆ 保守性(Maintainability) 　保守作業や改修作業に対する、必要なコストの度合い ◆ 移植性(Portability) 　別の環境へ移した際、移植のしやすさや、そのまま動作する度合い

ユーザ側は、業務システムに実装したい要求を、要求仕様としてまとめていきます。同様に、運用に必要な各種要求についても要望として整理します。特に、レスポンス時間保証が求められるシステムや、システムダウンの影響を最小化する場合は、動作品質の十分な考慮が必要となってきます。ユーザ側で開発を主導する場合はこのような内容をもとに検討していきます。

各テスト工程の進め方は？

テスト工程は、要求発生から納品までの流れに従ってステップ化していきます。その際は品質特性を意識したチェック項目を作成し、品質基準をクリアする判断を進めていきます。

開発者はユーザ側から要求を受けてから、以下のステップに従って、開発工程を進めていきます。まず要求分析(Requirements analysis)の工程で、ユーザの要求を理解するために、ユーザから要望書である要求仕様書を入手します。続いて要件定義(Requirement definition)の工程で、ユーザの要求が実装可能なIT要素で実現できるかどうかを確認し、要件定義書として作成します。

次に、基本設計(Basic design)の工程で、要件定義書の記載事項に基づき、外部設計仕様として設計していきます。さらに、詳細設計(Detailed design)の工程では、基本設計書の各項目に対応する開発を想定し、設計の詳細化を進めていきます。その後の詳細工程では、開発・製造(Development / Manufacturing)で、詳細設計の項目・ルールに従い、モジュールの開発・製造を行います。

上記の開発工程の品質を保証するために、以下のステップでテストを進めていきます。まずコードレビュー(Code review)では品質を確保するために、ソースコードの品質評価を行います。続いて単体テスト(Unit Test)では、開発・製造の工程での品質を確保するために、テストデータとテストロジックに基づいて単体動作の妥当性を検証します。

次に、結合テスト(Integration Test)では、詳細設計工程での品質を確保するために、テストデータにより、モジュール間の動作の妥当性を評価します。加えて、上限値・下限値やエラー処理の振る舞いが妥当かを確認します。その後にシステムテスト(System Test)で、疑似ユーザデータを用いてシステム全体での動作が妥当か確認します。また高負荷環境での動作が安定するかどうかや、運用想定のエラー処理が妥当かどうかもみていきます。

最終工程となる運用テスト(Operations Test)では、要件定義工程の品質を確保するために、ユーザの運用環境と実データを用いて、ユーザの要求が満たされていることを確認していきます。この工程では、ユーザ側からも運用担当者を派遣し、運用方法の要員教育を並行して実施することもあります。

ここでの要員教育とは、「想定した環境下で、運用方法の差異をユーザ側から派遣し、確認すること。差異がある場合は、受入テスト前に差異について習熟し、不備がないことを事前評価し、受入準備を図ること。」です。

その目的を果たすために、ユーザ側の要員が運用テスト期間に実施するパターンです。これにより、受入テストを円滑に進めることも可能となります。並行して、引渡しに際し、別途運用計画と要員育成計画を作成・実施します。

運用テストとは？

運用テスト(OT: Operations Test)は、開発者側が責任を持ち、進めていきます。要件定義書の記載が、開発システムでカバーされていることを保証するために実施します。この運用テストについて具体的な内容を見ていきましょう。

運用テストは、ユーザ側の要求する機能が満たされていることを確認し、保証するものです。そのために、ユーザの動作環境や実際のデータを用いて、商用環境を想定した操作方法・手順を用い、確認していきます。同様に、誤ったこと(エラー)が、想定通りに(想定エラーとして)処理されることを、最終評価していきます。

加えて、機能性のみならず、性能維持が高負荷でも守られるか、操作が安定しているか等の非機能要件の適合状況を検証します。さらに、ユーザ側は、運用テスト工程を活用して、受入後の操作の習熟を図ることができます。

運用テストでは、開発者の作成したテスト計画書とテスト仕様書、テストデータを用います。テスト環境の定義が妥当か、開発者側の責任範囲の設定が適切かについて確認しましょう。

応答時間、処理時間、操作エラー、障害発生時の動作や、エラー処理手順、障害検知・障害対応フローの確認についても、運用テストで見極めます。

運用テストは開発者の責任により実施されます。しかし、求められる要件はユーザ環境で必要とされる事項です。したがって、ユーザ側の立場に立って計画立案・実施をすることが求められます。そのため、テストシナリオを事前に用意し、ユーザ環境に合わせたテストパターンを複数定義して適合性を確認します。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

受入テストとは？

受入テスト(UAT: User Acceptance Test)とは、発注要件を満たしているかについて、ユーザ側が最終確認をするものです。検収テストとも言われています。したがって、ユーザのニーズや要件を満たしているかが、判断基準となります。同様に、ビジネスプロセスを満足していることが重視されます。

ユーザの作成した要求仕様に従って、要求定義書が作成されます。その際、運用環境や想定事項を考慮し作成します。ここでは、要求仕様の内容が実際に正しく反映されていることを、ユーザ側が受入時に判断する必要があります。そのため、検収の判断として受入テストを実施します。この受入テストは、大規模なシステムや複雑なシステムの多くで、受入工程に取入れられています。

運用テストで実施している同じことを繰り返すだけでは、個別に受入テストを実施する必要性が低くなります。主な実施理由は、運用テストで実施することができない商用環境固有の処理や、業務データ処理に起因する確認を、ユーザ視点で行うためです。特に重要な機能を、有限の評価時間の中で効率的・重点的に実施します。同様に、運用時に発生するリスクについて業務影響の有無を想定し、リスク低減を図ります。

ユーザ側では、上記開発者の品質確保のための各ステップを理解し、進捗報告を受けていきます。そのため、進捗報告に従い、受入可能な品質かどうか、事前に評価を進めていきます。

ユーザ側の受入テストでは、合否判断のための受入基準を定めて、事前にユーザ側・開発者側双方が合意して進めていきます。本番稼働後の影響、障害発生の対策を意識し、重点的に確認したい項目を定義しておきます。同様に、障害発生時の処理フローや、業務フローへの影響を調査します。これによって、運用時に発生する事態への対策を事前に講じ、運用時のリスク低減を図ります。

テスト工程を理解し、運用時の安定性を高めよう

各テスト工程が理解できると、関連仕様書をはじめとする成果物の理解度が高まります。同時に、顧客要件の理解が高まり、必要な確認事項が理解できます。理解度が高まるにつれて、自身の責任範囲も広がり、より多くの責任が任されるエンジニアとなるでしょう。

テストエンジニアの求人の探し方と、そのポイントを解説！