テストフェーズでの仕様変更に注意

以前は、単体テストの仕様書も作成していたが、最近は単体テストの仕様書は作成していない。以前といっても数年前だが、今は単体テストにJUnitを、使用するようにしている。

単体テストの有効性は、結合テスト時に、発生するNG項目の原因が限定しやすくなること、単純な不具合を先にチェックして修正できること。でも、単体テストも終了し、結合テストもほとんど終了した頃に、大きな仕様変更が入ることがある。仕様変更を行なうと仕様変更によるプログラムの影響範囲を、再テストしなければならなくなる。
仕様変更の修正量と再テスト項目数が多い場合は、仕様変更を次バージョンリリース時に延ばしたり、仕様変更自体を中止したりするようにしなければならない。

プロジェクト管理がずさんで、仕様変更時のプログラム修正量や影響度の検討やチェックが行なえないか、ユーザーの強い要望があって、どうしても大きな仕様変更を、リリース直前に行なわなければならない状況になったときは、テスト期間を配慮して、リリース日は絶対に延期するべきだ。

この辺を、うやむやにしたり、再テスト期間の見積もりがあまいまま進んでしまうと、品質の悪いプログラムが出来てしまう。そして結局、リリースが出来なくなる。そうなってしまうと泥沼状態になる可能性が高い。客先やユーザーにも迷惑が及んでしまう。もともとは仕様変更したことが、原因なのだが、仕様変更の影響を、ちゃんとお客先やユーザーにSE・プログラマーから説明しなかったことが、ユーザーには原因と映る。

リリース直前の仕様変更の影響が大きいとき、又は影響が大きいと思われるときは、仕様変更に反対するか、リリース日を延期してもらうように、強い態度でユーザーに説明するべきだ。それでも、仕様変更が実施される場合は、トラブルプロジェクトとなることをユーザーに理解してもらうしかない。その後は覚悟して、その後の仕様変更のチェックとバグの管理を徹底していくしかない。最終的には、健康管理が一番重要だと思う。

ユーザーによっては同じ過ちを、繰り返しているプロジェクトを、よく見かける。