今回は「テスト」を巡るさまざまな事項や課題を取り上げる。単に仕様どおりでよしとせず、顧客の立場に立ったテストが重要だ。性能テスト周辺の諸問題、テストで問題点が発見できたときの原因追究や対策に役立つ情報のあり方なども考える必要がある。
 |
テスト部隊あるいは検査部隊の役割の基本は、システムが設計どおりにできているかよりも、要件定義書どおりにできているかどうかを確認することである。ただ残念ながら、要件定義書がきちんと書かれているシステムは少ない。要件定義書のすき間を埋めるためには、定義された要件の背景にある考え方や、システムに求められている真の目的や本質が何かに強い関心を持たなければならない。本質のしっかりした認識を基礎にして、過去に経験したシステムや類似システムから得られた知恵をテストに生かすべきである。
例えば、不特定多数の人々に関連する社会基盤システムなどにおいては、処理が間違ったり、システムが事故を起こしたりした場合には甚大な影響が出ることが予想されるだけに、何とかしのげるだけの対策ができているかどうかをぜひテストしておきたい。
 |
仕様書どおりにできているし、特に間違っているわけでもないが、実際にシステムを使ってみると、「なんとなく使い勝手が悪い」とか「出てくるメッセージに少々の違和感を覚える」など、エンドユーザーの立場で見ると「もう少し何とかしてほしい」と思うようなことが、時に発生するはずだ。テスト担当者が感覚的に気付いた点は、不良（×）とは言わないまでも、改善要望の形で設計者に投げかけるべきだろう。
これらの気になる点は、システム稼働後に顧客からクレームや要望として変更を要求される可能性が高い。しかも、稼働後に対策を取ろうとすると、対策失敗の怖さもあるし、稼働前の対策と比べコストが数段増えてしまう。それだけに設計者としては、顧客と相談して、直すべきことは先に直しておくほうがいい。
 |
高い処理能力が要求されるシステムでは、処理能力の測定・確認が大事な仕事になる。しかし、処理能力の測定はそう簡単ではない。特に、どういう値を、どういう条件下で、どういう方法で測定するのかをよく検討しなければならない。
少なくとも測定結果を報告するときは、単にいくらの値が出たというだけでは話にならず、測定方法、測定環境、測定条件などをきちんと記録・報告しなければならない。処理能力不足に対する改善策を講じたとしても、改善前後の測定条件を合わせておかない限り、何を言っているのかが分からなくなってしまうからだ。
 |
特定の人気列車に呼が集中する座席予約システムや、特定物件に売買が集中する取引システムやオークション・システムにおいては、どこまでの高トラフィックに耐えられるかが重要な課題である。想定以上に呼が集中したときにシステムが動かなくなったり、異常な動作をしたりしないかも確認する必要がある。それには高負荷テストができるような環境を用意しなければならない。
初期のオンライン・システムでは、全端末に人が張り付き一斉に要求呼を発信して高トラフィックな状況を作ってテストすることもあった。それが今のように、端末数も増えインターネットの活用が増えてくると、全端末に人を張り付けるなどということは、とてもできない。一種のシミュレーション・テストを考えざるを得ないだろうし、擬似呼を大量に発生できるテスト装置を作る必要があるかもしれない。
いずれにしても高負荷テスト環境を実現することは口で言うほど簡単でなく、基本設計段階から解決策を考えておかなければならない。どこまで実態に近付ける必要があるかは、システムの特性や高トラフィック時の問題の深刻さを考えて、日程や予算措置も含めて、事前に顧客とよく議論しておく必要がある。
