前回に続き、「テスト」を巡るさまざまな事項や課題を取り上げる。テストにも顧客の立場に立った、多角的な視点が欠かせない。そして稼働後の事故防止につながるバグ情報の分析と活用も重要だ。
 |
テスト中に偶然、変な現象が発生したが、発生条件や経緯が不明確で不良とは断定しにくい場合も出てくる。それでも、「こんなあいまいな事故報告では設計者も納得しないから報告しないでおこう」と無視するのはやはりよくない。あいまいな事象でもせっかく見つかったのだから問題点として取り上げ、報告しておく必要がある。
確認のため再テストしても再現せず、原因究明もできなくて、最終的には何の対策も打てないかもしれないが、重大な事故の前兆である可能性もあるのだから、見つけたものは根拠薄弱でも設計者にきちんと伝えたいものだ。
 |
総合テスト段階になると、システムの品質は安定してくるが、それでも週に1回とか、月に1回とか事故が発生し、顧客から品質の見直しが要求されることがよくある。ベンダーとしても、当然見直して再テストも試みるが、新たな不良がなかなか見つからず、また1カ月もすると別の事故が起こる。そして、再度の見直しを要求されることになる。
見直しテストをしても不良が見つからないということは、冷静に考えれば、別のテストをしたつもりでも、実は過去と同じテストを繰り返したに過ぎなかったのではないだろうか。
こうしたことを避けるためにも、テスト実績をきちんと記録することが必要である。行き当たりばったりのテストをやっていると、無駄な時間を費やすだけになる。
 |
テストの結果、不良が判明したときは修正が必要であるが、修正ミスを起こさないよう慎重に対処したい。修正がうまくいったかどうかの確認テストは誰でもするだろうが、修正した部分の確認は比較的簡単であっても、修正の副作用で、今まで正しく動いていた部分がおかしくなっていることを見つけるのは難しい。
動かしたときはうまく動くように見えても、後から修正の副作用、デグレードが見つかるのが怖い。特に母体の開発者ではない設計者が修正せざるを得ない場合、修正不良は起こるものと考えて、より慎重にテストするとともに、別の設計者に修正内容をレビューさせるなどの対策を考えるべきであろう。
 |
プロジェクト後半になって、仕様変更が発生したり、バグが発見されたりして修正することはよくあることだ。だが、修正ミスにより、それまで問題なく動いていたところが動かなくなるようでは困るので、修正ミスがないかどうかのいわゆるリグレッション・テストやデグレード防止テストが必要になる。
それらのテストにおいては、それまでに実施してきたテストを再実行しなければならないが、この再テスト・再確認は最初にテストしたときのように手作業でやるのは時間がかかり大変なだけに、極力自動化できるように準備したい。
すなわち、最初にテストしたときのテスト条件や入力データ、テスト結果をディスクなど外部記憶装置に取っておき、記録された入力データを使って自動的にシステムを動かす。そして、出てきた出力結果を当初テスト時に記録しておいた結果と自動的に比較し、その良否を判定できるような仕掛けやツールを事前に準備しておきたい。
