パフォーマンス・エンジニアリングは、プロアクティブで継続的な、エンドツーエンドのアプリケーション・パフォーマンス・テストとモニタリングです。継続的なフィードバックループを通じて、チーム、ツール、プロセス間のシームレスなコラボレーションを可能にする。ここでは、品質保証を担当するのはテスターだけでなく、開発者、パフォーマンス・エンジニア、プロダクト・オーナー、ビジネス・アナリストも同様だ。

開発者からパフォーマンス・エンジニアまで、適切なサイズのツールを活用することで、パフォーマンス・エンジニアリングは、シフト・レフトのパフォーマンス・テストとシフト・ライトのアプリケーション・パフォーマンス・モニタリングを可能にします。伝統的なパフォーマンス・テストとは何かを理解せずに、パフォーマンス・エンジニアリングが伝統的なパフォーマンス・テストからどれだけかけ離れているかを理解するのは難しい。

Performance Engineering

パフォーマンス・テストとパフォーマンス・エンジニアリングの違いは何ですか？

古典的なパフォーマンス・テストは、事実上パフォーマンス・エンジニアリングのサブセットである。通常、開発後の品質保証（QA）サイクルの一環として、負荷テストを1回実施することになる。パフォーマンステストは、想定される作業負荷の下で、アプリケーションの速度、信頼性、スケーラビリティ、安定性、応答時間、およびリソースの使用をチェックすることを含む。パフォーマンス・エンジニアリングとパフォーマンス・テストの違いに入る前に、まずパフォーマンス・テスト単体について、そしてなぜそれ単体ではもはや持続不可能なのかを見てみよう。

第一に、テストは単独で捉えられ、機能テストの最後に初めて始まる後付けのものとして扱われる。
第二に、サイロでの作業は、プロジェクト・サブチーム間のコミュニケーション・ギャップを大きくし、高品質の製品を提供するために必要なコラボレーションを妨げる。
第三に、パフォーマンステストが開始される頃には、組織はすでにアプリケーションの設計、開発、プロモーションにかなりの時間、労力、資金を投入している。
第四に、パフォーマンステストは後回しにされがちで、リリース前の「完了」基準に含まれていない。つまり、この時期、ビジネスではアプリの本番稼動が急務であり、遅れは許されない。この文脈では、QAからのフィードバックがリリース前に完全に修正するには遅すぎる。必然的に、リリースがスケジュール内に収まるように、不必要に多くのパフォーマンス上の問題が本番環境にもたらされることになる。生産段階で不具合を修正することは、開発の初期段階で行うよりもはるかにコストがかかり、混乱を招く。
第5に、従来のパフォーマンス・テストはウォーターフォール・モデルには最適だったかもしれないが、今日のDevOps中心の世界にはそぐわない。DevOpsは、変更がシステムにコミットされてから本番稼動するまでの時間を短縮することで、新規リリースの失敗率を低減する。継続的インテグレーションと継続的デリバリー（CI/CD）は、ソフトウェアがライフサイクルを通じて常にリリース可能な状態にあることを確認する。DevOpsはまた、利害関係者、機能、ツール間のエンドツーエンドのコラボレーションをサポートするために、組織を再編成することにも重点を置いている。DevOpsの迅速なデリバリー要求に応えるため、ソフトウェア開発には、より進化したパフォーマンス・テスト・アプローチが必要だ。その新しいアプローチとは、ソフトウェア・パフォーマンス・エンジニアリングである。

では、パフォーマンス・エンジニアリングとパフォーマンス・テストの主な違いを掘り下げてみよう。

