クラウド移行テスト戦略作成ガイド

エンタープライズ アプリケーションをクラウドに移行すると、特有の課題が生じる可能性があります。ユーザーは、サーバーやローカル IT インフラストラクチャのその他の基盤コンポーネントと直接対話しません。クラウドでは、アプリケーションは誰でも閲覧および使用できます。したがって、アプリケーション テストはあらゆるクラウド移行の重要な部分となります。

正式なフレームワークは、IT チームがクラウド移行テスト戦略を策定し、アプリケーションがクラウドで適切に機能することを保証するのに役立ちます。重点を置くべき主な領域、従うべきベスト プラクティス、考えられる問題と解決策について見てみましょう。

クラウド移行テストが重要なのはなぜですか?

クラウド移行テストは、IT チームがアプリケーションがクラウドに移行された後も引き続き適切に機能し、より優れたユーザー エクスペリエンスを保証するのに役立ちます。そのためには、移行前と移行後のアプリケーションのパフォーマンス、オンプレミスでの実行方法、クラウドに移行した後の動作を測定する必要があります。

クラウド移行テストから得られる指標は、IT スタッフの時間とリソースを消費する推測に基づく比較によって発生する可能性のある問題を特定し、定量化するのに役立ちます。主要な指標には、アプリケーションの起動時間と応答時間、ピーク需要時とオフ時間のパフォーマンス、さまざまなプラットフォーム (デスクトップ、リモート接続、モバイル デバイス) での可用性が含まれます。

さらに、クラウド ベンダーがアップデートをリリースすると、アプリのパフォーマンスに問題が生じる可能性があります。テスト メトリックを通じてこれを確認し、クラウド プロバイダーと協力して何が起こったのか、どのような調整を行えばこれらの問題を修正できるのかを調べます。

最後に、クラウド移行テストにより、IT チームがパフォーマンスや UX を微調整してアプリケーションをクラウドに保持する正当性を確認できる箇所が明らかになります。

クラウド移行テストと従来のアプリケーションテストの違い

オンプレミス アプリケーションのテストとクラウドに移行したアプリケーションのテストの主な違いは、クラウド コンピューティングのスケーラビリティだけでなく、追加の統合と依存関係にも適応する必要があることです。一部の統合は識別や理解が難しい場合があります。クラウド テスト フレームワークは、オンプレミス コンテンツのテストに使用するフレームワークとは異なる場合があります。また、負荷テストや侵入テストなどの一部のツールも異なる場合があります。

ただし、テストの実際の最終目標はオンプレミスからクラウドに変更してはならないことに注意してください。目標やガイドラインが異なると、比較できなくなります。アプリケーションをクラウドに移行するための取り組みを明確に示すために、同じ手順とツールを多く使用します。テスト フレームワークまたはアプローチの変更は結果に影響する可能性があります。

クラウド移行テストの種類

クラウド移行テストの目的は、考えられるすべての機能と機能をテストすることではなく、アプリケーションが期待どおりに動作していることを確認するために、信頼性の高いテストとメトリックの結果が必要です。クラウド移行では、いくつかの異なるタイプのテストが特に重要です。

機能検証。クラウド移行作業の両側で、ビルドがコンポーネントとサービス機能の要件を満たしていることを確認します。何かが欠けているとすぐに明らかになります。

パフォーマンス。これには、データ量、容量負荷、CPU およびメモリ使用量を処理する能力など、実際の条件下でのアプリケーションのパフォーマンスを測定するためのいくつかのメトリックが含まれます。

統合されました。アプリケーションは他のサービスやアプリケーションに接続して、クラウド、オンプレミス、またはその両方でデータを共有する場合があります。 IT チームは、これらの接続がクラウド内でまだ有効であることを確認する必要があります。依存するサービスが異なるクラウドにある場合やオンプレミスで保持されている場合は、これが難しくなる可能性があります。

その他のテスト項目: アプリに専用のポータルがある場合、またはモバイル デバイスで実行するために UI の調整が必要な場合は、Android プラットフォームと Apple プラットフォームの両方でテストします。これは、クラウドに移行されたアプリケーションとオンプレミスで実行されているアプリケーションの両方に当てはまります。考えられるすべてのデバイス タイプをテストすることは現実的ではない可能性があるため、ユーザー ベースと協力して最適なモバイル プラットフォームを決定します。

