第10回:本番に向けてのテスト (1/3)

システム発注担当者
だからあなたの会社のシステムは動かない
〜システム発注担当者の悩みを解決します〜

第10回:本番に向けてのテスト

著者:システムクリエイト  田中 徹   2005/1/28
1   2  3  次のページ

   開発も一通り終わり、後は十分なテストを行って本番稼動を迎えるまでになりました。全てが仕様書通りに作成されており、仕様書に欠陥がなければ上手く動くはずです。テストの手順、準備などはどうすればいいのでしょうか?
テストの種類

   システム開発では、段階的に行われるテストを次のような表現と内容で分けています。

  • 単体テスト:
    プログラム単位のテスト。プログラム作成時にプログラマが行う。

  • 結合テスト:
    一連の処理、関係箇所を流してのテスト。特定機能検証。

  • システムテスト:
    システム全体を通してのテスト。本番と同様のデータ、環境を用いて行うことが望ましい。

テストの種類

   プログラム開発も終盤になってくると、担当SEからシステムテストについての話が出てきます。プログラム単位では単体テストを十分に行っているはずですから、全てが設計書通りに作られていれば、あとは「結合してどうなるか」なのです。さて、その前に準備しておくこと、心得は何でしょう。

   まず、十分なテスト期間が設定されているかどうかが一番の問題点になります。とかくテストは軽く見られがちですが、十分な期間をかけ、納得いくまで機能検証を行わなければ、本番を迎えることはできません。

   さらに最近では大規模ネットワークを構築したり、他システムとの結合を行っていたりと、環境作りでも一苦労しそうなシステムが多くあります。システムテストですので、本番と同じ運用環境で、それが無理ならなるべく近い形でテスト環境を構築することが必要です。


テストデータを用意する

   開発者は単体テストにおいてテストデータを作成して検証を行っていますが、結合テストでは可能な限り発注側から本番で使用するデータと同じものを提供してください。重要なことですが、データの中には機密事項が含まれることも多いでしょうから、必ず提供するデータは加工してください。本番で使用するデータと同じものを使うというのは、後々「本番と違うデータを使用したため想定外のケースだったので…」と言われないための対策です。

   データの加工のしかたについては、各社それぞれ情報に関する取り扱いガイドラインがあるでしょうから、それに則って行えばいいでしょう。しかし、明確なものがない場合のために、アドバイスしますので参考にしてください。


テスト用にデータの加工をする

   まず、データを加工するSEかプログラマを一人専任させます。これにより万が一情報漏洩があっても、責任の所在が明らかになります。専任するプログラマは元請の正社員に限ります。孫受けや契約社員、アルバイトは避けましょう。

   そしてデータを加工するのは手作業では行わず、データ加工用プログラムを作成してもらいます。これは、生データを極力直に触らせないということです。プログラムを作成して加工するより手作業の方が圧倒的に短時間で済む場合も多いでしょうが、それでもプログラムで加工するように指導します。

   データ加工用のプログラムはソースコードも納品してもらいます。所有権は発注側に帰属します。ソースコードを発注担当者が見ても分からないかもしれませんが、それでも納品してもらいます。そして発注担当者がデータのどの部分を加工しなければならないのか、直接指示してください。

   さらに一番重要なことは、開発側の技術者にフロッピーディスク、MO、CDにテストデータをコピーさせないことです。別のPCにコピーする必要がある場合は、発注担当者が行ってください。MOを使う場合でもネットワーク上でPCとPCでコピーする場合でも、発注担当者以外の人間がテストデータをコピーすることは絶対に避けてください。


テスト用データを管理する

   これで発注側には「加工前の生データ」、「加工後のテストデータ」、「加工用プログラム」があることになります。これをきちんとした方法でしばらく管理・保管してください。このデータ加工手順内容を明らかにした書類も作成してください。

   上司から情報管理について聞かれたら「私と開発会社の○○君(データ加工先任者の名前)の責任において行っています」と答え、データ加工手順内容書を提示すればいいでしょう。この方法でも100%完璧なデータ管理、情報管理とは言い切れませんが、後はあなたの会社で工夫して、情報に関する取り扱いガイドラインを作成してください。

   昨今、新聞紙上でデータの流出に関する記事を多く見ます。悪意を持って挑めばデータの流出を阻止するのは困難かもしれませんが、発注側がデータ(情報)に関しての管理を厳しくしていると思わせることで、隙あればデータを持ち出そうと思わせる気持ちを摘むことができます。

1   2  3  次のページ



著者プロフィール
システムクリエイト有限会社  田中 徹
代表取締役。1963年生まれ。MS-DOS時代から、汎用機−PCでのデータ送受信を行ってのチャート(金融業)、表・グラフ描画(財務系)などのシステム開発を行う。 社内人事管理(勤怠・人材活用)、流通業、制御系の分野や集計業務なども手掛ける。ソフトウェアハウスや大手開発会社まで多数の現場で開発を経験し、33歳で独立。現在は各業種・分野でSEとして、またシステムコンサルタントとして活動中


INDEX
第10回:本番に向けてのテスト
テストの種類
  テスト仕様書をみるポイント
  本番立会い
だからあなたの会社のシステムは動かない
〜システム発注担当者の悩みを解決します〜
第1回 システム発注担当者の苦悩
第2回 システム開発の流れ
第3回 開発形態と開発会社の規模による違い
第4回 見積もりについて
第5回 発注側の体制・社内体制を整える
第6回 発注担当者に必要なもの(1)〜業務知識とIT知識、業務フロー〜
第7回 発注担当者に必要なもの(2)〜社内調整、SEとの付き合い方〜
第8回 そもそもSE、プログラマってどんな人?
第9回 さあ困った 〜その時発注担当者がするべき事は〜
第10回 本番に向けてのテスト
第11回 先達に学ぶ 〜トラブル事例紹介〜
第12回 よりよいシステムにするために

人気記事トップ10

人気記事ランキングをもっと見る