シフト左テストとは何ですか? DevOps にとっての意味は何ですか?

左テストの方法論は、ソフトウェア開発サイクルにテスト要件を早く取り入れるソフトウェアテストへのアプローチです。

 

ソフトウェア開発は、過去数十年にわたってかなりの進化を見てきました。 今日、パフォーマンスエンジニアとテスターは、自動化、機械学習、AIツールをいくつでもテストに統合できます。 ソフトウェアテストが副次的な注意を払っていたのは、それほど昔のことではありませんでした。 実際、初期のソフトウェア開発には正式なテスト段階さえありませんでした。 テストの導入は、ソフトウェアがより複雑になって、本番環境からのバグや欠陥がビジネスに影響を与え始めるまで起きませんでした。 開発者は、別のチームではなく、自分でテストを実施しました。 このように機能テストが生まれ、工場の組み立てラインと同様に、線形パスを移動する別々の段階(分析、要件、設計、コーディング、テスト、受入れ、生産、ポストプロダクション)からなる従来のウォーターフォールモデルの一部となりました。

滝モデル

ポール・ホードリーによる滝モデル。 クリエイティブ・コモンズ・ライセンスの下で使用されます。

 

各ステージが完了すると、次のグループに渡され、ラインを下に移動しました。 紙面では見栄えが良かったが、QAはこれらの段階の大半が完了するまでコードをテストしなかった。 そのため、本番稼働前にコードを変更する時間が非常に少なのにかありました。 問題やバグが十分に深刻であった場合、プロジェクトの廃棄または遅延を意味します。 さらに、これは、ソフトウェアアプリケーションの重要性に応じて、企業にとって潜在的な巨額の損失を意味しました。

 

シフト左テスト – 基礎を築く

幸いなことに、以前の開発ミスから学んだ高価な教訓は、シフト左の方法で私たちを助けました。 組織は、ゲームの終盤に問題を特定することは、コストが高すぎるだけでなく、リスクも高いということに気付きました。2019年5月 のTechRepublicの記事 は、ソフトウェアの視覚的なバグを修正するための年間平均コストが$ 400,000を超えることを報告しました。 正確にチャンプチェンジではありません。

また、業界全体が変化していました。 企業が争わなければならないデジタルトランスフォーメーションがありました。 組織は、年に1~2回のリリースサイクルに頼ることはもはやできないことに気づき始めています。 お客様の期待と要求は高いものでした。 設計が不十分な製品をリリースすることは、顧客を競争に負けることを意味しました。 何かが変わらなければならなかった。

組織は、開発サイクルを小さく管理しやすいブロックに分割し、各フェーズにテストを組み込むようになりました。 これにより、より協力的な環境が可能なため、チームは問題をより早く特定できるようになりました。 たとえば、プロセスの早い段階でソフトウェア要件をより深く理解することで、テスト チームは、潜在的なバグを修正するためのより良いテスト ケースの開発を支援できます。 これは「早期に頻繁に失敗する」または「速く失敗する」とも呼ばれます。プロセスの前の段階でユーザー シナリオとソフトウェアの動作を考慮すると、潜在的なバグが排除され、コードが最適化されます。 これにより、チームは一貫した製品を提供できます。

明らかに、テストが意味をなさない時が来ます。 たとえば、GUI を使用するまで GUI テストを実行することはできません。 しかし、左シフトは単なる開発プロセスではなく、考え方の方が多いです。 最も重要なことは、チームは常に、より良いユーザー エクスペリエンスを実現するものを考える必要があります。 最終的には、最終製品を手に入れるのはユーザーです。 アプリケーションを改善して、本番環境に投入する前に何でもメリットを得ることができます。

 

シフト左テストとアジャイルとDevOpsの台頭

技術の進歩の増加とデジタル体験への焦点により、パラダイムシフトが起こりました。 開発とテストのサイクルは短く、より頻繁になりました。 その結果、新しい機能が市場に早くもたらされました。 最も重要なことは、これは企業が競争力を維持することを可能にしただけでなく、顧客を幸せにし、従事し続けた。 たとえば、モバイルアプリケーションと ウェブ アプリケーションは、通常、2 週間のリリースサイクル内で動作します。 一部の組織は毎日更新プログラムをリリースする – あるいは毎時!

