TOP＞プロジェクト管理＞ テスト仕様書をみるポイント

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第10回：本番に向けてのテスト 著者：システムクリエイト  田中 徹   2005/1/28

前のページ  1  2   3  次のページ

テスト仕様書をみるポイント

テストを行う前に開発会社はテスト仕様書と呼ばれるものを作成し、それに則って検証作業を行うのが一般的です。    形式はさまざまで、処理機能全てについて漏らさず書いてあるのですが、そこに落とし穴があることが多いのです。「0割」と呼ばれる0件での処理やMAXのデータ件数を超えるテストなどのかなり特殊なケースと、正常処理されるケースが同列に書かれていているので、同じレベルでテストされます。    特殊処理を疎かにしていいわけではありませんが、一番多いケース、頻繁に発生するケースを特に重点的に行うべきです。テスト仕様書についても納得いくまでSEと話し合ってください。    システム開発全般について言えることですが、成功・失敗の要素がもっとも多く含まれるのが、初期段階の設計と本番開始前のテストであることは、疑いの余地がありません。開発会社が作成したテスト仕様書を発注担当者が見て、欠けている内容、時間を割いてテストを行いたい機能などがあればどんどん進言するべきです。    どの機能も重要ですが、特に「この機能がダウンしたら話にならない」という、最重要項目があれば、それもSEに伝えてください。

旧システムが存在する場合

形式はさまざまで、処理機能全てについて漏らさず書いてあるのですが、そこに落とし穴があることが多いのです。「0割」と呼ばれる0件での処理やMAXのデータ件数を超えるテストなどのかなり特殊なケースと、正常処理されるケースが同列に書かれていているので、同じレベルでテストされます。    特殊処理を疎かにしていいわけではありませんが、一番多いケース、頻繁に発生するケースを特に重点的に行うべきです。テスト仕様書についても納得いくまでSEと話し合ってください。    システム開発全般について言えることですが、成功・失敗の要素がもっとも多く含まれるのが、初期段階の設計と本番開始前のテストであることは、疑いの余地がありません。開発会社が作成したテスト仕様書を発注担当者が見て、欠けている内容、時間を割いてテストを行いたい機能などがあればどんどん進言するべきです。    どの機能も重要ですが、特に「この機能がダウンしたら話にならない」という、最重要項目があれば、それもSEに伝えてください。

ドキュメントについて

いよいよ本番ともなれば、いままでたくさん説明してきたドキュメントの重要性はさらに増していきます。テストを終え、本番稼動してしまえば、疎かになりがちなドキュメントについて、ここでもう一度おさらいしておきましょう。

チェックする意味

システムの設計書、プログラム仕様書などをチェックする意味は2つあります。1つは、内容が正しいかどうかという正当性の確認です。もうひとつは必要なものが全て揃っているかどうかの確認です。    発注者の多くは前者に対しては気を使い十分な時間を割いてチェックする人が多いですが、後者に対して気づかないことが多いようです。どちらもとても大切なことです。内容を確認するのはトラブル、バグなどが発生した場合、プログラムレベルのミスなのか、システム設計のミスなのか、事後処理後、どう修正するのかを判断するのに欠かせないものです。    またドキュメントが全て揃っていないと、2次開発や大規模メンテナンスのときにとても困ります。

ドキュメントの見方

システム発注や設計書を見ることが初めてなら、ドキュメントを見ても内容が分からないとかどうやってみればいいのか、という方が多いのは当然のことです。しかしこれも慣れなのですが、実はそんなに大変なことではないのです。    基本設計書や機能概要書などは、システム構成図などといっしょにシステムの根幹に関すること、基本的な内容が書かれているものです。SEに細かく説明してもらいながら話を聞けば十分理解できるように書いてありますので、分からないところはどんどん訊いてください。質問する内容によってSEもどの程度まで理解できるのかを判断し、今後はそれを踏まえて作成してくれるでしょう。    コード体系やキーなどをまとめたものは、ほかのシステムとのリンクなどでとても重要なものです。さらに、このあたりのチェックをおろそかにし、あとで変更が発生した場合その影響は膨大で思わぬ工数が掛かることがあります。    プログラム設計書に関してですが、これもむずかしいことではありません。プログラミングに必要なことも合わせて書かれていますが、発注者が読むときに必要なことは「入力・処理・出力」のことだけで十分です。    「プログラムは何するもの？　コンピュータとは何をするもの？」の答えと一緒ですが、「プログラムとは何かを入力し、処理し、何かを出力するもの」というのが定義です。このポイントだけを押さえてプログラム設計書を見れば簡単に把握でき、処理が足りる・足りないが判断できます。    ネットワーク構成図などは、「この環境で何ができるのか？」、「こちらが運用したいイメージをこの環境で実現可能か？」ということを聞けば十分でしょう。比較検討できる代替案を参考程度に聞けば、さらに深く理解できるでしょう。

前のページ  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回 よりよいシステムにするために