ステージングは、本番環境にリリースする前の、デプロイメントプロセスの最後の段階です。アプリケーションのすべての部分が仕様通りに動作することを保証するための、詳細で時間のかかるテストのほとんどは、前の段階の統合テストで行われましたが、まだやるべきことはあります。ステージングとは、本番環境へのリリース前の最終的なリハーサルのことです。
ステージング環境の構築
ステージングおよびデプロイメントテストにおける重要な要素は、テストが行われるコンピュータ環境が合理的に可能な限り、本番環境と一致しなければならないということです。つまり、ステージングと本番のマシン構成を一致させなければなりません。さらに、サーバーソフトウェア、データベース、ストレージのリソースも一致させなければなりません。ホスト環境でデプロイメントテストを行う場合、ステージング環境を立ち上げるには通常、一時的な仮想マシンやコンテナのデプロイメントをいくつか作成するだけでよいのです。コンピューティングリソースをオンプレミスに置き、ハードウェアを直接操作している企業では、ステージング環境の構築はより困難となります。ステージング用のハードウェアを本番用のハードウェアと一致させるには、時間とコストがかかります。ソフトウェアの設定も同様です。ベアメタルリソースを使用するためのコストは、仮想化環境に移行するための十分な動機となり得ます。VM、コンテナ、デバイス・エミュレータを立ち上げることは、タブレットや携帯電話を入手してプロビジョニングするよりもずっと簡単で安価なことなのです。 これが、AmazonがAWS Device Farmサービスをリリースした理由の1つです。
AWS、Azure、Google Cloudなどのサービスプロバイダを利用してクラウド上で展開テストや作業を行っている企業は、ステージング環境を簡単に作成することができます。通常、必要なコンピューティング環境のプロビジョニング、環境のオーケストレーション、関連するデータおよびファイルストレージサービスへの初期データとファイルのインジェクションを行うスクリプトを実行する程度の作業で済みます。このようなエフェメラルプロビジョニングは、ステージングプロセスでデプロイメントテストを実行する際に、同じ環境を作成する信頼性の高いアプローチとなります。また、エフェメラルプロビジョニングは、テストを実行するときだけテスト環境の費用が発生するという点で、費用対効果に優れています。ベストプラクティスは、ステージングテストが実行された後、次のテストセッションまで環境を破棄することです。テスト環境が破棄されれば、企業は使用されていない非常に高価なテスト環境の費用を支払う必要がなくなります。
ステージング環境でのテスト
ステージング環境が設定されると、次はテストの実行です。先ほど解説したように、難易度の高い内容は統合テストで行われました。ステージング環境におけるテスト範囲は、テスト対象のアプリケーションがビジネス要件と期待に合致していることを確認することです。したがって、通常行われるテストは、スモークテストとユーザー受け入れテスト（UAT）です。
Staging and User Acceptance tests in the CI/CD Dev Lifecycle
スモークテスト
スモークテストは、サニティテストとも呼ばれ、テスト対象のアプリケーションが最小限の期待通りに動作することを保証する、スクリプトまたは人間によって実行される高速なテストのことです。例えば、人間が行うスモークテストでは、アプリにログインし、検索や標準機能の使用など、通常のアクティビティを行います。これは、泥臭いやり方とも言えるでしょう。テストの目的は、通常の明らかな機能が期待通りに動作することを確認することです。主要な機能が動作すれば、アプリケーションの機能スタックにあるより複雑な機能も動作するはずだという仮定です。もちろん、これはすべて、厳密で時間のかかるテストが「統合」の頃に行われていたという前提のもとで行われています。
ユーザー受け入れテスト
ユーザー受け入れテスト（UAT）は、ビジネスにフォーカスしています。ソフトウエアは魔法でできるものではありません。消費者をはじめ、社内の人、外部の関係者など、彼ら全てのニーズを満足させなければなりません。UAT は、アプリケーションが期待に応えているかどうかをビジネスが確認する場です。通常、UATのテスト担当者は、ビジネスユーザーやプロダクトマネージャーになります。基本的な機能が期待通りに動作することを確認することに加えて、テスト担当者は、アプリケーションの見た目がブランディング、ロケール、およびスタイルの標準に適合していることを確認します。例えば、適切なフォントが使用されているか、グラフィックが会社の基準を満たしているか、製品の全体的な使い勝手が許容範囲にあるかなどを確認することを意味します。
繰り返しになりますが、ステージングとは本番リリース前の最後のテストセッションです。したがって、一般消費者向けにリリースされようとしているコードとビジネス要件が合致していることを確認することは、最も重要な項目です。
本番リリースにおけるA/Bテストアプローチの価値
昔のウォーターフォールテストでは、アプリケーションのすべての機能が一度にリリースされ、テストプロセスは、コードからテスト、デプロイと階層的になっていました。もしもテストが失敗したら、リリースの連鎖をすべて遡ることになります。今日、私たちは異なるアプローチを採用しています。私たちは継続的なリリースサイクルを採用しており、一度に1つの小さな機能をリリースし、反復的にテストを行っています。
本番前の継続的なテストという考え方は、本番リリースにも波及しています。以前は、新しいバージョンのコードをリリースすると、以前のコードをすべて置き換えていましたが、今日では、新しいバージョンをユーザーベースの小さなセグメントにリリースして全てがうまくいけば、新しいバージョンが100％浸透するまでそのユーザーベースを拡大することがよくあります。例えば、Webサイトへのリクエスト100件に対して、そのうち10件は新バージョンのコードに誘導し、残りの90件は旧バージョンに直行させるような方法です。この手法をA/Bテストといいます。
A/Bテストは、様々な点で有用です。まず、ソフトウェアの真のテスト環境は、現実の世界だけです。リリース前のテストはすべて仮定に基づくものです。リリース前のテストはほとんどの問題に対処できますが、特に人間の気まぐれに左右されるコードに関しては、すべての運用上の問題に対処できるわけではありません。したがって、ユーザーの一部にコードをリリースすることで、全ユーザーに悪い体験をさせることなく、実世界でのテストに必要なランダムな相互作用を提供することができます。
2つ目の利点は、比較分析ができることです。A/Bテストでは、両方のバージョンのコードが完全に動作していることを思い出してください。使用状況データは収集されている。データが集まれば、アナリストは使用結果を測定し、比較することができます。A/Bテストでは、ユーザーが新しいコードに費やす時間が、以前のバージョンに比べて短くなっていることが明らかになるかもしれません。あるいは、全体的なパフォーマンスが低下している可能性もあります。このようなパターンが明らかになれば、新しいバージョンの問題が解決されるまで、すべてのウェブトラフィックを古いバージョンに戻すことは比較的簡単です。
すべてを統合する
ステージングは、デプロイメントテストプロセスの重要な部分です。テクノロジーとビジネスが一体となる場所です。運用テストのプロセスは、統合テストほど広範囲ではありませんが、ビジネス指向のテスト担当者が実施するテストから得られる洞察は、リリースされるソフトウェアの全体的な実行可能性に関する重要な情報を提供します。ほとんどのソフトウェアは、実際のニーズを満たすために作成され、それらのニーズは、通常、ビジネスを実行している人々によって最もよく知られています。彼らの受け入れが重要なのです。しかし、それ以上に重要なグループがあります。それは、コードの利用者です。A/Bをリリースサイクルの一部として組み込むことで、重要なコードを作成するために必要な、さらなる洞察が得られます。重要なコードを作ること、それがすべてなのです。
mablのテスト自動化プラットフォームの無料トライアルはこちらからお試し頂けます。