第一に、パフォーマンステストは、アプリケーションの負荷処理と応答性の品質チェックです。システムが生産負荷にどの程度耐えられるかを確立し、高負荷時に起こりうる問題を予測する。パフォーマンス・エンジニアリングは、最初からパフォーマンス指標を念頭に置いてアプリケーションを設計し、開発の初期段階で問題の発見を容易にすることを目指す。
第二に、パフォーマンス・テストはQAプロセスであり、通常、ソフトウェア開発が完了した時点で実施される。パフォーマンス・エンジニアリングは、設計から開発、そしてエンドユーザー・エクスペリエンスに至るまで、ソフトウェア開発サイクルのすべての段階に組み込まれる継続的なプロセスである。
第三に、パフォーマンス・エンジニアリングにはRNDとQAが関与するのに対し、パフォーマンス・テストはQAチームが実施する。

パフォーマンス・エンジニアリングのコンセプト

以下のコンセプトを通じて、DevOpsとパフォーマンス・エンジニアリングは一貫したプロダクション・パフォーマンスの結果をもたらし、顧客はより自信を持ってアプリケーションを効率的にデプロイし、ユーザーの期待に応える高性能で安定したソフトウェアを展開することができます。

エンド・ツー・エンドの最適化

パフォーマンス・エンジニアリングは、継続的なテストとモニタリングのプロセスを通じて、エンドツーエンドのシステム最適化を実現します。これにより、パフォーマンステストと負荷テストは開発プロセスにシフトされた。機能テストが安定し、コードがリリースされた後にテストが行われる従来のパフォーマンステストとは異なる。

コードがリリースされると、パフォーマンス・エンジニアリングは、アプリケーション・パフォーマンス・モニタリング（APM）ツールを利用することで、運用中のアプリを追跡する。

パフォーマンス関係者の部門横断チーム

パフォーマンス・エンジニアリングは、ビジネス・アナリストから開発者まで、プロジェクトの利害関係者間のコラボレーションを可能にする。カスタマー・エクスペリエンスを向上させる高いパフォーマンス・レベルを維持し、ビジネスのペースに対応し、エンドツーエンドのパフォーマンスを管理することは、QA/パフォーマンス・エンジニアだけでなく、すべての人を製品パフォーマンスの管理者にします。その方法はこうだ。

テスト・センター・オブ・エクセレンス

テスティングセンターオブエクセレンス（CoE）は、信頼できるテスティングアドバイザーとして、またベストプラクティスの管理者として機能する。CoEは、さまざまな事業部門、さまざまなテスト手法（DevOpsやアジャイルなど）をサポートし、必要に応じてパフォーマンス・テストやテスト・ツールを柔軟に推奨します。より優れたテストモデルを構築し、テスト品質を向上させるために、CoEは、長期にわたって複数の事業部門にわたって生成・収集されたテストデータを統合し、再利用するための単一のポイントとして機能する。

パフォーマンス・エンジニア

パフォーマンス・エンジニアは、パフォーマンス・テストの基準が包括的であり、全体像を網羅し、開発中のコードのすべての異なる部分を考慮するように、開発中のすべてのコードを全体的に見渡します。パフォーマンス・エンジニアは、パフォーマンス・テスト・ツールの主要ユーザーであり、スクリプト作成、設計、実行、テスト結果の分析において高度な専門知識を有する。パフォーマンス・エンジニアリングでは、パフォーマンス・エンジニアが開発の初期段階に参加し、コードがリリース準備完了とみなされるために必要なパフォーマンス測定基準やシナリオを提供します。早期の関与は、パフォーマンス・エンジニアが、ソリューションが開発当初に設定された期待パフォーマンスを満たすことを保証できることを意味する。また、アーキテクチャとデザインが開発全体を通して一貫していることも確認される。

ソフトウェア開発者

開発者はコーディングの専門家だが、機能テストとパフォーマンス・テストの両方には疎いことが多い。彼らは統合開発環境（IDE）で作業し、好みのツールを使う傾向があり、新しいツールを学ぶ気はあまりない。パフォーマンス・エンジニアリングは、パフォーマンス・テストをソフトウェア開発者の責任範囲へとシフトさせた。パフォーマンス・エンジニアからのインプットがあれば、ソフトウェア開発者はコードを書きながらパフォーマンス・テストを実行できる。開発者は、性能テスト基準に合格する前にコードをリリースすることはない。

