左シフトテストでCI / CDを改善する方法

アプリケーションのテストは、アプリケーションのリリースの数日または数週間前にスケジュールされた、技術的に困難で時間のかかるアクティビティでした。開発チームには11時間までコーディングの余地が与えられ、多くの作業を手動で行ったテスターは、与えられた少しの時間でやるしかありませんでした。その結果、多くのアプリケーションが標準以下のテストを受け、テクノロジーチームは、エンドユーザーとアプリケーション監視システムによってエスカレートされた本番環境の問題と欠陥に対応することを余儀なくされました。

Devopsの継続的インテグレーションプラクティス、単体テストフレームワーク、およびテスト自動化プラクティスは、このパラダイムを覆しました。開発プロセスの最後に品質保証を実行する代わりに、多くのテストプラクティスが開始され、コーディング、統合、および展開中に完全に実行されるようになりました。 DevOpsとアジャイルチームはテストスクリプトを自動化し、CI / CDパイプラインはコード統合またはデリバリーフェーズ中にテストを実行するように呼びかけます。最終的な結果として、コードの変更によってビルドが中断されると開発者に警告が表示され、報告された問題に対処するための迅速な措置を講じることができます。

テストの自動化とテストスクリプトのCI / CDパイプラインへの統合は、左シフトテストと呼ばれます。これは、リリースタイムラインの早い段階で問題をキャッチするために、開発フェーズでより多くの品質保証プラクティスを実行できることを意味します。テストの自動化は、デプロイメントの頻度を増やしたいアジャイルチームとDevOpsチームにとってのデプロイメント前の優先事項の1つです。

新しい機能の導入時に、構築されたテストスクリプトが新しい機能を検証します。これらのテストは自動化され、ビルドまたはデプロイのステップに含めることができます。リリースプロセスの最後にQAエンジニアに回帰テストを実行させる代わりに、開発の一環としてこれらのテストの多くを実行および検証できます。これらのテストは、リリースプロセスの終わりから、初期の開発およびコーディングフェーズに左にシフトします。

左シフトテストにより、アジャイルチームの品質への取り組みが可能になります

左シフトテストは、効率を高めて品質を向上させるだけでなく、アジャイル開発プロセスに大きな文化的変化をもたらします。

一部の開発チームは、品質保証とテストを、コードを本番環境に配信する際の障壁として認識しています。アジャイル製品の所有者を満足させ、コードを完成させるためのすべてのハードワークの後、QAチームメイトは修正が必要なバグのリストを特定します。QAが多くのバグを発見した場合、それらを修正するためのリリースタイムラインに影響を与える可能性があります。さらに悪いことに、欠陥によってロジック、セキュリティ、またはパフォーマンスの問題が明らかになるため、コードの重要なセクションをリエンジニアリングする必要があります。このシナリオでは、開発者とQAエンジニアは同じアジャイルチームに所属していても、チームとして機能していません。

左シフトテストにより、アジャイルチームは品質責任を開発者とテスターの完全なチームに移すことができます。テストがCI / CDパイプラインの一部として実行される場合、開発者が関連するコードに取り組んでいる時点で品質の問題に対処するためのより良い機会を提供します。 CI / CDパイプラインは、ビルドの失敗を開発者に警告します。ほとんどの自己組織化開発チームは、これらの問題をすぐに修正する必要があります。

左シフトテストは、開発者とQAエンジニアにさらに多くのテストを自動化する機会も提供します。ベストプラクティスは、開発された機能に必要なテストのタイプに応じて、チームが自動化を実装する人を決定することです。たとえば、開発者はユニットテストとAPIテストの自動化を担当することがよくありますが、QA自動化エンジニアは、複数のサービスへのマルチステップAPI呼び出しをシミュレートするエンドツーエンドのユーザーエクスペリエンステストとトランザクションテストを開発することがよくあります。

シフトレフトテストを適用するタイミング

左シフトテストは、実行時間が短い、よりユニットレベルのアトミックテストに最適です。CI / CDパイプラインで自動化されたテスト、および開発者がビルドをトリガーするたびに実行されるテストは、ビルドプロセスを遅くすることなく、迅速に実行することが不可欠です。

エンドツーエンドのユーザーエクスペリエンステスト、トランザクションテスト、静的コード分析、セキュリティテストなど、より複雑で時間のかかるテストは、CI / CDパイプラインの外部で、毎日またはより頻繁なスケジュールで実行されることがよくあります。これらのテストは、品質の問題について開発者に早期のフィードバックを提供しますが、ビルドの速度低下やボトルネックを回避するためにCI / CDの外部で自動化されています。

