単体テスト、結合テスト、総合テストのそれぞれのテストで、障害（バグ）が発生したときは、プログラムを修正し、再テストを行うと思います。
このとき、あなたは、どのような再テストを行っていますか？
まず考えられることとして、障害（バグ）が発生した箇所がちゃんと正しくなっているかを見るということが挙げられます。このテストは必ず行うとは思います。
ですが、この障害（バグ）を修正したことによる影響の確認はどうでしょうか？
今回は、単体テスト、結合テスト、総合テスト、障害（バグ）発生時に、必ずやるべきテストとして、リグレッションテストが必須であることを学んでください。
リグレッションテストとは？
リグレッションテストとは、回帰テストとか、デグレーションテストとも呼ばれます。
障害（バグ）を修正したことにより、別の障害（バグ）が発生していないかを確認するテストのことです。
テストというと、単体テストや結合テストの他に、テストってあるの？と勘違いをする方もいると思いますので、補足しておきます。
リグレッションテストは、単体テストや結合テストのような工程ではなく、どのようなテストをおこなうのかを決めるための、テストの観点です。
ですから、正確にはテスト観点として、新たな問題が発生していないことの確認をするという意味合いになります。
このリグレッションテストは、障害（バグ）発生時には必ず行わなければいけません。
そして、障害（バグ）発生時だけではなく、単体テストや結合テスト、総合テストにも、リグレッションテストを盛り込むべきです。
では、なぜ、リグレッションテストを行う必要があるのでしょうか？
リグレッションテストの目的とは？
リグレッションテストは、別な障害（バグ）が発生していないかを確認するテストだということを述べました。
この、別な障害（バグ）が発生していないかを確認することは、いったい、何を確認しようとしているのでしょうか？何を気にしているのでしょうか？そこに、リグレッションテストの目的があります。
正しく動作している他の部分が壊されていないことを確認しようとして、実際に壊れていないかを気にしているのです。
まわりくどい言い方をしていますが、障害（バグ）が発生していないにもかかわらず、実際に障害（バグ）があった場所を修正したことで、その影響を受け、新たな別の障害（バグ）になる可能性があるため、あえて、このような言い回しをしています。
つまり、リグレッションテストの目的は、システムに修正を加えた場合、修正した場所以外は、今まで通りに動作することを保証するためなのです。
全くの新規でシステム開発を行う場合であれば、全てが新規であるため、全てをテストすることでしょう。ですので、リグレッションテストという思考はないかもしれません。
しかし、一度でも障害（バグ）が発生した場合、他に影響が出てないかどうかを確認しなければいけません。正しく動作する保証がなくなってしまうのですから。
それを保証するのが、「リグレッションテスト」なのです。
リグレッションテストは、デグレーションテストや単にデグレ確認とも呼ばれます。
デグレとは、デ・グレードのことで、グレードが下がることを指します。グレード・アップの逆です。今まで使えていた機能が使えなくなるということです。
デグレが発覚した場合、非常にまずい状態であることが理解出来ると思います。
リグレッションテストを行わないリスク
これまで述べてきたように、リグレッションテストはとても重要です。
そして、リグレッションテストを行わないことによるリスクが非常に高いということを認識してください。
ユーザーテストの段階や納品後にデグレが発覚した場合、今まで使えていた機能が突然使えなくなっているのです。誰が考えても、信用を失います。
例えば、スマホでメールができていたのに、新しいバージョンのソフトに変更したら、メールが使えなくなったとしたら、どう思いますか？
戦略的に次期バージョンからはメール機能を廃止しますというのならば、それは仕様ですので、問題ありませんが、そうではないのなら、あきらかに、機能低下でデグレを起こしている状態なのです。
この後の対応は、地獄絵図が待っています。
リグレッションテストを行うことで、このようなリスクを回避することができるのですが、驚くことに、リグレッションテストを行っていないプロジェクトが多すぎます。
ほとんどのプロジェクトで、障害（バグ）が発生したあとは、そこに関わるプログラムを修正し、問題なく動作することを確認して終わりにしているのです。
そこに新たな問題が潜んでいたら、リグレッションテストをしない限り潜んだままになります。表に出るのは、決まって、システムが納品され、稼動した後だったりします。
ですから、障害（バグ）発生時はもとより、各テストにおいても、修正した箇所に対するリグレッションテストは必ず行う思考をもつようにしてください。
例えば、今までは、入力した値が0～69までは「不合格」、70～100までは「合格」、101～または0未満、文字はエラーと表示する箇所があったとします。
そして、今回のシステム開発では、50～59までを「見直しが必要」、60～69までを「合格まであと一歩」と表示するように変更を行うことになりました。
プログラミングを終え、テストをしてみます。
入力値に、59を入力したところ、「見直しが必要」が表示され、60を入力したところ、同じく「見直しが必要」と表示されました。
本来であれば、60を入力した場合、「合格まであと一歩」と表示されるべきなので、障害（バグ）となります。
障害（バグ）が発生したため、プログラムを修正します。
プログラムを修正した結果、60を入力して「合格まであと一歩」と表示されるようになるのを確認できました。
しかし、今まで59を入力した場合に「見直しが必要」と表示されていたのに、「合格まであと一歩」と表示されてしまうようになりました。
これはプログラムを修正したことにより、新たな障害（バグ）が発生してしまったということです。
つまり、デグレが発生したということになります。
このことから、リグレッションテストで59の入力値の確認をしていなければ、デグレを抱えたまま次工程に進んでしまうことになるのです。
この障害（バグ）が発覚するのはシステムが稼動してからでしょうか？非常にリスキーであることが分かります。
デグレを発生させないために、障害（バグ）発生時、単体テスト、結合テスト、総合テストそれぞれにおいて、「リグレッションテスト」を行うことが大事であることを再認識してください。
カテゴリ：問題管理