デブテスター

ソフトウェア開発者とパフォーマンス・エンジニアには明確な区別があるため、古典的なパフォーマンス・テストには開発者は存在しない。パフォーマンス・エンジニアリングでは、開発テスターが、パフォーマンス・エンジニアリングと開発者チームをつなぐ利害関係者として登場する。開発者やパフォーマンス・エンジニアと同じレベルの専門知識ではないが、確かなコーディングとテストのスキルを持つことで、ギャップを埋めるのだ。彼らはテストを素早く実行することができ、必要に応じてさまざまなツールを使い分けるという点で、開発者よりもはるかに柔軟性がある。

ビジネスアナリスト、アプリケーションエンジニア

テストをシフトさせることで、パフォーマンス・エンジニアリングはビジネス・アナリストとアプリケーション・エンジニアを参加させる。これにより、ユーザー・エクスペリエンスの質を定義するビジネスおよびアプリケーションのパフォーマンス要件が、パフォーマンス基準に組み込まれることが保証される。この2つの役割は、常に最高のアプリケーション・パフォーマンスを保証するために、運用中のアプリを監視する。

適切なパフォーマンス・エンジニアリング・パートナーを得る

パフォーマンス・エンジニアリングは、ソフトウェア開発の状況だけでなく、それに携わるすべての人の仕事内容にも変化をもたらしている。また、より多くの役割が関与するようになったことで、プロセスを合理化するツールやテクノロジーの必要性はかつてないほど高まっている。パフォーマンス・エンジニアリングには、リアルタイムの洞察と分析とともに、右から左へ、左から右へと、エンド・ツー・エンドの統合とコラボレーションが求められる。従来のパフォーマンステストベンダーは、この混沌とした変化の波に対処するための十分な能力を備えていない。しかし、OpenTextには、テストの混沌を設計された秩序に変える、実績ある経験とテクノロジー・ソリューションがあります。

OpenText パフォーマンスエンジニアリングソリューションのオープンアーキテクチャは、あらゆる開発環境において、あらゆるプロトコルやアプリケーションタイプのテストをサポートします。開発者からビジネスアナリストに至るまで、関係者が多数のベンダーやオープンソースのツールを使用し、規模に応じた完全なCI/CD統合を可能にする。OpenTextのツール統合は、アプリケーションのデリバリーを遅らせる開発の待ち時間やテストの時間を迅速に排除する能力を提供します。この統合は、API、ネットワーク状況、仮想サービスの現実的なシミュレーションを迅速に作成することを可能にする。OpenTextのパフォーマンスエンジニアリングソリューションは、既存のオンプレミスまたはクラウドインフラストラクチャをベースに構築され、資産の再利用を促進して既存の投資を活用します。これは、企業全体の複数のアプリケーションのパフォーマンス・テストの需要に応えるための迅速な拡張に役立ちます。

従来のパフォーマンス・テストは、機能テストが完了するまで開始されず、パフォーマンス・テストが終了するまで不具合や根本原因の特定を開始しなかった。OpenTextのパフォーマンスエンジニアリングソリューションは、エンドツーエンドで継続的に不具合を測定・分析し、パフォーマンステストが終了する前でもリアルタイムで根本原因を突き止めます。パフォーマンス基準は、"done "の定義と要件に含まれている。OpenText のリアルタイム分析は、パフォーマンスエンジニアが開発者に迅速にフィードバックを提供し、開発プロセスの早い段階でトラブルシューティングを開始するのに役立ちます。シンセティック・モニタリングと実稼働環境でのリアル・ユーザー・モニタリングは、テストから漏れて次のリリースで修正しなければならないパフォーマンス上の問題についての洞察を提供する。パフォーマンスの観点からエンドユーザーの感情を把握し分析することで、より具体的なフィードバックを開発者に提供し、より良いパフォーマンスを実現するためにアプリケーションを最適化することができます。