PR

 結合テストフェーズでデグレード(デグレ)の発生に気づいた――。テスト担当者や開発担当者からすると、冷や汗が流れる瞬間だろう。バグ改修や機能追加でソフトウエアをバージョンアップすると、それまで正常に動いていた機能が動かなくなったりする。こうした、バージョンアップが逆に品質の低下を招くという現象を「デグレ」と呼ぶ。場合によってはテストの全面的なやり直しが必要になったりする。

 筆者が経験したあるプロジェクトでは、結合テストの開始から1週間が経過した段階でデグレを発見した。業務フローの最初に登場する機能でのデグレだったため、後続する機能のすべてに影響した。その結果、それまで1週間行ってきたテストをほぼすべてやり直す事態となった。もちろん、人手が足りない。プロジェクトチームメンバー総動員となった。

 別のプロジェクトでは、本番リリース時のデグレに気づかず、データ移行のプログラムを実行するというトラブルを経験した。テラバイト単位のデータがほぼ異常値となり、結局リリース時期を延期せざるを得ない状況に陥った。プロジェクトメンバー、ユーザー、ユーザーの顧客と多方面に迷惑をかける事態となった。

 デグレが発生する原因は複数あるが、確実に言えるのは「ソフトウエアのバージョン管理を行う『構成管理』の整備が遅れた現場では、デグレが起こりやすい」ということ。バージョンアップの基に古いプログラムを使ってしまったり、誤ったプログラムをリリースしてしまったりしやすいからだ。

 構成管理の不備は「開発環境とテスト環境で動作が異なる」といった問題も引き起こす。構成管理が整備できていないプロジェクトでは、開発者がローカル環境にあるプログラムを個別にビルドして、テスト環境にリリースすることになる。この際、開発者の足並みがそろわず、特定チームのリリースが遅れてしまう場合がある。こうなると、テスト環境に存在するシステムは本来想定していたソフトウエアではない、ということになる。

 デグレの発生、開発環境とテスト環境の差異の発生があると、少なくとも問題を発見した段階までの結合テストがやり直しになる。最悪の場合にはテストの停止、全テスト工程のやり直しにまで発展する。こうしたトラブルの発生を防ぐために、早めに構成管理を整備して起き得る問題を未然に防ぐようにしたほうがいい。

 問題の根本は結合テストの進め方や体制ではなく構成管理の不備にある場合が多いのだ。