さてよくある話ですが機能変更の雨嵐の中、いよいよプロジェクトの期限、リリース日が目前になってきますが、問題なのはテストです。機能変更により単体テストレベルからのやり直し、結合・総合テストの日程などとうに消えています。どうしようもないのでテスト要員の増員残業指示、そしてテスト内容の大幅カット リリース日の若干の引きのばし・・・・ 運用開始後のバグの雨あられ、だれでも夢見たことがあるであろう悪夢です＾＿＾；。
とはいえ、似たような状況になってしまったことは誰でもあるのではないでしょうか？ なぜそうなるのか、機能変更は前回書いたように必要なことですし、リリース日が簡単に動かせないのは諸々の事情でしかたがないことです。また、増員したところでたいした効果はないうえ、そもそも増員する予算もしくは、人がない場合がおおいです。そして犠牲になるのかテスト内容の効率化という名目での手抜きです＾＿＾；
そこで、スケジュールを組む場合、テストの部分はなにがなんでも余分に確保するようにします、機能変更対応等をあらかじめスケジュールに組み込むことは、なかなかとおりませんが、テストという名目なら品質向上のためと言う名目で、とおりやすいです。また、設計段階からテストの効率化を考えて設計しておくことにより、テスト項目を削減することは十分可能です。
本来、テストは開発・製造関連プロジェクトにとっては、品質向上のためにおこなわれるものですが、運用段階での要求仕様の見直しをテスト段階で行い、機能変更を行うことにより、運用レベルでの全体的な品質向上を行うことが可能であり、また、機能変更によるスケジュールの見直しをテスト工程に集中させることによりコントロールを容易にすることが可能となります。
現状でのテスト工程は、品質向上だけではなく、スケジュール管理、機能変更などさまざまな要因を制御するための最重要な工程となっています。