この記事では、全社的にパフォーマンステストをシフトレフトする方法をお教えします。
どのスプリントも重要であり、意思決定は迅速に行われなければなりません。すばやいフィードバックを可能にするためには、テストチームはアプリケーションをとても短い期間で、徹底的に検証する必要があります。この成果を最大化するために、できるだけ早い段階で可能な限りのテストを行って最大のROIを得られるよう、テストへのアプローチを現代的なものに変えていっても良いのではないでしょうか。
パフォーマンステストのシフトレフトとは
パフォーマンステストをシフトレフトするとは、開発者とテスト担当者が開発サイクルの初期段階でパフォーマンステストを実施できるようにすることを意味します。従来、パフォーマンステストは特殊なツールとスキルを必要とする、開発サイクルの最後に実行されるタスクでした。つまり、熟練したパフォーマンステストエンジニアによって、専用環境で高価なハードウェアのセットを使用して実行されます。パフォーマンステストをシフトレフトすると、開発中の個々のコンポーネントに対して、テスターによる小規模で臨機応変なパフォーマンステストが可能になります。
これを達成するためには、機能を実装しながらユニットテストや機能テストの作成をすると同時にパフォーマンステストの作成を開始し、それらのテストが自動的に実行されるよう設定し、パフォーマンスが低下したときにアラートを報告する仕組みが必要になります。テストを自動的に実行するには、パフォーマンステストの実行をCI/CDプロセスの一部として緊密に統合する必要があります。コードがチェックインされるたびに、機能テストやユニットテストとともにローカル環境でパフォーマンステストが実行されます。
このプロセスにより、追加された新しいコンポーネントがアプリケーションの全体的なパフォーマンスに与える微細な影響を把握することができ、最終的にデリバリーライフサイクルの早い段階でパフォーマンス関連の欠陥を発見することができます。企業文化の観点から言えば、パフォーマンステストをシフトレフトすることは、開発者の関与を増やすことも意味します。ほとんどの場合、開発チームは、パフォーマンスの低下を発見したその日にパフォーマンスの改善を行うことができ、アプリケーション全体が構築されるまで待つ必要はありません。
パフォーマンステストをシフトレフトするために組織が行うべきこと
まず何よりも、全社的な協力態勢が確立されている必要があります。事後対策としてではなく、プロセスとして品質に対処することは、企業全体でパフォーマンステストをシフトレフトさせるために不可欠です。このプロセスの主役はプロダクトマネージャーです。パフォーマンステストの実施とテストの開発にかかる時間によって、実装期間が長くなり、開発サイクルが遅くなる可能性があるからです。PMチームは、このプロセスの必要性を理解し、ホットフィックスの減少や、パフォーマンスの最適化という点でメリットがあることを理解する必要があります。
次に、アプリケーションレベルに加えてコンポーネントレベルで SLAを定義します。これにより早期のフィードバックが可能になり、開発者が開発中の個々のコンポーネントに対するコード変更の影響を理解するのに役立ちます。このようなきめ細かいパフォーマンステストにより、関係者はホットスポットの発生箇所を簡単に知ることができます。
また、UI中心のテストからAPIテストやデータベーステストなどの自動化されたテストに移行することが重要です。これらのタイプのテストプラクティスは、より保守性とスケーラビリティが高いだけではなく、パフォーマンステストに流用するのが簡単で、パフォーマンスの問題の根本原因をピンポイントで突き止めることができ、変化に対する高い耐性があります。
最後に、パフォーマンステストをビルドプロセスに統合して、コードチェックイン時に基本的なスモークテストとしてパフォーマンステストを実行し、夜間に完全なパフォーマンステストを実行する必要があります。それには、ハードウェア要件を再検討する必要があります。自動化されたパフォーマンステストは機能テストよりも多くのコンピューティングリソースを必要とするため、開発チームはそれに備えなければなりません。既存のパフォーマンスインフラストラクチャがシフトレフトアプローチに適合しているか、それとも変更が必要か（クラウド・エージェントなど）は、パフォーマンステストの自動化に移行する際の重要な考慮事項の1つになります。
パフォーマンステストのシフトレフトにおける開発者とテスターの役割
開発者はアプリケーションのパフォーマンスに責任があります。開発者は、マイクロサービス、REST/SOAP API、およびモジュール化設計アーキテクチャを駆使して、いつでもパフォーマンステストの準備が整ったアプリケーションを作成し、個々の部分を開発時にテストできるようにする必要があります。
テスターは、パフォーマンステストプロセスに流用しやすいよう、アプリケーションの重要なワークフローに沿ったテストケースを作成します。アプリケーションのAPIレイヤーに焦点を当てることで、テストをより弾力的に変更したり管理することができます。どちらのチームも、アプリケーションのSLAが満たされていなかった場合にレポートを受け取り、最新のコードチェックインに基づいて問題のある領域を特定したり、最適化が必要なコンポーネントを特定できます。
SOAtest/Virtualize 製品ページへ >
ツール統合によるパフォーマンステストのシフトレフト
パフォーマンステストプロセスのシフトレフトに適した個々のツールを選択することは重要ですが、自動化されたワークフローにそれらのツールを統合して使用することはもっと重要です。開発初期段階でのパフォーマンステストは、精通したテスターや開発者がさまざまなオープンソースツールや市販のツールを用い、技術を工夫して個人的に実行することがよくありますが、それでは自動化されたプロセス全体の一部として統合されていないため、結局は結果が見落とされることになります。
そうではなく、テスターは自動化された方法でパフォーマンステストを作成できる専門の商用ツールを使用する必要があります。開発者は、同様のツールを使用して、作業を最適化したり、低レベルのスクリプトを作成して自動化と負荷テストを推進することができます。では、どんなツールが必要なのでしょうか？
以下のツールはメンテナンスを簡素化し、集約的に管理でき、結果を把握するための使いやすいUIを提供します。
-
機能テストツール
機能テストは、継続的テスト戦略の一部であるべきです。機能テスト自動化に使用するツールは、アプリケーションのAPIレイヤー（テストケースの実行アクションと保守を簡略化するため）とUIレイヤー（エンドツーエンドおよびユーザーエクスペリエンステスト用）の両方に対応する必要があります。機能テストツールは、UIレベルとAPIレベルの両方で、再利用可能なベースライン実行パスを作成するために使用されます。これらの実行パスはユーザーストーリーと一致しているため、パフォーマンステストの結果とその影響を受けるユーザーストーリーを容易に関連付けることができます。
-
パフォーマンステストツール
とくに、機能テストの成果物を流用し、高負荷環境でそれらのテストを実行するパフォーマンステストツールが必要です。それらのツールには、時間ごとの仮想ユーザーの数やトランザクション数など、さまざまな負荷制御パラメーターが必要です。これらのツールは、結果を集約するためのダッシュボードに結果をレポートする必要があります。
-
サービス仮想化ツール
サービス仮想化ツールは、シフトレフトされたパフォーマンステストの初期段階で、緊密に結合されたアプリケーションの欠落しているコンポーネントに対処します。パフォーマンステストの初期段階で直面する主な課題の1つは、並行する開発作業やサードパーティのコンポーネントなどが要因で、バックエンドのインフラストラクチャが利用できないケースがあることです。これらの依存システムのベースラインを確立し、それらを仮想サービスとしてモデル化することにより、運用環境と同様のアプリケーション ベースラインを再現し、テスト中には個々のコンポーネントのパフォーマンスに集中することができます。
-
継続的インテグレーションツール
シフトレフトされたパフォーマンステストは、プロセスが自動化されている場合に最も効果的です。自動化されていれば、「パフォーマンステスト」の負担は、結果をレビューし、テストをメンテナンスすることだけです。プロセスが自動化されており手動ではないため、長期的にはテスト実施にかかる時間を短縮します。
パフォーマンステスト戦略を継続的テスト戦略と整合させ、Jenkins、Bamboo、Microsoft VSTSなどのツールと統合することで、完全に自動化されたプロセスを構築できます。CIツールは、夜間に安定して総合的なパフォーマンステストを実行できるように、コードチェックインのたびにパフォーマンステストを実行できなければなりません。
さらに、CIツールはレポートおよび分析ダッシュボードと統合し、自動的に結果を公開して傾向データをすばやく理解できるようにする必要があります。
-
結果を集計する一元化されたダッシュボード
レポートおよび分析ダッシュボードについて言えば…集中型ダッシュボードは、プロジェクト、コンポーネント、API単位でのトレンド情報を表示することで、コンポーネントのパフォーマンステストのインクリメンタルな変化を理解できるため、非常に重要です。
集中型ダッシュボードには、パフォーマンステストを自動化し、パフォーマンステストの結果を成功/失敗に振り分けるためのSLAを定義し、過去のトレンドを確認する機能が必要です。さらに、レポートダッシュボードでは、パフォーマンステストと要件をリンクする詳細情報を表示する必要があります。この情報によって、ビジネスは問題の優先順位付けを適切に行い、ハイレベルの成功/失敗を見るだけでなく、検出された障害の原因を特定することができます。
シフトレフトアプローチでは、（マネージャーやテスターだけでなく）開発者もダッシュボードのユーザーに加えられるため、開発者がSLAを満たしていないケースや過去のトレンドの要因を効果的に調査して突き止められるよう、ダッシュボードに低レベルの詳細情報を持たせる必要があります。
まとめ
頻繁なホットパッチやパフォーマンス最適化のための更新はユーザーを疲労させます。ユーザーが求めているのは新機能や機能性の向上です。従来のパフォーマンステストはサイクルの終わりに行われるため、必然的に納期に影響を与えます。そのため、ネガティブな先入観を持って見られます。パフォーマンステストプロセスを統合し、アジャイルチームが「シフトレフト」された反復的なパフォーマンステストを採用できるようにすると、問題を早期に特定できます。これにより、パフォーマンスの低下に対して容易に技術上の意思決定を下せるだけでなく、個々の領域を最適化し、パフォーマンスに集中することにより、最終的には全体としてよりパフォーマンスの高い製品が提供されます。
（この記事は、開発元Parasoft社 Blog 「How to optimize performance testing with a shift-left approach」2018年10月5日の翻訳記事です。）
Parasoft SOAtest/Virtualizeについて
>
SOAtest/Virtualizeは、APIの開発者／利用者に向けてテストの自動化とテスト環境の仮想化の2つの側面から開発を効率化します。SOAtest/Virtualizeは、APIのテストドライバーを提供し、開発中のAPIのテストを自動化する機能と、APIを利用するアプリケーションが必要とするAPIをスタブとして仮想化する機能を同梱して提供します。