また、データ速度の違いがアプリの動作に影響を与える可能性があるため、携帯電話ネットワークと Wi-Fi ネットワークの両方でテストしてください。会社の Wi-Fi ネットワークの外でこれを実行してください。ネットワーク内でのサービスへのアクセス方法は、Wi-Fi ネットワーク外とは異なる場合があり、その結果、アプリの動作が異なったり、まったく動作しなかったりする可能性があります。

最後に、印刷可能性のテストですが、はい、人々はまだ印刷しており、一部の人にとっては印刷可能性のテストは重要な職務です。この潜在的に困難な技術的問題を過小評価しないでください。クラウドベースのアプリケーションからローカル プリンターに印刷すると、オンプレミスでは発生しないセキュリティとネットワークの課題が生じます。

クラウド移行テストにおけるセキュリティの考慮事項

オンプレミスからクラウドへのアプリケーションの移行を開始する前に、適切なアプリケーション セキュリティ監査を実施し、エンド ユーザーの権限を調整する必要があります。最も避けたいのは、アプリケーションの動作や相互依存関係に影響を与える追加の変更を導入することです。

クラウド移行テストには、次の 3 つの重要な要素を確認するためのセキュリティ検証を含める必要があります。

（１）アプリケーションにアクセスできるのは誰ですか？ユーザーがアクセスするアカウントと機能から始めます。変数を追加してもテストは役に立たず、テストのスピードも上がりません。そのため、横方向の移動では、エンド ユーザーのアクセスはローカル アプリケーションで持っているものを反映する必要があり、それ以上でもそれ以下でもありません。

（２）最小権限をどのように確保するか？クラウド内の異なるサービス間でデータを移動する際に、最小限の権限を確保するためにどのような手順を踏みますか?クラウドベンダーは、これを支援するサービスとレポートを提供しています。時間をかけて学び、使用してください。

（３）セキュリティの変更はアプリケーションに影響しますか？セキュリティの変更はパフォーマンスに影響する可能性があるため、変更後は必ずアプリケーション テストを再実行してください。たとえば、移動中および保存中のデータを暗号化すると、アプリケーションの応答時間が変わりますか、それとも CPU サイクルのオーバーヘッドが増加しますか?これは完全なテストのサブセットになる場合がありますが、アプリケーションが引き続き正常に動作し、セキュリティの変更によってアプリケーションがオフラインにならないことを再検証する必要があります。

クラウド移行テストにおける 7 つの一般的な課題と、その解決のためのベスト プラクティス

物事がどれだけスムーズに進んでいても、アプリケーションのテストは課題となります。あらゆる計画とテストにもかかわらず、依然として問題に遭遇することがあります。何も期待通りにスムーズには進みませんが、ほとんどの問題は解決できます。

課題 1: アプリケーションテストの指標を優先順位付けする方法

アプリケーションのユーザー エクスペリエンスとセキュリティはアプリケーション全体にとって重要ですが、最終的にはアプリケーションが期待どおりに動作する必要があります。コア機能が欠けているアプリは、たとえそれが完全に安全であったり、ユーザーにとって非常に合理化されていたとしても、何のメリットもありません。

ベスト プラクティス: 設計とセキュリティを重要な機能とバランスさせます。クラウド移行プロセスの早い段階で、機能、ユーザー エクスペリエンス、セキュリティなど、すべての要素に対処するために時間と労力を費やしてください。これらは、異なる段階で対処できる別個の側面ではありません。これらは相互に関連しており、早い段階で対処する必要があります。

課題2: アプリを機能させるために手抜きをしない

アプリケーションがクラウドで適切に実行されることを確認することは重要ですが、短期的な目標を達成するためだけに悪い習慣に陥らないでください。 IT チームは、新しい環境でアプリケーションを適切に実行するためにセキュリティ制御を削減または削除した後、それらの保護を復元することを忘れることがあります。これにより、最初は時間が節約されるかもしれませんが、後々ますます複雑な作業が発生し、全体的なテストが困難になります。

ベストプラクティス: 最初からセキュリティを計画します。セキュリティ権限の問題が頻繁に発生し、アプリケーションの機能を妨げる可能性がありますが、すぐに動作させるために全面的な変更を加えるという衝動的な反応は避けてください。クラウド移行計画では、これらの問題に対処するための時間を確保してください。

課題3: ITだけではクラウド移行をテストできない

