情報システムの品質を考えたとき、開発されたソフトウェアの「受入テスト」「総合テスト」は、極めて重要である。情報システム品質を確保するためのチェックポイントとは?
この記事は会員限定です。会員登録すると全てご覧いただけます。
ユーザー企業の情報システム開発の最終段階は、協力会社または自社でのソフトウェア開発がほぼ終了した後、ユーザー企業側での受入テスト、総合テストである。このポイントでの品質は、実際の運用に供するためには欠かすことができない。
情報システム開発において、ソフトウェア開発のすべてを内製することは、人材面・稼働面・コスト面から見て現実的ではない。本稿ではソフトウェアのかなりを外製していることを想定しているが、協力会社から「はい出来上がりました」と持ち込まれて、すぐ動くとは限らないし、複数の協力会社に依頼していることも多く、会社間のインターフェイスも心配である。従って、仕様どおり出来上がっているかをテストすること、すなわち受入テストが必要である。
また、ソフトウェアのオープン化に伴い、独立系ソフトウェアベンダ(ISV)からさまざまなソフトウェア製品を購入し、システムに組み込むことも多い。これらの購入ソフトウェア・プロダクトの受入テストは、アプリケーションに先行して導入され、単体テスト以降の環境として使いこなされている場合も多いが、開発したソフトウェアがこれらの下で、正常に動作できるかをテストすることが必要である。
システムのトラブルが発生したときに、切り分け、修正依頼などスムーズに行うためにも、受入テストの役割は重要である。
受入テストはシステム・インテグレーション(要素を組み上げて、システムを構築する作業)の入り口である。受入テストは、1つのシステムへ組み上げるためのプロセスであると考えて、テスト計画を立てるとよい。
ユーザー企業(発注会社)は、受入テストまでに協力会社が行うべきテストと品質レベルに関して事前に約束をしておかなければならないが、受入テストと同程度の環境(部分的でもいい)でテストをしてあると前提できるならば、直ちに受入テストを行える環境になっていると見てよい。
受入テストを実施するための各種作業を列記し、準備すべき事項のスケジュールを立てる。
(1)受入環境構築
受入テストのための環境は、結合テストの環境と考えてよい。
(2)受入テストの項目設定
業務プログラムでは、主として、業務機能の要求を満たしているかをテストする。いわゆる機能テストである。詳細設計書に記述された要求機能からチェック項目を作り出し、これに合ったテストケースを作成する。発注側が、テスト項目を作成するのが本来だが、開発側に手伝ってもらったり、立ち会ってもらったりすることもある。また、開発側で行ったテスト項目をチェックしてテスト項目を省略することもある。
(3)テストの実施
テストそのものは、テストケースに基づいて淡々と実施するが、故障が発生した場合の対処方法を決めておく。開発側の関係者が立ち会っていれば、故障対処は早くできる。
(4)合否基準
直ちに修復できない致命的なバグが一定数以上あった場合は、差し戻しとする。
(5)再テスト
差し戻しになったソフトウェアは再テストする。
(6)修正後のチェック・維持
受入テストで合格になったら、構成管理手順による最終製品の原本管理を行う。受入テストに合格すれば、開発したソフトウェアは、プログラマ個人のものではない、システム共有の資源であることを認識させておくことが肝要である。
各納入単位での受入テストの後、全体的な機能テストを行う。大まかな業務間での処理、処理間のオンライン処理とバッチ処理との連携、バッチ処理と引き続くオンライン処理の連携、他システムとの連携(データの送受信:手操作、ファイル転送など)のチェックを行う。
関連記事
・連載:企業システム戦略の基礎知識(9) ? 納品されたシステムに対する効果的な検収方法(@IT情報マネジメント)
・連載:企業システム戦略の基礎知識(10) ? 紛争勃発に備えよ!──受け入れ検査時のトラブル対策(@IT情報マネジメント)
Copyright © ITmedia, Inc. All Rights Reserved.