納入時に品質を確保する「受入テスト」と「総合テスト」：ビジネスサクセスのための“情報システム品質”（3）（2/2 ページ）

[北島義弘（元日科技連SPCシンポジウム委員長），株式会社PM Academy 代表取締役]

総合テスト

　第1回「ユーザー企業にとっての“品質”とは何か？」で、情報システムの品質は、「目的にいかに適合しているかがポイントである」と述べたが、この最終工程は情報システムが意図したとおりに開発できているか、現場レベルまで含めて使用可能かどうかの最終チェックをする総合テスト（運用テストを含む）である。

　総合テストは、基本設計で定めた要求仕様、特に非機能要件に着目して行う。業務機能などの要件に関しては、これより以前の受入テストを含む結合テスト工程で十分実施されていることを前提としている。

　非機能要求とは、主として、性能・信頼性・安全性・拡張性・運用・保守・移行を指すといってもよい。これらに対してどのような要求条件が約束されたかは、システム基本設計書（要求定義書といってもよい）に記述されている。システム基本設計書は総合テストの基準になる文書といっていいだろう（そんなことをどこにも規定していないというシステム開発は、単なるソフトウェア開発であって、システム開発とは呼べないだろう）。

　従って総合テストの準備は、基本設計が完了すればいつでも始めることができるのである。テストファーストという言葉は、何も目新しい概念ではなく、昔から存在している。

性能

　情報システムの性能設計では、特定の日、特定時間帯の、大きな負荷に耐えられるための仕組みが組み込まれていなければならない。

　トランザクション型では、一定負荷時のレスポンスタイムとスループット（単位時間当たりの処理できるトラフィック）を測定する。代表的なトランザクションタイプのレスポンスタイムについては、例えば、90％のトランザクションが3秒以内で処理できることが、レスポンスタイムの条件となる。また、スループットのテストでは、大量トランザクションの負荷を掛けてみて、処理できる秒当たり（時間当たりかもしれない）トランザクション件数を推定する。

　また、負荷分散の仕組みを持っているシステムでは、負荷分散装置（機能）が正しく動いているかを確認することも必要である。バッチ処理では、特にネックになりそうな大型処理があれば、一定時間以内に完了できるかをチェックしたり、DBのバックアップ時間が運用に差し支えないかを確認したりする。

　負荷を作るための準備、または大量のクライアント端末から時間を決めて決められたデータを投入する場合には、要員確保も含めて入念な準備が必要である。

信頼性

　信頼性条件──例えば、ディスクの故障の耐性、複数台サーバの故障に対する切り替えなど、基本設計で定めた条件についてのテストを行う。疑似的にディスクを故障させ、RAIDの回復機能が機能するか、サーバを故障させて切り替えがスムーズに動くかといったテストが必要である。また、システムダウンからの回復時間、バックアップファイルからの再立ち上げ時間などのリカバリに関する規定があれば、そのための確認が必要である。この種のテストでは、本当に装置を壊してしまうようなことがないように注意して行う必要がある。

安全性

　安全性条件は、最近の情報システムでは、特にセキュリティ条件が確実に情報システムに組み込まれているかを確認することが重要である。さまざまな条件で行う必要があるため、条件表などが整備されていないといけない。特に、使用者の役割（一般オペレータ、管理者オペレータ、業務管理者、システム管理者）ごとの業務等へのアクセス制限に関するテストが、最近のSOX法対応としても必須である。

　インターネット網と接続されている場合は、外部からの侵入に対するガード機能も確認する。ガード機能に「絶対」はないが、外部の専門コンサルタントを使ったガード突破テストを行うことも視野に入れておいた方がよい。ただし、きちんと契約ベースで行わないと、委託先が不正アクセス防止法違反に問われるという事態になりかねないので、社内調整などが必要かもしれない。

拡張性（縮小性）

　システム設計時に開発する情報システムの目標に対応して、このシステムの量的な拡張性（例えば、組織数・店舗数、クライアント台数など）にどう対応するかを検討し、それらの対応した機能を備えているかを確認する。単に、テーブル更新だけで片付く問題もあるが、ミドルウェアでの制約や特定業務プログラムのメモリテーブルなどに制約があるケースがある。

