継続的テストとは何ですか?
継続的テストは、ソフトウェア開発の加速、コード品質の向上、コストのかかるボトルネックの回避において重要な役割を果たします。
IBMニュースレターの購読
黒と青の背景
継続的テストとは何ですか?

継続的テストは、ソフトウェア開発ライフサイクル (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における継続的テストの役割

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

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

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

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

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

継続的なテストフレームワーク

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

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

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

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

関連ソリューション
DevOps ソリューション

強力な DevOps ソフトウェアを活用して、複数のデバイス、環境、クラウドにわたってセキュリティが強化されたクラウドネイティブ アプリを構築、展開、管理します。

DevOps ソリューションの詳細はこちら
IBM Rational Test Workbench

API テスト、機能 UI テスト、パフォーマンス テストなどを自動化します。修正コストが低いときにエラーを特定します。

Rational Test Workbenchを調べる
DevOps インサイト

一般的な継続的インテグレーションおよび継続的デリバリー ツールから得られる包括的な洞察により、アプリケーションの速度、品質、制御を向上させます。

DevOps の洞察を探索する
参考情報 Dummies 継続的テスト、IBM Limited Edition

IBM ソフトウェアとベスト・プラクティスが、ソフトウェア開発、テスト、運用チームが継続的なテストのアプローチを採用するのにどのように役立つかを学びます。

DevOpsとは何ですか?

DevOps は、ソフトウェア開発チームと IT 運用チームの作業を組み合わせて自動化することで、高品質のソフトウェアの提供を迅速化します。

継続的インテグレーションとは

継続的インテグレーションは、開発者が開発サイクル全体を通じて新しいコードを頻繁に統合し、少なくとも 1 日に 1 回コード ベースに追加するプロセスです。

次のステップ

DevOps の準備はできていますか? 市場が要求する速度でソフトウェアとサービスを提供するには、チームがフィードバックとデータに基づいて迅速に繰り返して実験し、新しいバージョンを頻繁にデプロイする必要があります。最も成功しているクラウド開発チームは、最新の DevOps 文化と実践を採用し、クラウドネイティブ アーキテクチャを採用し、クラス最高のツールからツールチェーンを組み立てて生産性を最大限に引き出しています。

DevOps ソリューションを見つける