"とりあえず動けばよい"では済まされない！改めて考える「システムテスト」の重要性| Qbook

シェア
ツイート
ブックマーク

システム開発プロジェクトの最終段階で実施する「システムテスト」。開発プロジェクトの成否を決するとも言える重要な工程ですが、そもそもシステムテストはなぜ必要なのでしょうか。その重要性を改めて考えてみます。

不十分なテストで起こり得るシステム障害

　最近、システム障害に関するニュースを目にすることが増えています。2021年に入ってからも新型コロナウイルス接触確認アプリ「COCOA」の不具合をはじめ、気象庁の防災情報システム、山形県の情報通信システム、地方銀行の勘定系システムなど、公共・金融機関を中心にシステム障害のニュースが立て続けに報道されました。

しかも、これらのニュースは氷山の一角であり、一般企業に目を向ければさらに多くのシステム障害が頻発していることは想像に難くありません。システム障害によって数時間にわたり業務や取引などが停止し、多大な損失を企業が被る可能性も十分にあるのです。

　システム障害が起きる原因の一つとして挙げられるのが、「システムテスト」の不十分さです。システムテストは本番のシステム稼働環境と同様の使用状況を想定し、システムが正常に動作することを検査する極めて重要な工程であり、開発したシステムが仕様書通りに実装されているかといった機能要件、および性能・可用性・保守性・セキュリティなどの非機能要件を満たしているかどうかを入念にテストします。例えばシステム開発を担当したベンダーにとっては、発注元が実施する「受入テスト」の前に実施する最後のテストになります。

　システムテストに合格したシステムは「品質に問題がない」とベンダーが保証したとみなされます。ベンダーは発注元との間で締結するシステム開発契約において瑕疵担保責任や保証期間・条件を定めますが、システムテストで発見できなかったソフトウェアのバグ、想定していなかった操作方法による動作欠陥などが原因でシステム障害が発生すると、ベンダーは責任を免れません。当然、金銭的な補償問題に発展し、会社の信用も落とす事態になりかねないのです。

テストのプロが語る、ソフトウェアテストの心得とは？

プロジェクトにおけるテスト工程を改めて見直す

　では、どのようにシステムテストを実施すれば、バグや欠陥を確実に発見・修正してシステム障害のリスクを最小化できるのでしょうか。

　大規模なシステム開発プロジェクトでは、品質管理部門やテスト専任担当者（テストプロジェクトマネージャー）がテスト工程全般を主導することも多いのですが、小規模なプロジェクトではプロジェクトマネージャーの責任の下でテストを実施します。当然、プロジェクトマネージャーは要件定義、基本・詳細設計、コーディング、テストといった一連の工程をすべて管理しなければならないので、一つひとつのテスト工程管理が手薄になったり、どこかのテスト工程に抜け漏れが起きたりすることもあり得ます。

　このような課題を回避してテストを確実に実施するには、まずはテスト工程全体の方針や概要を「テスト計画書」にまとめることが必要です。計画書ではテストの目的や範囲、実施方法、スケジュールなどを決めておきます。次に計画書に基づいた「テスト仕様書」を作成し、テストに使用するツールやデータ、シナリオ、合格判断基準などを定めておきます。このテスト計画書とテスト仕様書は、発注元のプロジェクトオーナーも含め、プロジェクトメンバー全員で共有します。

　実際のテスト工程では、システムテストに至るまでの間に以下のテストを実施します。

単体テスト・・・システムを構成するプログラムモジュールを作成するたびに実施し、正常に動作することを検証。
結合テスト・・・単体テストで動作確認した複数のモジュールを組み合わせて実施し、モジュール間の連結に問題がないかを検証。単体テストおよび結合テストで不具合が見つかれば、すぐに前工程に戻して修正対応を実施。
確認テスト・・・システムを修正した際に、他の部分に影響が出ていないかを改めて確認する「リグレッションテスト（回帰テスト）」、過去バージョンへの先祖返りや不具合の再発がないかを確認する「デグレードチェックテスト」などを実施。

　結合テストで見つかった不具合の修正がすべて完了し、システム全体の形が出来上がったら、本番環境を想定したハードウェア（あるいはクラウドの仮想マシン）を用意してシステム全体のテストを実施します。これがシステムテストです。

　この工程では、以下のようなテストを実施します。

仕様書の検証・・・システムが仕様書通りになっているか、機能要件を満たしているかを中心に検証。
評価テスト・・・セキュリティに関する機能が仕様書通りかどうかを確認する「セキュリティテスト」、操作性や見やすさ、わかりやすさなどを確認する「ユーザビリティテスト」、障害発生時における対応や復旧手順について確認する「障害許容性（再発防止策）テスト」などを実施。
性能・負荷テスト・・・性能要件通りの処理能力を確認する「性能テスト」、連続稼働によるパフォーマンス低下を確認する「ロングランテスト」、過負荷状態でシステムが正常に動作するかを確認する「ストレステスト」、データ量やユーザー数が増えた場合の処理能力を確認する「キャパシティテスト」などを実施。

　これらのテストをすべて実施し、システムが問題なく稼働することが確認できたらシステムテストは終了です。

ソフトウェアテストとは？種類は？テストレベル別にテスト対象、実施内容を解説

外部のテストサービスを利用するという選択

　このようにシステムテストは、システム障害の発生リスクを確実に減少させるために極めて重要な工程です。しかしプロジェクトによっては、何度も仕様変更や要件見直しが発生したり、納期が差し迫っていたりといった理由から、システムテストを確実に実施できずに"とりあえず動けばよい"で済ませているケースがあります。またプロジェクトマネージャーによっては、テストに関するスキル不足により、結果的にシステムテストが不十分となることも考えられます。もし、システム開発プロジェクトのテスト工程に不安を抱えているのなら、第三者機関が提供するテストサービスを利用し、システムテストのさまざまなスキルやノウハウをプロジェクトに導入するという手段も有効です。また万一の場合に備え、法律上の損害賠償責任を補償する「業務過誤賠償責任保険」に加入することもお勧めします。

　冒頭の繰り返しになりますが、ビジネスに多大な影響を及ぼすような致命的なシステム障害をひとたび発生させてしまうと、損害補償などの金銭的損失や会社の信用失墜は避けられません。そうしたリスクを最小化するためにも、システムテストをはじめとする開発プロジェクトの品質管理体制が十分か、テスト工程は十分かをいま一度振り返ってみましょう。