ここでは、リリース後に発生する「保守テスト」について解説します。
■保守テストとは
ソフトウェアの開発が終わり、製品がリリースされると、開発者はついつい安心しがちです。しかし、製品をリリースした後に待っているのが、ソフトウェアの保守です。保守の期間は製品がリリースされてから、通常は数年、長いときで数十年にわたります。
この期間で、システムや構成データ、または動作環境の修正・変更・拡張が何度もおこなわれます。
また、開発の過程でいくらテストをおこなって、数多くの欠陥を修正しても、リリース後にも欠陥は見つかってしまうものです。
すると、その欠陥の修正もおこなわなければいけません。
その他に、なんらかの原因でサーバーやシステムがダウンしてしまった場合の復旧作業と、その後の再発防止対策などもおこないます。
このように、製品リリース後のソフトウェアに対して修正をおこなった場合におこなうテストを「保守テスト」と呼びます。
実際に、保守テストが必要になる場面には以下のものがあります。
●ソフトウェアの変更をおこなった場合
もともと予定されていた機能の拡張や、リリース後に必要になり追加した機能、仕様変更や見つかった欠陥の修正など、ソフトウェアに手を加えた場合、保守テストが必要です。
●ソフトウェアの動作環境が変わった場合
一般的に、保守テストはソフトウェア自体に変更があった場合に、その箇所をテストする印象が強いと思います。
しかし、OSやデータベース、その他COTSソフトウェアなどのバージョンアップや修正パッチの適用など、
ソフトウェア自体に変更はなくても、動作環境や周辺のソフトウェアに変更があった場合、そのソフトウェアのテストが必要です。
●新しい環境への移行をおこなった場合
ソフトウェアを動作させているOSやサーバー、ハードウェアなど、 今のプラットフォームとはまったく別のプラットフォームに、ソフトウェアの移行をおこなった場合、その環境でのテストが必要です。
●システムの回収作業をおこなった場合
システムの入れ替えや、長期間のデータ保有をする際のデータの移行や保管もテスト対象になります。
■改修・変更による影響をテストする「回帰テスト」
回帰テストとは、ソフトウェアに変更・改修を加えた際に、その変更・改修によって他の箇所で別な欠陥が生まれていないかを検証します。独立した新しい機能を作った場合は、その範囲でテストをおこなえば問題ありませんが、既存のシステムの修正や追加をおこなう場合、その他のプログラムに何の影響も与えていないことを確認するのは大変です。
また、最近のシステムは大規模で、各プログラムが複雑にむすびついていることが多く、
一見すると何も影響がなさそうに見える部分でも、欠陥や誤作動に結びつく場合があります。
そのため、回帰テストは、できるだけシステムを網羅するように実施されるべきですが、
上記のように「既存のシステムに欠陥が見つかっていて修正が必要」という場合には、早急な対応を求められることも少なくありません。
そのため、回帰テストの実施範囲は、人的リソースと時間的なリソースを考慮したうえで、慎重に決める必要があります。
■回帰テストを左右する「影響度分析」
影響度分析は、回帰テストなどのテスト実施範囲を決定するための材料となるものです。具体的には、手を加える箇所とその他の機能の関連性をあらかじめチェックすることで、システム全体の中でも影響の大きそうな部分を分析することです。
このとき、仕様書やプログラムのトレーサビリティ（追跡可能性）が高いと、分析をスムーズにおこなうことができます。
★まとめ
●保守テストとは、リリースした製品への改修や変更に対するテスト●回帰テストとは、変更・改修によって他の箇所で別な欠陥が生まれていないかを検証すること
●影響度分析の精度によって、回帰テストの範囲が変わる
ここまでで、保守テストの概要と、実際にどのようなテストをおこなうかについて解説してきました。
絶対に修正や変更のないシステムを作ることは不可能なので、開発の段階から保守のことを考えた実装ができるように心がけましょう。
【参考文献】：
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』
【参考URL】：
http://www.info.shonan-it.ac.jp/lecture/Software1Eng/sweng1-6.pdf,（参照 2016年7月30日）
http://allabout.co.jp/gm/gc/296679/,（参照 2016年7月30日）