アプリケーションおよびソフトウェア開発の焦点は、迅速でアジャイルであり、リスクを軽減することです。 組織は、アジャイル ソフトウェア開発と DevOps プラクティスを通じて、この課題に対応しています。 アジャイルソフトウェア開発は、ウォーターフォールモデルに似ています。ただし、主な違いは、ウォーターフォール モデルでは、設計フェーズの後に常にテスト フェーズがあることです。 Agile メソッドは、開発をスプリントと呼ばれる小さなイテレーションに分割し、4 週間は終了しません。 各スプリントには、スプリントのあらゆる側面に取り組む部門を超えたチーム メンバーが含まれます。 これにより、チーム メンバー間の共同作業が増え、フィードバック サイクルが短くなり、高品質な製品が実現します。

そして、それはシフト左テストに関するもう一つの重要な要因です。 従来のウォーターフォール テストでは、製品の品質のテストと管理に責任を負う責任は QA チームに委ねられます。 シフト左テストとアジャイル環境では、開発者とテスト担当者が実際のテストを実行しますが、開発中のコラボレーション型のクロス機能アプローチにより、最終的には全員に責任が委ねられます。 現在、左方のテストをシフトする方法として、従来型、増分テスト、アジャイル/DevOps、モデルベースのシフト左テストの 4 つのアプローチがあります。

 

シフト左テストの種類

ほとんどの人が考える従来のシフト左テストは、古典的なVモデルのテストを少し低く、わずかに残します。

従来のシフト左テスト

ドン・ファイアスミスによる伝統的なシフト左テスト。 クリエイティブ・コモンズ・ライセンスの下で使用されます。

インクリメンタルシフト左テスト

ドン・ファイアスミスによるインクリメンタルシフト左テスト。 クリエイティブ・コモンズ・ライセンスの下で使用されます。

増分シフト左テストは、ハードウェアの依存関係を持つ大規模で複雑なプロジェクトに最適です。 段階的にテストすることで、次のステップに進む前に、システムの各セグメントが機能することを確認します。

アジャイル/DevOpsは、テストを短期間で完了させ、通常は開発テストではなく開発テストで実施します。 これは、システムが動作に移されると発生します。

アジャイルDevOpsシフト左テスト

アジャイル/DevOpsは、ドン・ファイアスミスによる左テストをシフトします。 クリエイティブ・コモンズ・ライセンスの下で使用されます。

モデルベースのシフト左テスト

ドン・ファイアスミスによるモデルベースのシフト左テスト。 クリエイティブ・コモンズ・ライセンスの下で使用されます。

モデルベースのシフト左テストは、欠陥の大部分が導入される要件段階での欠陥を解決するために設定されます。 上記のシフト左のメソッドは、開発サイクルでテストを開始します。 これにより、テストをできるだけ早く完了できます。

近年、DevOpsという用語は、マーケティング、ソフトウェア製品、さらには仕事の説明の流行語となっています。 簡単に言えば、DevOps は、開発チームと運用チームを結び付けることを目的とした、アジャイルアプローチの代替フレームワークです。 歴史的に、各部門は、時には矛盾した、それぞれの目標を持っていました。 開発者は、作成、設計、および革新を行います。 運用チームは、インフラストラクチャに重点を置き、可用性を確保するために継続的な監視を行う「ライトを点灯」します。 同様に、DevOps は、これらの部門間でより多くのコラボレーション、フィードバック、および俊敏性をもたらすために特別に作成されました。 また、CI/CD (継続的インテグレーションと継続的な展開) と自動化について話すときに DevOps が言及されていますが、組織が CI/CD と自動化を使用しているという事実は、自動的に DevOps 認定を受けられません。

 

DevOps 環境のロード テストのベスト プラクティス

チームが古い負荷テストと監視のアプローチに従っている場合、DevOps はすぐにパフォーマンスの障害に追い込むことができます。 QA チームは、頻繁に新しいリリースの展開に対処する必要があります。 DevOps チームには、柔軟な監視に加えて、テストを管理する簡単な方法が必要です。

連続負荷テスト。

UI に影響を与える可能性のある変更が多すぎることや、ロード テストをクラッシュさせる可能性があります。 最初の焦点は、完全に自動化された APIテスト を実行し、毎日実行するようにスケジュールすることです。 主要なビジネス プロセスが安定したら、テスト シナリオにエンドツーエンドのテストを追加できます。

貴重な洞察を共有する。

DevOps チームを結果分析アクティビティに参加させます。 情報を隠す練習をしないでください。 すべての負荷テストと監視結果をエンジニアと共有して、すべての問題の原因を突き止めます。

すべてのレイヤーの監視。

左シフトは、開発段階とQAステージで生産ライクなモニタリングを行うことを意味します。 アジャイル開発パイプラインのエラーを継続的に再現する時間はありません。 非本番段階のフロントエンド、バックエンド、およびインフラストラクチャの使用率の指標を 24 時間 365 日収集してください。

ベースラインとベンチマーク。

