 |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| テスト仕様書をみるポイント | ||||||||||||||||||||||||||
|
テストを行う前に開発会社はテスト仕様書と呼ばれるものを作成し、それに則って検証作業を行うのが一般的です。 形式はさまざまで、処理機能全てについて漏らさず書いてあるのですが、そこに落とし穴があることが多いのです。「0割」と呼ばれる0件での処理やMAXのデータ件数を超えるテストなどのかなり特殊なケースと、正常処理されるケースが同列に書かれていているので、同じレベルでテストされます。 特殊処理を疎かにしていいわけではありませんが、一番多いケース、頻繁に発生するケースを特に重点的に行うべきです。テスト仕様書についても納得いくまでSEと話し合ってください。 システム開発全般について言えることですが、成功・失敗の要素がもっとも多く含まれるのが、初期段階の設計と本番開始前のテストであることは、疑いの余地がありません。開発会社が作成したテスト仕様書を発注担当者が見て、欠けている内容、時間を割いてテストを行いたい機能などがあればどんどん進言するべきです。 どの機能も重要ですが、特に「この機能がダウンしたら話にならない」という、最重要項目があれば、それもSEに伝えてください。 |
||||||||||||||||||||||||||
| 旧システムが存在する場合 | ||||||||||||||||||||||||||
|
形式はさまざまで、処理機能全てについて漏らさず書いてあるのですが、そこに落とし穴があることが多いのです。「0割」と呼ばれる0件での処理やMAXのデータ件数を超えるテストなどのかなり特殊なケースと、正常処理されるケースが同列に書かれていているので、同じレベルでテストされます。 特殊処理を疎かにしていいわけではありませんが、一番多いケース、頻繁に発生するケースを特に重点的に行うべきです。テスト仕様書についても納得いくまでSEと話し合ってください。 システム開発全般について言えることですが、成功・失敗の要素がもっとも多く含まれるのが、初期段階の設計と本番開始前のテストであることは、疑いの余地がありません。開発会社が作成したテスト仕様書を発注担当者が見て、欠けている内容、時間を割いてテストを行いたい機能などがあればどんどん進言するべきです。 どの機能も重要ですが、特に「この機能がダウンしたら話にならない」という、最重要項目があれば、それもSEに伝えてください。 |
||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||
| ドキュメントについて | ||||||||||||||||||||||||||
|
いよいよ本番ともなれば、いままでたくさん説明してきたドキュメントの重要性はさらに増していきます。テストを終え、本番稼動してしまえば、疎かになりがちなドキュメントについて、ここでもう一度おさらいしておきましょう。 |
||||||||||||||||||||||||||
| チェックする意味 | ||||||||||||||||||||||||||
|
システムの設計書、プログラム仕様書などをチェックする意味は2つあります。1つは、内容が正しいかどうかという正当性の確認です。もうひとつは必要なものが全て揃っているかどうかの確認です。 発注者の多くは前者に対しては気を使い十分な時間を割いてチェックする人が多いですが、後者に対して気づかないことが多いようです。どちらもとても大切なことです。内容を確認するのはトラブル、バグなどが発生した場合、プログラムレベルのミスなのか、システム設計のミスなのか、事後処理後、どう修正するのかを判断するのに欠かせないものです。 またドキュメントが全て揃っていないと、2次開発や大規模メンテナンスのときにとても困ります。 |
||||||||||||||||||||||||||
| ドキュメントの見方 | ||||||||||||||||||||||||||
|
システム発注や設計書を見ることが初めてなら、ドキュメントを見ても内容が分からないとかどうやってみればいいのか、という方が多いのは当然のことです。しかしこれも慣れなのですが、実はそんなに大変なことではないのです。 基本設計書や機能概要書などは、システム構成図などといっしょにシステムの根幹に関すること、基本的な内容が書かれているものです。SEに細かく説明してもらいながら話を聞けば十分理解できるように書いてありますので、分からないところはどんどん訊いてください。質問する内容によってSEもどの程度まで理解できるのかを判断し、今後はそれを踏まえて作成してくれるでしょう。 コード体系やキーなどをまとめたものは、ほかのシステムとのリンクなどでとても重要なものです。さらに、このあたりのチェックをおろそかにし、あとで変更が発生した場合その影響は膨大で思わぬ工数が掛かることがあります。 プログラム設計書に関してですが、これもむずかしいことではありません。プログラミングに必要なことも合わせて書かれていますが、発注者が読むときに必要なことは「入力・処理・出力」のことだけで十分です。 「プログラムは何するもの？ コンピュータとは何をするもの？」の答えと一緒ですが、「プログラムとは何かを入力し、処理し、何かを出力するもの」というのが定義です。このポイントだけを押さえてプログラム設計書を見れば簡単に把握でき、処理が足りる・足りないが判断できます。 ネットワーク構成図などは、「この環境で何ができるのか？」、「こちらが運用したいイメージをこの環境で実現可能か？」ということを聞けば十分でしょう。比較検討できる代替案を参考程度に聞けば、さらに深く理解できるでしょう。 |
||||||||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
-
-
連載
