継続的テスト

継続的テスト（けいぞくてきテスト、）は、ソフトウェアテストを自動化し、開発から本番環境への移行までの流れの中で絶えず実行して速いフィードバックを得る実践である。マスケローニ（Maximiliano A. Mascheroni）とイラサバル（Emanuel Irrazábal）は、2018年の系統的文献レビューで、これを、自動化されたあらゆる種類のテストケースをできる限り速く実行し、本番環境に移る前に重大な不具合を検出する過程であると結論づけている。この語は2003年に、サフ（David Saff）とアーンスト（Michael D. Ernst）が、開発者がソースコードを編集している間に使われていない計算資源でテストを背後で実行し続ける技法の名として用いた。継続的インテグレーション（CI）や継続的デリバリー（CD）とともに、DevOpsの文脈で扱われる。

概要 マーティン・ファウラー（Martin Fowler）は、継続的インテグレーションを扱った記事で、手作業のテストは変更の頻度に追いつかないとし、統合のたびに実行される包括的なテストスイートを主な技法に挙げ、この形のコードを「自己テストコード」（self-testing code）と呼んでいる。同記事は、自己テストコードが継続的インテグレーションの前提条件であるとし、継続的インテグレーションがエクストリーム・プログラミングの一部として生まれ、テストが同手法の中心的な実践であったと述べている。

マスケローニとイラサバルは、この概念が年を追って変化してきたとしている。当初は開発者の作業環境で単体テストを継続的に実行することだけを指していたが、現在は自動化できるあらゆる種類のテストケースに適用されるとし、その背景に、多様なテストを自動化できる道具が現れたことを挙げている。両者は56本の文献を対象とした同レビューで、継続的テストが継続的デリバリーの主要な目標の一つであり、継続的デリバリーと直接に関係すると結論づけている。

大規模な開発では、実行するテストの量そのものが制約になる。メモンらは2017年の報告で、Googleではコード変更ごとに個別に回帰テストを実行することはできず、コードの投入からテスト結果が開発者に届くまでの間隔が伸びるとし、品質を損なわずにテストの実行量を抑える取り組みを述べている。荻野恒太郎は、アジャイル・DevOps開発では短い開発サイクルの中で小刻みなフィードバックの循環を繰り返すため、開発から運用までを含む一連の過程の中での継続的なテストとフィードバックの獲得も求められるとしている。

主な要素 自己テストされるビルド 統合のたびに自動で実行され、ビルドの成否を判定するテストスイート。ファウラーは、テストが一つでも通らなければビルドを不合格とする扱いを挙げている。 テストの段階 マスケローニとイラサバルは、継続的デリバリーの事例で用いられる段階として、査読、ビルドと単体テスト、静的コード解析、統合テスト、インストール（配置）テスト、機能テスト、セキュリティテスト、性能・負荷・ストレステスト、探索的な手動テストの9つを挙げ、このうち単体テスト、機能テスト、性能・負荷・ストレステストが最も多く用いられるとしている。 テストピラミッド 種類の異なる自動テストの組み合わせを考えるための整理。ファウラーは、これを、利用者インタフェースを通す広い範囲のテストよりも低いレベルの単体テストを多く持つ形を示すものだと説明している。マイク・コーン（Mike Cohn）が2009年の著書『』で「テスト自動化ピラミッド」として記述したことで広く知られるようになったとされる。 テストの選択と優先順位付け 実行するテストを絞り、順序を変えて結果を早く得る手法。エルバウムらは2014年の報告で、コードの投入前の段階では回帰テスト選択の手法で対象を部分集合に絞り、投入後の段階ではテストケース優先順位付けの手法で結果が早く届くようにする方式を示し、いずれもコードカバレッジの情報に依存しないと述べている。

歴史 サフとアーンストは2003年の論文で、開発中に頻繁にテストを実行すると開発の進行が止まり、実行しないと不具合の発見が遅れるという二つの無駄な時間があり、実際の開発プロジェクトの調査ではこれらが開発時間の10%から15%を占めたと報告した。両者は、使われていない計算資源でテストを背後で実行し続ける技法を継続的テストと名付け、ソースコードの編集中に結果を速く返すことでこの時間が92%から98%減ったと述べている。両者は2005年に、統合開発環境Eclipseへの実装も発表している。

2010年代には、大規模な継続的インテグレーション環境でのテストが研究の対象になった。エルバウムらは2014年に、Googleの大規模なデータを用いて回帰テスト選択とテストケース優先順位付けの手法を評価した。メモンらは2017年に、テストが通らない事例は少ないが、それが起きるテストは対象のコードに近い位置にあるという傾向を示した。シャヒンらは2017年に継続的な実践の系統的レビューを、マスケローニとイラサバルは2018年に継続的テストに焦点を当てた系統的文献レビューを公開した。

関連する概念 継続的テストは、継続的インテグレーション、継続的デリバリー、継続的デプロイと並ぶ、開発を継続的に進める実践の一つとして扱われる。シャヒンらは、2004年から2016年6月までの69本の査読論文を対象とした系統的レビューでこれらの実践を支える30の手法と道具を整理し、その一つとして半自動または自動の継続的テストの支援を挙げている。マスケローニとイラサバルが挙げる2015年から2016年の定義の一つは、継続的テストを、品質保証と開発の段階を統合するシフトレフトの取り方でテストの速度を高めるために自動化された手法を用いることとしている。

関連項目 テスト自動化 CI/CD DevOps シフトレフト

脚注