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

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

 

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

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

 

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

 

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

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

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

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

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

 

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

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

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

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

 

シフト左テストの種類

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

 

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

チームが時代遅れの ロード テストと監視のアプローチに従っている場合、DevOps はすぐにパフォーマンスの災害に陥る可能性があります。 QA チームは、頻繁に新しいリリースの展開に対処する必要があります。 DevOps チームには、柔軟な監視に加えて、テストを管理する簡単な方法が必要です。

連続負荷テスト。

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

貴重な洞察を共有する。

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

荷重ステップ曲線

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

目標に基づく曲線

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

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

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

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

 

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

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

Web サービスの監視

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

ウェブページの監視

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

Web アプリケーションの監視

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

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

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

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

 

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

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