継続的テストは、ソフトウェア開発ライフサイクル (SDLC) のさまざまな段階で自動フィードバックを組み込むプロセスであり、展開を管理する際の速度と効率の向上をサポートします。

継続的テストは、CI/CD（継続的インテグレーション/継続的デリバリ）プロセスの有効性を支える重要な推進力であり、コード品質を改善し、コストのかかるボトルネックを回避し、 DevOps プロセスを迅速化することによって、SDLCのタイムラインを加速する上で重要な役割を果たします。

実用的な DevOps アプローチを開発する際の基本原則の 1 つは、迅速なソフトウェア配信と信頼性の高いユーザー エクスペリエンスとの間のギャップを埋めることです。しかし、各ソフトウェア開発段階（プロジェクト設計、コーディング、テスト、デプロイメント、メンテナンスなど）において、手作業でフィードバックを得るという従来の方法では、組織のリソースを不十分かつ効果的に活用できず、結果的に統合サイクルの長期化や製品アップデートの遅延につながっていました。

継続的テストは、DevOps チームの「左シフト」を支援し、手動テスト プロセスを自動化し、人的エラーを最小限に抑えながら、SDLC の早い段階で貴重なフィードバックを提供することで、これらの非効率性を解決します。

継続的テストは、自動化ツールを使用して、実稼働のすべての段階で事前定義された QA スクリプトをロードすることで機能します。これらの自動スクリプトにより、QA テストの実行時に定期的に人間が介入する必要がなくなり、ソース コードの効率を逐次検証しながら、関連するフィードバックが適切なチームに即座に提供されるようになります。

自動テストが失敗した場合、開発チームは開発の個々の段階で通知を受けるため、SDLC のさまざまな段階で他のチームに影響を与える「前に」ソース コードに必要な調整を行うことができます。自動化されたテストが検査に合格すれば、プロジェクトは自動的に SDLC の次の段階に引き継がれ、組織は生産性を最大化し、部門間の調整を改善する持続可能なデリバリモデルを構築することができます。

次のビデオでは、Eric Minick がこのトピックについてさらに詳しく説明しています。

継続的テストを DevOps プロセスに組み込むと、成長する企業にいくつかのメリットがもたらされます。

より効率的で質の高い配備。 継続的テストは、ソフトウェア開発ライフサイクル (SDLC) の各段階で品質保証とワークフロー間の品質相互運用を管理する自動化された方法を提供します。継続的なフィードバック ループをユーザー モジュールと単体テスト モジュールに統合することで、開発者は、コードをデプロイする前に、コードの互換性とパフォーマンスを向上させるために必要な実用的な洞察を得ることができます。この効率性により、複数の DevOps チーム メンバー間の切断が解決され、ソフトウェア配信スケジュールの加速がサポートされます。

分散プロジェクトの迅速なエラー発見と修復。今日の最新の開発アーキテクチャは多面的かつ多層になっています。継続的なテストは、エラーの発見と修復のタイムラインを大幅に改善するスケーラブルな自動テスト ソリューションを組み込むことで、開発チームがこれらの複雑さを解消するのに役立ちます。

ユーザーエクスペリエンスの向上。高度な継続的テスト手法では、さまざまな独自のユースケースやトラブルシューティングのシナリオをシミュレートし、ユーザーがそれらにどのように反応するかを観察できます。これらのシミュレーションから収集された洞察により、開発者はユーザー インターフェイスの非効率性を早期に排除し、物理製品の展開後の予期せぬ事態を回避することができます。

開発関連の業務中断によるコストの削減。 特に大規模な相互接続システムでは、アプリケーションの 1 つのモジュールだけで発生したエラーが波及効果をもたらし、望ましくないダウンタイムを引き起こし、生産性や収益に悪影響を与える可能性があります。

たとえば、クラウドプロバイダーは、地域全体を麻痺させ、数時間続く停止を引き起こす一方の端での故障を定期的に報告します。これは、高いサービス可用性を必要とする組織にとって特に壊滅的な影響を与える可能性があります。詳細なレベルでの継続的なテストにより、大規模なソフトウェア システムでは認識できない可能性のあるエラーが特定され、ビジネス中断によるコストの回避に役立ちます。

継続的テストには、システムの信頼性、セキュリティ、運用パフォーマンス、および使いやすさを保証するさまざまなテストが含まれます。スペクトルテストには次のものが含まれます。