GMFinancialのITサービス担当副社長であるThomasJ。Sweetは、左シフトテスト戦略の限界に関する彼の個人的な洞察を私と共有しました。彼は次のように示唆しています。「サードパーティベンダーの配信で統合テストを実行する場合を除いて、左シフトは常に戦略です。ソースコードにアクセスできないことがよくあるからです。従来のモノリシックアーキテクチャを備えた内部アプリがある場合でも、コードレビューとセキュリティスキャンを必要とする基本的なチェックインポリシーを適用することから始めることができます。スキャンに重大な警告や失敗が含まれている場合は、チェックインを拒否する必要があります。」

統合パートナーとのダウンストリームテストに対する1つの潜在的なソリューションは、サービスの仮想化を実装することです。この手法により、開発チームはさまざまな入力に対するダウンストリームシステムの応答をシミュレートできます。ダウンストリームシステムが明確に定義されている場合にうまく機能します。Micro Focus、Tricentisなどのツールがこの機能を有効にします。

経験豊富な品質保証マネージャーであるRobPocilukは、アジャイル開発における左シフトテストの強力な支持者です。「準備ができてコードの小さなセクションをテストできるようになると、スプリントの進行中にQAが柔軟になり、ループ状態になります。コード自体の目的を失う可能性があるため、チームはシフトレフトを使いすぎないように注意する必要があります。」

したがって、チームが左シフトテストを完全に採用している場合でも、リリースを対象としたコード完了ビルドでテストウィンドウをスケジュールするのには十分な理由があります。これにより、すべての自動テストが最終ビルドで実行されることが保証されますが、完全に機能するシステムを必要とする追加のテストをスケジュールすることもできます。

それらのテストの1つはUAT(ユーザー受け入れテスト)であり、選択されたエンドユーザーと対象分野の専門家が検証してフィードバックを提供します。一部のUATは開発中に実行できますが、このテストを頻繁に実行したり、機能の準備が整っていない場合は、簡単に実行できない場合があります。

左シフトテスト戦略の前提条件

左シフトテストは、成長を続けるDevOpsプラクティスですが、前提条件と先行投資があります。いくつかの重要な機能と実践が必要です。

  • 同時に実行されるビルドとテストの数をサポートするには、十分なテスト容量と環境が必要です。
  • アジャイルチームには、CI / CDパイプラインやジョブスケジューリングツールに簡単に統合でき、機能、コード品質、セキュリティ、パフォーマンスを検証できるテスト製品のツールキットが必要です。
  • アーキテクト、情報セキュリティスペシャリスト、QAリード、および組織の他の上級メンバーは、デフォルトの受け入れ基準を形成するテスト標準とサービスレベル目標を確立する必要があります。
  • アプリケーションでユーザー入力が必要な場合、テストチームは、十分なペルソナ、ユースケース、および入力パターンを検証するために十分なテストデータとパターンを必要とします。
  • スプリントコミットメント以前では、QAテスト自動化エンジニアを含むスクラムチームは、テストする機能、実装するテストの種類、更新する自動化プロセス、およびテストの開発者に関するテスト戦略を設定する必要があります。
  • Devopsチームは、CI / CDパイプラインの実行期間を測定し、自動化されたテスト手順が生産性に影響を与える場合にフラグを立てる必要があります。Devopsチームは、実行時間の長いテストを実行するために、CI / CDパイプラインの外部で追加のテストスケジュールを必要とすることがよくあります。
  • チームは、自動テスト、特に対象分野の専門家、UAT、またはパートナーとのテストを必要とする検証のギャップについて定期的に話し合う必要があります。アジャイルチームが自動化でこれらのギャップに対処できない場合は、リリースサイクルでオーバーヘッドを考慮してリスクを軽減し、これらのテストを完了する必要があります。

最後に、アジャイルチームとDevOps組織は、テストカバレッジを定期的に測定し、話し合う必要があります。開発チームと品質自動化エンジニアが問題をキャッチしてリスクに対処するのに十分なテストを実際に実装、自動化、統合しない場合、左シフトテスト戦略の採用は機能しません。

リリースサイクルを高速化したり、十分なテスト自動化なしで継続的デリバリーを有効にしたりすると、重大な品質問題が発生し、エンドユーザーのエクスペリエンスが低下する可能性があります。アジャイル開発チームはリリースを頻繁にプッシュしすぎると、より多くのより良い自動化に投資する代わりに、本番環境の問題や欠陥に対処していることに気付きます。