継続的テストとは

継続的テストとは

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

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

実用的なDevOpsアプローチを開発する際の基本原則の1つは、迅速なソフトウェア配信と信頼性の高いユーザー・エクスペリエンスの間のギャップを埋めることです。

しかし、プロジェクトの設計、コーディング、テスト、展開、保守などのソフトウェア開発の各段階で手動でフィードバックを得る従来の方法では、組織のリソースが不十分かつ非効率的に使用され、最終的には統合サイクルが長くなり、製品の更新が遅れることになります。

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

継続テストは、自動化ツールを使用して、生産のすべての段階で事前定義された品質保証(QA)スクリプトを読み込むことによって機能します。これらの自動化されたスクリプトにより、QAテストを実行するときに定期的な人的介入の必要性がなくなり、ソースコードの効率性が順次検証されるとともに、関連するフィードバックが適切なチームに即座に提供されるようになります。

自動テストが失敗した場合、開発チームはその開発段階で通知を受け取り、SDLCのさまざまな段階にある他のチームに影響を与える前に、ソースコードに必要な調整を加えることができます。

自動テストが検査に合格すると、プロジェクトは自動的に SDLCの次の段階に渡され、組織は生産性を最大化し、部門間の調整を改善する持続可能な配信モデルを作成できるようになります。

高速道路の空撮

クラウドで夢を広げる


Thinkニュースレターでは毎週、AI時代のマルチクラウド設定の最適化に関する専門家のガイダンスをご覧いただけます。

継続的テストの利点

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

効率の向上と高品質な導入:継続的なテストは、SDLCの各段階で品質保証とワークフロー間の品質相互運用を管理する自動化された方法を提供します。

継続的なフィードバック・ループをユーザー・モジュールと単体テスト・モジュールに統合することで、開発者は、コードをデプロイする前に、コードの互換性とパフォーマンスを向上させるために必要な実用的な洞察を得ることができます。この効率性により、複数のDevOpsチーム・メンバー間の切断が解決され、ソフトウェア配信スケジュールの加速がサポートされます。

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

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

開発関連の業務中断によるコストの削減: 特に大規模な相互接続システムでは、アプリケーションの1つのモジュールでエラーが発生するだけで連鎖的な影響が生じ、不要なダウンタイムが発生し、生産性と収益に悪影響を与える可能性があります。

例えば、クラウド・プロバイダーは、一方の端で障害が発生し、地域全体が麻痺し、数時間にわたる停止が発生することを定期的に報告しています。これは、高いサービス可用性に依存している組織にとって壊滅的な打撃となる可能性があります。詳細なレベルでの継続的なテストにより、大規模なソフトウェア・システムでは検出されない可能性のあるエラーが特定され、業務中断のコストを回避するのに役立ちます。

継続的テスト方法

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

シフト・レフト・テストこのアプローチでは、SDLC の早い段階でソフトウェアとシステムのテストを優先し、将来的に重大なデバッグの問題を軽減または防止します。

シフト・ライト・テスト:
このアプローチでは、ユーザー・エクスペリエンス、全体的なパフォーマンス、障害許容度、および機能の向上に重点を置いて、SDLC の終わり近くのテストを優先します。

スモーク・テスト
:これらのテストは、手動または自動で実行でき、ソフトウェアの顕著な欠陥を最初にざっとスクリーニングします。スモーク・テストは構造が複雑ではありませんが、ソフトウェアの重大なエラーを排除するための迅速かつ安価なソリューションを提供します。

ユニット・テスト:
ビルド全体にわたる小規模なストレス、負荷、ボリューム、またはメモリー・リークのチェックに最適で、開発の初期段階で劣化を特定できます。

統合とメッセージング
テスト:ソフトウェア・モジュールが相互に動作しているときにエラーをチェックします。継続テストでは、不足している依存関係を仮想化するため、チームはエンドツーエンドのプロセスとシナリオが総合的にどの程度うまく実行されるかをテストできます。次に、複合コードをコンパイルして実行時に起動し、期待どおりに動作するかどうかをテストします。