連続的な負荷テストは大量のデータを作り出す。 ベースラインを設定し、ベンチマークを使用して、サイクルの早い段階で偏差を検出します。 早く減速について知れば知るほど、開発チームはそのような問題を解決する時間が増えます。

 

シフトレフト方法論へのパフォーマンステストの統合

今日のアプリケーションは、サードパーティのプロバイダとCDNの膨大なネットワークに依存して、複数の技術を利用しています。 ユーザーは、世界中のどこからでも、さまざまな接続速度で、任意の数のデバイスからアプリケーションにアクセスできることに加えて。 ユーザーに常に素晴らしいエクスペリエンスを提供しようとするとき、それは説明する多くのことです。 応答時間、品質、可用性は、アプリケーションを運用環境に移行する前に注意が必要な重要な要素です。

実稼働後、アプリケーションまたはサイトは数百人、あるいは数千人の同時ユーザーに立ち向かう必要があります。 コードに対する小規模な増分変更はパフォーマンスに影響を与える可能性があるため、パフォーマンス関連のバグを早く見つけると、修正が容易になり、コストも低くなります。 ほとんどの場合、チームは 1 日または 2 日以内にパフォーマンスの問題を修正できる必要があります。 繰り返しますが、これらの改善を実行する方が、配置前の発見に比べてはるかに簡単です。

理想的には、コードが必要な機能テストを通過し、機能が検証され、サインオフされた場合、チームは機能テストアーティファクトが仮想ユーザーにどれだけうまく耐えられるかを確認するために、ストレステストや負荷テストなどの非機能テストを実行する必要があります。 LoadViewはシフト左テストアプローチの不可欠な部分を果たしており、ユーザーは時間、お金、最適化されたコードとアプリケーションを提供することができます。

 

LoadView プラットフォーム: 実際のブラウザーでのクラウドベースのロード テスト

LoadView プラットフォームは、プロトコル ベースのテストから実際のブラウザー ベースのテストまで、あらゆるものをシミュレートする、効果のない負荷パターンの問題に対処できる柔軟な負荷テスト プラットフォームです。 これは完全にクラウドベースであるため、内部ロード インジェクタのセットアップと展開、サードパーティのクラウド アカウントの管理、ハードウェアやソフトウェアの要件の心配は必要ありません。 パフォーマンス テストでは通常、一部の組織ではサポートできない追加のインフラストラクチャとリソースが必要です。 LoadView はプラットフォームを通じてこれを管理します。

ロードビューシフト左インフォグラフ

LoadViewは、単一の負荷インジェクタからバックエンドの高レベルの負荷を容易にスピンアップしてシミュレートできるため、コードやウェブ サービスを早期にテストするのに最適です。 これにより、JSON、SOAP、REST などの ウェブ API アーキテクチャのテストに最適です。 また、非機能テストでは、通常、セットアップ時間が長くなり、開発者やエンジニアが特定のプログラミング言語に関する知識を持つ必要がある複雑なスクリプトが必要になります。 ベンダー固有のエコシステムでのみ機能する傾向があるため、自動化が困難な場合があります。 これは、ビューの場合は当てはまりではありません。

 

スクリプト作成が簡単になりました: EveryStep Web レコーダー

LoadView は、EveryStep Web レコーダーと呼ばれる使いやすいスクリプト レコーダーを利用します。 ユーザーは、API、ウェブ アプリケーション、および ウェブ サイトを使用して実際のユーザーアクションをシミュレートする高度なスクリプトアクションを簡単に作成できます。 クライアント側アプリケーションのエンドツーエンド応答時間を検証するために、ユーザーはテスト ケースを移動してすべてのアクションを記録するだけで済みます。 初期の開発段階で API または ウェブ アプリが処理できる負荷の程度を理解することは、開発者が次の重要な分野で処理するうえで役立ちます。

  • 特定のユーザー負荷番号のもとでの応答時間ベースラインの決定
  • パフォーマンスのボトルネックの特定
  • 容量計画のための現在のシステムの上限を見つける
  • サーバーのパフォーマンス (CPU、メモリ、帯域幅、ディスク I/O) とデータベース応答時間の分析

レコーダーはまた、40以上の人気のあるデスクトップ/モバイルブラウザやデバイスだけでなく、AJAX、HTML5、JavaScript、Flash、Silverlight、および多くなどのウェブ 技術やプログラミング言語をサポートしています。 LoadView は、これらのスクリプトを使用して、13 以上のグローバルな場所 (米国、カナダ、南米、ヨーロッパ、および APAC) からオンデマンドのストレスおよび負荷テストを実行し、テスト エンジニアに実際のブラウザーからの実際のパフォーマンス データを提供します。 内部テストを実行すると、アプリケーションまたはサイトがネットワーク内からのトラフィックの増加をどの程度うまく処理しているかを把握できますが、実際の状況は反映されません。 適切にテストおよび最適化されていないアプリケーションやサイトは、コンバージョンに悪影響を及ぼし、最終的には収益に悪影響を及ぼす可能性があります。

 