• Shift-Left テスト: このアプローチでは、ソフトウェア開発ライフ サイクル (SDLC) の初期段階でソフトウェアとシステムのテストを優先し、将来の重大なデバッグ問題を軽減または防止します。
  
  
• Shift-Right テスト: このアプローチでは、ユーザー エクスペリエンス、全体的なパフォーマンス、耐障害性、および機能の向上に重点を置き、SDLC の終わり近くでのテストを優先します。
  
  
• Smoke テスト: これらのテストは手動または自動で行うことができ、ソフトウェアの顕著な欠陥を最初に大まかにスクリーニングします。Smokeテストの構築は複雑ではありませんが、ソフトウェアの重大なエラーを排除するための迅速かつ安価なソリューションを提供します。
  
  
• 単体テスト: ビルド全体にわたる小規模なストレス、負荷、ボリューム、またはメモリ リーク チェックを行い、開発の初期段階での機能低下を特定するのに最適です。
  
  
• 統合およびメッセージング テスト: ソフトウェア モジュールが相互に連携して動作しているときにエラーがないかチェックします。継続的なテストにより欠落している依存関係が仮想化されるため、チームはエンドツーエンドのプロセスとシナリオが全体的にどの程度適切に実行されるかをテストできます。次に、複合コードがコンパイルされ、実行時に実行され、期待どおりに動作するかどうかがテストされます。
  
  
• パフォーマンス テスト: アプリケーション ソフトウェアのパフォーマンスをテストするだけでは、最終的な運用環境のハードウェアとミドルウェアが考慮されていない可能性があります。ソリューションの全体的なパフォーマンスを効果的に評価するには、統合システム テストが必要です。
  
  
• 機能テスト: この形式のテストでは、ユーザー エクスペリエンスが期待を満たしているかどうか、および機能ワークフローがソフトウェア システム全体で必要に応じて実行されるかどうかをチェックします。たとえば、サプライ チェーン ソフトウェアは、在庫が出荷可能になったときにトラックに工場に到着するように警告できる必要があります。(対照的に、非機能テストでは、パフォーマンス、使いやすさ、信頼性、応答時間、ロード時間、スケーラビリティなどに焦点を当て、望ましい顧客エクスペリエンスを提供するためのソフトウェアの準備状況を評価します。)
  
  
• 回帰テスト: このテストでは、依存するソフトウェアのエラーが修正された後にパフォーマンス、機能、または依存関係に変化があるかどうか、またシステムが以前と同様に動作するかどうかをチェックします。
  
  
• ユーザー受け入れテスト: アプリケーション テストまたはエンドユーザー テストとも呼ばれ、対象ユーザーの一部によって現実世界の状況でアプリケーションがテストされる場合に行われます。ベータテストは、ユーザー受け入れテストの一例である。

IT システムとアプリケーションは、次の特性によりエラーのリスクが高くなります。

• クラウド・コンピューティング、IoT、ソフトウェア定義 ネットワーキング、拡張現実（AR）など、多くの新技術との統合が進んでいます。
  
  
• コアとエッジがシームレスに相互接続され、複数のリージョンに分散されることが増えています。スマート シティ、自動運転車、スマート ユーティリティのアプリケーションは、このようなアーキテクチャの恩恵を受けます

このような場合、開発は 1 つの場所または 1 つの企業で行われないため、継続的なテストはより要求が厳しくなります。リモート チームを含むサードパーティがシステムの一部の要素を提供する場合があります。システムはアプリケーション プログラミング インターフェイス (API) と統合される場合があります。各開発チームは、レガシー ソフトウェアを含む、異なる IT 環境で活動しています。各チームの物理環境を再現して継続的にテストすることは不可能です。

幸いなことに、継続的テストを 仮想化 することで、システム全体を単一のインターフェイスで仮想的に再現できるテスト環境を構築することができます。仮想化環境を簡単に再構成して、別の IT システムやエラーを修正するために変更された IT システムをテストできます。

DevOps環境では、継続的テストはソフトウェア開発ライフサイクル（SDLC）を通して自動的に実行され、アプリケーションに統合された新しいコードを自動的に検証する 継続的インテグレーションと 密接に連携します。

テスト ツールには、新しいコードがアプリケーションに統合されるたびに自動的に実行されるテスト スクリプトがプリロードされています。通常、テストは統合テストから始まり、システム テスト、回帰テスト、ユーザー受け入れテストに自動的に移行します。

テストでは各アプリケーション モジュールからデータ フィードが生成され、そのフィードが分析されて、新しいコードの影響を受けるすべてのモジュールが期待どおりに動作するかどうかが確認されます。テストが失敗した場合、コードは修正のために開発チームに戻されます。その後、再統合され、テスト サイクルが新たに開始されます。

すべてのテストに合格したら、アプリケーションやプロジェクトは SDLC の次のステージに移行します。

このトピックの背景については、Andrea Crawford による DevOps の説明を参照してください。

アプリケーションのモジュール、コネクタ（または APIや コンテナ）、プラットフォーム、インフラ、そして要件を定義するシナリオにまたがる一貫性を保証するために、一連のテストには継続的なテストフレームワークが必要です。

テストのセットは逐次的 (例: 回帰テストが単体テストに続く) または同時 (例: モジュールの新しい反復にその依存関係の対応するテストを伴うテストを伴う) の場合があります。

継続的テスト フレームワークは、一連のテストのラッパーを提供して、テストが一貫して適用され、自動化への道を準備します。開発者は、モジュールに対して採用するアプローチが、関連するモジュールに適用されるアプローチと異ならないことを確認したいと考えています。モジュールが進化すると、相互に関連するソフトウェアに対してさまざまなテストが行われます。

フレームワークは、テスト用にスクリプトと関数を簡単に変更するための標準的な方法を提供します。自動化は、テストの不一致が取り除かれれば恩恵を受けますが、そうでなければ一連の誤解を招くテスト結果を生成することになります。