　十数年前までは「拡張」ばかり考えてきたが、デフレ時代になって「縮小」も検討する必要があることが経験的に分かってきている。店舗の減少、統廃合などによる業務縮小などに対応できるかどうかも検討項目に入れておきたい。

保守性

　保守性の条件は、実際の保守の仕方──すなわち保守時間、保守要員の配置など物理的なものが多いが、最近では特にログ類の扱いについてのチェックが必要である。こういう項目は、案外忘れがちでログの量と質に関するテスト項目が必要であろう。

運用性

　情報システムが実際に運用可能かどうかをテストする。システムの要求条件によってテスト項目は変わってよい。

　一般には、

1. 通常日の1日の運用が（オンラインからバッチまで）うまく流れ、翌日も正常に立ち上げ可能
2. 金曜日の運用から、月曜日の運用に引き継げること
3. 月末営業日から翌月最初の営業日に引き継げる
4. 年末営業日から翌年初営業日に引き継げる
5. 終日運転システムでの、ソフトウェアメンテナンス／ハードウェアメンテナンスに対応した運用
6. 異状状態での運用：アラートが出たときの対処
7. 平行運転：現行システムと新システムの結果を比較する

などのテストが必要である。

移行

　どのような形態で移行するのかは、あらかじめ考えて仕組んでおくことが必要である。実際は、総合テストの先頭を切るのが移行テストと考えてよい。移行リハーサルという名前を付けているところもあるが、実際の移行に近い形で実施してみると、実態的なさまざまな問題が浮き彫りにされる。また、移行を最後に書いたが、総合テストでの一般的なデータ設定機能としても使えるので、うまく利用するとよい。

過酷条件

　これらのほかに、通称「意地悪テスト」「イジメテスト」という、普通に考えれば思いもつかないことをやってみるといったテストを行うことがある。どれだけ思いも付かぬことを思い付くかというのが開発のノウハウかもしれない。例えば、画面から何も入力しないでEnterする、EnterをしてからいきなりPCの電源を落とす……。こうしたことで、思わぬ現象が発生することがある。

テストには綿密な準備を

　システムテストは、

1. テスト計画を立てる
2. テスト環境を構築する
3. テスト項目を決める
4. テストデータを準備する
5. テスト手順を記述する
6. テストを実施する
7. テスト結果を評価する

　これらのテストを一定期間のスケジュールに従って、実施する計画を立て実行するわけだが、大規模なシステムでは、全社を巻き込んだ大掛かりなものになる。特に、エンドユーザーまで動員することがあるので、慎重に準備することが求められる。ここでミスをすると、後々までシステムの評判を落とすことになるし、コストの無駄遣いになってしまう。中小規模のシステムでも、やらなければならない仕事の数は変わらない。範囲、稼働人員の違いが出る。

　小規模なシステムでも実施する項目はそれほど変わらないが、関連する人は少なくなるだろう。

筆者プロフィール

北島 義弘（きたじま よしひろ）

株式会社PM Academy代表取締役社長、杭州東忠人材開発有限公司副董事長。

NTT、CRCソリューションズなどで、交換機ソフト開発、企業通信システム構築、プロジェクト管理システム構築の開発経験、品質保証・品質管理指導／プロセス改善／開発管理標準化業務、オフショア開発管理、PMO推進業務、PM／PL人材教育業務を経験。現職ではITコンサルティング、IT技術者教育を日本と中国で行っている。

米国PMI Certified PMP（プロジェクトマネジメントプロフェッショナル）、上級システムアドミニストレータ、プロジェクトマネジメント学会所属。第21回ソフトウェア生産における品質管理シンポジウム最優秀賞受賞。

IPA/SECプロセス改善研究部会委員、日本科学技術連盟SPC研究会運営委員長兼第2分科会講師（プロジェクトマネジメント分科会主査）、元SPCシンポジウム委員会委員長、ソフトウェア技術者ネットワーク（S-Open）会長、高品質ソフトウェア技術交流会(QuaSTom)幹事。

主な著書・執筆活動：「ソフトウエア開発オフショアリング完全ガイド」（共著）日経BP社

▼Webサイト

▼メールアドレス