パフォーマンス・テスト
:アプリケーション・ソフトウェアのパフォーマンスを単独でテストすると、最終的な運用環境のハードウェアとミドルウェアが考慮されない場合があります。ソリューションの全体的なパフォーマンスを効果的に評価するには、統合システム・テストが必要です。

機能テスト:
この形式のテストでは、ユーザー・エクスペリエンスが期待どおりかどうか、およびソフトウェア・システム全体で機能ワークフローが必要に応じて開始されるかどうかを確認します。例えば、サプライチェーン・ソフトウェアは、在庫が出荷可能になったときにトラックが工場に到着するように通知できる必要があります。

対照的に、非機能テストは、パフォーマンス、使いやすさ、信頼性、応答時間、読み込み時間、拡張性に重点を置いています。これは、ソフトウェアが望ましい顧客体験を提供できる準備ができているかどうかを評価します。

回帰テスト:
このテストでは、依存ソフトウェアのエラーが修正された後にパフォーマンス、機能、依存関係に変化があるかどうか、システムが以前と同じように動作するかどうかを確認します。

ユーザー受け入れテスト: アプリケーション・テストまたはエンドユーザー・テストとも呼ばれ、これは、アプリケーションが実際の状況で対象ユーザーのサブセットによってテストされるものです。ベータ・テストは、ユーザー受け入れテストの例です。

仮想化と継続的なテスト

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

これらは、クラウド・コンピューティング、モノのインターネット(IoT)、ソフトウェア定義のネットワーキング、拡張現実(AR)などの多数の新興テクノロジーとますます統合されています。

シームレスに相互接続されたコアとエッジを備え、複数のリージョンに分散されるケースが増えています。スマート・シティ、自動運転車、スマート・ユーティリティー向けのアプリケーションは、このようなアーキテクチャーの恩恵を受けます。

このような場合、開発は単一の場所または企業内で行われないため、継続的なテストの要求はより厳しくなります。リモート・チームを含むサード・パーティーが、システムの一部の要素を提供する場合があります。

システムは、アプリケーション・プログラミング・インターフェース(API)と統合される場合があります。各開発チームは、レガシー・ソフトウェアを含むさまざまなIT環境で作業します。各チームの物理環境を再現して継続的にテストすることは不可能です。

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

DevOpsにおける継続的テストの役割

DevOps環境では、SDLC全体で自動的に継続的なテストが実行され、継続的統合と連携して、新しいコードがアプリケーションに統合されるたびに自動的に検証します。

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

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

すべてのテストに合格した後、アプリケーションやプロジェクトは、通常、継続的デリバリーへと進みます。

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

アプリケーション内のモジュール、そのコネクターまたはAPIコンテナ、プラットフォーム、そのインフラストラクチャー、およびその要件を定義するシナリオ間での一貫性を確保するために、テスト・セットには継続的なテスト・フレームワークが必要です。

テスト・セットは、ユニット・テストに続く回帰テストのように順次実行することも、依存関係に対応するテストを伴うモジュールの新しい反復のように同時に実行することもできます。

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

フレームワークは、テスト用にスクリプトや関数を簡単に変更するための標準的な方法を提供します。テストの不一致が解消されると自動化の効果が得られ、そうでない場合は一連の誤解を招くテスト結果が生成されます。

関連ソリューション
IBM DevOps アクセラレート

CI/CDとリリース管理を自動化する包括的なソリューション、IBM DevOps Accelerateを使用して、ソフトウェア配信パイプラインを合理化します。

IBM DevOps Accelerateの詳細はこちら
IBM DevOps Automation

プロセスを自動化しながら、ワークフローを最適化し、開発とデプロイメントのあらゆる段階でチームのコラボレーションを改善することで、より迅速かつ信頼性の高いソフトウェア配信を実現します。

IBM DevOps Automationの詳細はこちら
DevOps for IBM Z

安定性、安全性、俊敏性を保ちつつ、ハイブリッドクラウド環境の基幹業務アプリケーションを変革します。

IBM Zについて
次のステップ

継続的な統合とデリバリーにより、DevOpsの可能性を解き放ち、安全なクラウドネイティブ・アプリケーションを構築、テスト、デプロイします。

DevOps ソリューションの詳細はこちら DevOpsの実際の動作を確認する