LoadView: 実環境のシナリオをテストする柔軟性

LoadView では、ユーザーは、サイトへのトラフィックの割合に基づいて、地理的な場所間でユーザーの負荷を分散するオプションを提供します。 たとえば、特定の割合の顧客とユーザーが特定の地理的位置から来る場合は、テストする特定の領域を選択できます。 このプラットフォームでは、アマゾン ウェブ サービス (AWS) と Azure クラウド サービスを利用して仮想ユーザーを生成します。 さらに、ロードカーブのタイプをカスタマイズすることで、ロードテストをさらに一歩進めることができます。 これにより、テスト エンジニアのシナリオに応じて、さらに高い柔軟性が得られます。 LoadView ユーザーは、次の 3 種類の荷重曲線から選択できます。

荷重ステップ曲線

    • 事前に決定された同時ユーザー数から始まり、徐々に負荷が増加し、ウェブサイトがトラフィックの急増を処理し、予想されるトラフィックと比較する方法を確認します。

目標に基づく曲線

    • このタイプの荷重曲線は、一定の時間間隔でスループット目標またはサイト訪問者数を既に決定している場合に役立ちます。 SLA または非機能要件の検証に最適です。

ダイナミック調整可能曲線

    • このテストにより、テストの実行中に負荷を調整し、ウェブ サイトまたはサーバー容量のパフォーマンスの制限を明らかにすることができます。

テストが完了すると、チームが同時ユーザー数、エラー、平均応答時間、CPU 使用率、スループット、待機時間など、KPI (主要業績評価指標) の成功度を測定する際にチームを支援するレポートが LoadView によって自動的に生成されます。 これらの指標は、エンド ユーザーのパフォーマンスに影響を及ぼす可能性のある現実世界のボトルネックを発見するうえで、開発者、DevOps、および QA チームにとって重要です。

 

左にシフトした後、右にシフトすることを忘れないでください

シフト左テストに重点を置いて、あまり注目を集めずにプロセスにもう一つの非常に重要なステップがあることを覚えておくのは難しいです。 アプリケーションが実稼働状態に移行した後は、ユーザーがスムーズに実行し続ける必要があります。 ドットコムモニターは、ページやアプリケーションが正常に動作し続けることを保証するために 、複数の監視ソリューション を提供しています。

ウェブ サービスの監視

    • HTTP/S、SOAP/REST などの ウェブ サービスの稼働時間とパフォーマンス

ウェブページの監視

    • 実際のブラウザでの ウェブ ページのパフォーマンス、時間の経過に対する最も低速で最も高速な要素の識別

ウェブ アプリケーションの監視

    • AJAX、PHP、Ruby、フラッシュなどの複雑なウェブアプリケーションを監視

インフラストラクチャの監視

    • HTTP/S、電子メール、ストリーミング メディア、VoIP などのインターネット サーバーおよびプロトコルの機能とパフォーマンス

これらのプラットフォームでは、ユーザーはカスタムしきい値に基づいて継続的な監視を設定でき、エラーが発生したときに特定の個人やチームに警告できるため、より多くのユーザーに影響を与える可能性がある前に問題の修正に取り組むことができます。

 

シフト左テスト:ビジネスと安心のための良い

結論として、左シフトと右シフトの両方の概念は、ソフトウェア開発サイクル内だけでなく、他の部門や業界においても非常に価値があります。 たとえば、プロダクト マネージャーやカスタマー エクスペリエンス マネージャーは「左にシフト」し、継続的なフィードバックを得るために実際の顧客とのエンゲージメントが高まっています。 これにより、組織はより機敏になり、情報やフィードバックのソースに近づき、顧客の理解を深めることができます。 考えてみてください。 誰かと一緒に仕事をしたり、自分のインプットを重視する会社と取引を続けたりする可能性が高いと思いませんか? だから、今、誰かが「左にシフト」または「早く頻繁にテストする」と言うのを聞くと、それは彼らが投げ回している単なる派手な流行語ではありません。 これは、カスタマーエクスペリエンスパズルの重要な部分であり、常にあなたの心の奥に保つべきものです。 ユーザーと顧客が満足できるだけでなく、効率を上げ、より良い結果を得て、組織との安心感を得ることができます。