テストは時間とお金を意識して実施する

システムを改修して、無事テストも完了すると、本番環境への移行を行います。

自分が休む日に本番移行して、新しい業務を開始する事はやめておいた。どんなにテストしても本番移行後に何かしら問題は起こり得る。問題が発生する領域を概ね以下の三つで分類してみました。

1．システムの内容そのもの

2．移行による問題

3．システム連携による問題

1の「システムの内容そのもの」は単純にテストの量と質に比例すると思う。テストの量や内容が本番業務を想定していないものであれば、あるほど、本番移行後に問題が起こる。対策としては、業務部門、つまり利用者に本番業務と同じテストをしっかり行って貰う事となる。

2の「移行による問題」は、主にヒューマンエラーが多い。移行を完全に自動化するのは難しい。人間の手によってリリース内容の準備やアップデートに関する対象物（プログラム、設定情報）を漏れなく、移行しないといけない。もちろん、移行を自動で行うツールや機能もあるが、その設定を行うのは人間だ。移行対象物を漏らしたり、移行時間の設定や移行先を間違う事もあるだろう。以前、あるベンダーと仕事をしていて、そのベンダーは移行のテストも行っていた。当時は移行のテストまでするのかとやや驚いたが、今思うと、納得がいくし、なるほどなと思う。

3の「システム連携による問題」は、環境によると思う。システム活用が進めば進むほど、沢山のシステムがあると思います。そのシステムの全てがテスト環境を持っている訳ではないと思います。そうすると、テストしない部分が出てきてしまいます。本番移行した後、その部分で問題が起きる事があります。

テストをどこまでやるかは、お金と時間との相談になります。システム担当者が一人でテストしても、完璧なテストは出来ないでしょう。業務担当者ではないので、テスト内容はどうしてもホワイトテストになりがちです。効果的なブラックボックステストは業務担当者でなければできないと思います。また、ヒューマンエラーも人間である以上防ぐことは難しいです。システムのテスト環境を完璧に準備する事も難しいでしょう。これもお金がかかる問題なので。

私の場合、実際的には、限られた時間とお金の中で、最小限の工数で可能な限り効果的なテストになるように、テストを実施するという感覚でやってきました。中小企業では、大体一人で全てをやらないといけないと思います。時間もお金も限られています。また、テストをやればやるほど、良いと思いますが、テストそのものは価値を産み出していません。従って、テスト作業そのものが他者から評価されにくいです。その点において、一人情シスの担当者がテストにあまり時間をかける動機も低くなりがちです。最終的には、システム担当者が、自分なりに時間とお金をどこまで使ってテストをするかを見極めて、やるという判断になると思います。