目次

回帰テスト(regression test)

  • =レグレッションテスト
  • すべての機能のテストケースを実施し直すこともあるが、修正範囲や確認範囲に応じて回帰テストケースのセットを用意しておくのが一般的である。
  • 通常テストをする過程でバグが見つかったらそれを修正し、最後に新規バージョンとしてリリースする。テスト担当者はそのバグが期待通りに修正されていれば対応すべきバグのリストからはずす。しかしながら、バグは修正されていなかったり、新たなバグ(サイドエフェクトバグという)を発生させることがある。よって、サイドエフェクトバグが発生すると仮定して、回帰テストを行うべきである。
  • 唯一計画なしに行うテスト。
  • 一般に回帰テストは自動化が容易だと思われているが、ユーザーインタフェースに変更があった場合は自動化スクリプトがまったく走らなくなってしまうことがある。さらに回帰テストはそれほど多く実行されるものではない。バグが開発者によって修正された直後と出荷直前に回帰テストを行えば十分であるからである。よって、自動化のメリットはあまりない。
  • 回帰テストは時間がかかるため、重要度の高い順序で行うこと。
  • デグレードの発生を確認するためのテスト。
  • ソースコードに修正が発生したときは必ず回帰テストを実施する。
  • 回帰テストのテストケースは前回と異なるテストケースになる。
    • 回帰テストでは変更されたテストケースを含めたすべてのテストケースをテストすることが理想的である。
  • テスティングフレームワークを利用していれば、テストコードに書かれたテストの実行はツールが自動的に行ってくれるので、回帰テストをすべて手作業でやるよりも負担が軽減される。

参考文献

  • 『知識ゼロから学ぶソフトウェアテスト』
  • 『現場で使えるソフトウェアテスト Java編』
  • 『ソフトウェアテスト入門』