テスト不足が招く不幸

テスト不足が招く不幸

いくつかのプロジェクトで共通的に起こっている現象があります。
端的に言ってしまえば、ベンダーによるテスト/検証不足によるシステム障害。

テストと言っても色々なレベルがありますが、

まずは単体テスト

作成したプログラムが所定の機能を満たしているか、または、誤動作をしないかなど、作成したプログラム単位で行うテストです。



次に結合テスト

このテストは内部結合と外部結合とに分けることができますが、細かい解説は抜きにして、各機能要素が正しく連動し動作をするかどうかを確認するテストです。

最後に総合テスト(システムテスト)

システム全体が要求された事項を満たしているかどうかを確認するためにテストです。


通常であれば、ベンダーによる各種テストが終了した後にユーザへ納品物が引き渡され、ユーザ側による受入検収を行います。

受入検収を行う過程で不具合が出るのは想定内ではありますが、
しかし
『これはどう見ても単体テストレベルで確認すべきこと』
と思われる不具合が多々見受けられるのです。

あるベンダーにおいては、通常では考えられない不具合を抱えたままのプログラムが納品されたため、『本当にテストは行ったのか?』と詰問したところ、自社にその環境がなかったのでやってませんとの回答。
それも、さも当たり前のように!

これらの事態を引き起こした最大の理由は、納期遅れによる焦りの対応によるものです。

事前にユーザに報告し、納期を延期するなどの対策を協議せず、『できます、やります』の掛け声に踊らされた結果、ユーザに最大の迷惑を掛けているのです。

もう少し、しっかりとした対応を心掛けて欲しいものです。

こちらもご覧ください

0 件のコメント:

コメントを投稿

システム設計書

システム設計書 システム開発における設計書。 名前の付け方、内容の記述の仕方、実はこれ、ベンダーによってまちまちなんです。 名前の付け方に関して言えば、外部設計書/内部設計書というベンダーもあれば、基本設計書/詳細設計書というベンダーもあります。 場合によっては...