クラウド移行は複雑な作業であり、移行されたアプリケーションが大規模に安全に実行できるようにするには、幅広い専門知識が必要です。 IT 部門には大きな責任があり、こうした取り組みを主導することができますが、開発の専門知識がなければ技術面だけに集中することはできません。

ベストプラクティス: 多様性のあるテスト チームを構築します。アプリケーション サポートを提供し、起こりうる問題を特定するために、部門横断的なチームを編成します。チームは柔軟である必要があり、あらゆる側面に対応できるコンテンツの専門家が必要です。会議では、プロジェクトをカテゴリに分類して、参加者全員に情報が多すぎると退屈したり、専門知識を超えた技術的な問題を理解できなくなったりしないようにします。

課題4: 「簡単な」アップデートとスコープクリープへの抵抗

クラウドに移行するアプリケーションの暗号化を有効にすることは、理想的で、一見簡単に思えるかもしれません。ただし、注意が必要です。変更を加えると、アプリケーションの操作の他の多くの側面に意図せず影響が及び、技術的な問題やコストが増加する可能性があります。移行テストにおけるこの種の範囲または機能の拡大は、すぐに維持できないレベルにまで拡大する可能性があります。

ベスト プラクティス: アドオンをテストしてレビューします。まず、アプリのコア機能については当初の計画を忠実に守るようにしてください。テスト段階は機能拡張を行う時間や場所ではありません。小さな新機能や機能を追加する必要がある場合は、全員の同意を得て変更をテストおよびレビューし、その広範な影響を理解してください。

課題 5: テストの頻度と競合する優先事項のバランスをとる

理想的には、継続的なセキュリティ テストと、少なくとも毎週のテストを実行して、データを検証し、エラー ログを処理する必要があります。残念ながら、お金、時間、IT と管理の優先順位の変化により、これらの計画が覆される可能性があります。クラウドの使用には1秒ごとに費用がかかります。従業員には時間と費用がかかり、アプリケーションがリリースされると、ほとんどの運用チームと開発チームは他のプロジェクトに移行します。

ベスト プラクティス: メジャー アップデートを中心に計画を立て、さらなるアップデートを推進します。 IT 部門は、必要な要件を満たすために利用可能なリソースを使用する方法を常に見つけます。クラウド移行テストでは、経営陣が何を望んでいるか、何を必要としているか、何を期待しているかを理解するようにしてください。基本アプリケーションまたはプラットフォームへの主要な変更について、毎日および毎週チェックするテスト フレームワークを設定します。より多くのリソースが利用できる場合は、より頻繁な定期検査を目指します。

課題6: UXテストの範囲が狭い

一部の IT チームは、ローカル テストに一般ユーザー プールに依存したり、特定のソフトウェアの少数の専門家に依存したりしています。しかし、アプリケーションをクラウドに移行する場合は、アプリケーションをより完全に理解する必要があります。これは、技術的な観点だけでなく、複数の観点から全体的なユーザー エクスペリエンスに関するデータを収集することを意味します。

ベストプラクティス: ユーザー テスト チームを拡大します。さまざまな経験と役割を持つ大規模なテスターグループとユーザーテストを調整します。クラウドに精通した人も初心者も対象です。ほとんどのエンドユーザーはクラウドの内部の仕組みを知らず、気にも留めませんが、アプリケーションを見てパフォーマンスについて一定の期待を抱きます。時には、彼らの方があなたよりもよく理解しているかもしれません。

課題 #7: テスト指標はクラウドコストの問題を無視している

オンプレミスの移行では、通常、関連するアプリケーションのすべての部分を所有することになります。クラウド移行では、すべてのプロセス ステップ、呼び出されるサービス、およびキャッシュまたはオンプレミスに転送されるデータにコストが発生します。他のクラウド サービスとの統合や依存関係もありますが、その一部は明らかではない可能性があります。新しいクラウドベースのテスト ツールを使用することもできます。請求書を受け取ると、コストが衝撃的になり、アプリケーションを調整したり、クラウド移行を再評価したりする必要が生じる場合があります。

ベストプラクティス: 定期的なテストによりコストの傾向が明らかになります。コスト管理はクラウド移行テストの焦点では​​ありませんが、テストを行うことで、企業はアプリケーションがクラウドでどの程度適切に実行されるかについての洞察を得ることができます。そうは言っても、クラウド移行テストを頻繁に実施することで、組織はデータ転送、使用パターン、主要な依存関係をより深く理解できるようになります。つまり、請求書が届いたときに驚くことはありません。