Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第13回 【拾参】リグレッションテストは必ず実施する。

  2007/10/26 12:00

 システムに修正を加えた時、今まで動いていたところに影響が出ないことを保証するのが、リグレッションテストです。仕様の変更に伴う修正が入った場合も、システム全体への影響を慎重に考える必要があります。

リグレッションテスト

 Regression。「回帰」です。一回りして戻ること(明解国語辞典)。転じて、リグレッションテストは、プログラムなどに修正を加えた時、今まで行っていた処理には何も影響が出ないことを確認するためのテストについて使われる名前です。

 システム開発をやっていて大変困るのが、既存のシステムに修正を加えた時、今まで動いていたところに影響が出ないことを保証することです。新しく作った処理についてのテストは、その範囲で狙い撃ち出来るのですが、新しく作りこんだ処理が、今まで行ってきた処理の結果に何の影響も与えていないことを確認するのは大変なことです。

 もし、何万、何十万もの既存のプログラム処理命令について、今回加わった修正が、悪い影響を与えていないことを確認するテストケース、テストデータを、都度作り実施することになったとしたら、その実施だけでどのくらいの人、時間、お金といったリソースが必要でしょうか。

 そういうこともあり、多くの企業では、通常システム開発をする場合、単体テスト、連結テスト、統合テスト、運用テストと規模を大きくしながら検証を進めていきますが、完成して本番稼動を始めたシステムについて改定が入る場合は、こういった開発時に作成実施したテストのデータ、ツールなど、環境を保存して再利用することで、今回入った改定と既存の処理に影響がないことについての確認を行っています。

 このやり方は、合理的で効果があります。しかし、改定は常に全体に手を入れるような規模で発生するとは限りません、通常は一部のサブシステムに手が入るということが、繰り返されます。修正が入った該当部分だけのリグッションが保証されても、そのシステムとデータでつながっている他システムについては保証が得られません。

 とうことで、スコープを業務全体に広げ、修正の入った該当システムとつながりがあるシステムは全てリグレッションテストを実施することが必要になります。

 小さな修正なのに、何でこんなにテストをしなければいけないの? そう考える人がいても不思議ではないし、特にお金をだすユーザー発注部門の人に説明するのは大変です。しかし、既存の大規模業務システムは社会的に安全性と信頼性を要求されるものになってきています。小さな原因でも、大きな影響のあるトラブルをおこしかねません。仕事の大きさと、事故の大きさは比例しないのです(経産省『情報システムの信頼性向上に関するガイドライン』)。

 大変だから、簡単な修正だから、リグレッションテストをやらなくて良いというわけにはいかないのです。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 菊島 靖弘(キクシマ ヤスヒロ)

    独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。 1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管...

バックナンバー

連載:開発担当者必携!トラブル削減のための原則拾七ヶ条

もっと読む

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5