本記事では、DevOpsインフィニティループにおけるテストフェーズの重要性をあらためて整理します。あわせて、関連するツールやフレームワーク、手法、テストの種類、そしてDevOpsのベストプラクティス、特にテストフェーズの実装に活用できるAWSのエコシステムやサービスを概観します。技術的な深掘りではなく、全体像をつかむための入門的な内容です。パイプラインの具体的な構築手順やインフラへのデプロイ手順までは扱わず、押さえておきたいポイントや選択肢、関連サービスを紹介します。
テストフェーズ
DevOpsでは、ソフトウェアを迅速にリリースすることが求められ、1日に何度もデプロイが行われるケースもあります。これを実現するには、コードを数分以内に、できるだけ高頻度でテストできる体制が欠かせません。テストフェーズでは、テスト結果に基づき、ビルドを次のステージに進めるか、それとも止めるかを人手を介さずに判断します。
ソフトウェアテストは、ソフトウェア開発ライフサイクル(SDLC)に欠かせないステップであり、本番リリース前にバグを早期発見・解決できることには計り知れない価値があります。パイプラインにテストフェーズを組み込めば、潜在的なバグを早い段階で洗い出せるという大きなメリットが得られます。テストフェーズでは、アプリケーションに応じてさまざまな自動テストツールを使い分けます。たとえば、APIの公開メソッドのテストにはNewmanが手軽ですし、コードやコンポーネントの単体テストにはJUnit/XunitやJestが適しています。Webアプリケーションであれば、UIレベルまでカバーするフルなe2eテストにはPlaywrightやCypressが理想的です。
テストフェーズは、TestRailのようなテスト管理ツールを組み込むのにも適したフェーズです。TestRailはコードベースやテスト結果に関する詳細なレポートを生成し、開発サイクルやアプリケーションの成熟度をステークホルダーに可視化します。これにより、社内のステークホルダー向けレポーティングが容易になり、開発プロセスやプロダクトの成熟度への理解も深まります。ここで取り入れたいのが、「品質はQA部門の中だけにあるものではなく、組織全体に宿るものだ」という考え方です。このマインドセットが最良の成果につながり、テストフェーズはその成功への道筋を支えてくれます。
テストフェーズが重要な理由
テストフェーズの最大のメリットは、テスト・品質検証・パフォーマンス評価をSDLCのできるだけ早い段階で行えることです。この「シフトレフト」の考え方は、SDLCの終盤にまとめてテストを行っていた従来型・手動中心のアプローチからの大きな転換です。
テストフェーズの主なメリットは次の通りです。
- SDLCの早期にテストを組み込むことで、継続的テストが可能となり、ソフトウェアをより速く、絶え間なく届けられるようになります。素早く・頻繁に・早期にテストできるため、エラーの見落としリスクも下がります。
- テストを自動化すれば、エラーを見逃すという人的要因を排除できます。一方で、テストシナリオの保守・更新は必要となり、場合によってはテスト専任の開発者チームを設ける必要が出てくることもあります。
- SDLCの各ステップでは、それぞれ異なる種類のテスト(単体テスト、APIテスト、e2eテスト、UIテストなど)が行われます。これにより、エラー検出時の手戻りを最小限に抑えられます。
このフェーズを導入することで、アプリケーションの提供までにかかる時間が短縮され、エラーやバグも最小化されます。さらに、エンジニアリング部門全体がアプリの品質に責任を持つ「品質責任の共有モデル」の確立にもつながります。
テストピラミッドについて
テストピラミッドはソフトウェア開発でよく知られた概念で、さまざまな記事や書籍で取り上げられてきましたが、その原典はMike Cohnの著書Succeeding with Agileです。ピラミッドというメタファーは、ソフトウェア開発で実装すべきテストの階層を直感的に捉えるのに役立ちます。
振る舞い駆動(Behavior-Driven)型のテストは、テストシナリオと期待結果を組み合わせるため最も効果的とされます。これらはコンポーネント間の統合をカバーすることを前提としており、単一のユニットだけでなく、システム全体や独立した複雑なモジュールを検証できる点で、統合テストとして高い価値を持ちます。そう考えると、システムをデプロイし統合し終わった状態で実行するUI e2eテストへの投資は良いアイデアに思えますし、実際その通りです。ただし落とし穴もあります。たとえば、UI e2eテストだけに頼ると、コストが過剰に膨らみ、保守の負担やストレスが増えるおそれがあります。
UIエンドツーエンドテストばかりに投資すると、テストピラミッドが「アイスクリームコーン」と呼ばれるアンチパターン、いわゆる逆ピラミッド型に陥りがちです。
このコーン型を維持するのは悪夢のようなもので、コストは膨れ上がり、テスト結果は不安定になり、テストフェーズ本来のメリットを失う可能性が高くなります。
ここからは、テストピラミッドの各層と代表的なテストの種類、それぞれのメリットを見ていきましょう。
- 単体テスト(Unit Tests):最も基本的かつ粒度の細かいテストで、通常はメソッドやコンポーネントなど1つの作業単位に焦点を当てます。テストピラミッドの最下層に位置し、ビルドステージでコンパイルおよび実行が可能です。実装が容易で低コスト、コード品質を守る最初の防衛線として機能します。
- 統合テスト/APIテスト:統合はAPIを介して行われるため、この層のテストはシステムにとって極めて重要です。システムが統合された状態で正しく動作すること(つまり、各作業単位が組み合わさっても問題なく機能すること)を検証する必要があります。組織体制に応じて、開発者または品質担当者のいずれが担当しても構いません。結局のところ、単体テストしか行われていない航空機に進んで乗りたい人はいないはずです。
テスト自動化とは
抱えるソフトウェアが増え続けている場合はもちろん、比較的変化が少ないソフトウェアであっても、手作業でアプリケーションをテストし続けるのは大きな負担です。繰り返し作業を抜け漏れなく実施し、人的ミスを抑え込むことを手動で実現するのは、ほぼ不可能と言っても過言ではありません。そこで頼りになるのが自動化です。今やインフラのプロビジョニングからビルドのオーケストレーション、コードやアプリケーションのテストまで、ほぼあらゆる領域で自動化が標準となっています。
実務的には、開発者は成果物やタスクの一部として単体テストおよび統合テストの作成に注力し、品質担当者はビジネスやプロダクトオーナーから提供されるシナリオに基づいてUI e2eテストを作成する、という分担になります。主に手動テストで行われるテスト発見の工程は、自動化の前段階として実施します。
テストフェーズの自動化を実現するには、現在市場で提供されているツールから自社に合うものを選んで活用できます。選択肢は事実上無限にあり、どれを選ぶかは要件と開発組織のスキルセット次第です。PlaywrightとCypressはUI e2eテストに強く、いずれにも長所と短所があります。スタックがJSであれば、テストピラミッドのすべての層を1つのツールでカバーする、ワンストップな選択肢として活用することも可能です。次の層は統合テストで、こちらもKatalon、PostmanのNewmanなど選択肢が豊富です。ツール選定では、機能はもちろん、複雑性、相互運用性、CI/CDパイプラインへの組み込みやすさを必ず確認してください(これらのツールを導入する目的は、最終的にテストフェーズ、つまりCI/CDパイプラインに組み込むことだからです)。最後に重要なのが単体テストの層です。これらの作成・実行には、コードベースに最も合うツールを選びます。.NetコードならXUnit、JavaならJUnit、JSやTSのコードならJestが選択肢になります(あるいは前述の通り、Playwrightのようなモダンで多用途なツールもあり、コードベースがJSやTSであれば、Playwrightだけでピラミッド全体をカバーすることもできます。詳細はPlaywrightの公式ドキュメントをご参照ください)。
テストフェーズ実装のためのAWS CodePipeline
テストフェーズは、現在市場に存在するさまざまなツールやサービスで実装できます。JenkinsやCircleCIといったサービスでも、目的を達成するための基本的な流れは変わりません。すなわち、ソースコードをプル>コードをビルド>テスト>プリプロダクション(ステージング)へデプロイ>必要に応じて再テスト>本番へデプロイ。これでデプロイは完了です。
選択肢は数多くありますが、ここではAWSのサービスを取り上げます。AWS CodePipelineはフルマネージドの継続的デリバリー(CD)サービスで、パイプラインの構築、ステージのオーケストレーション、アプリケーションやインフラへの更新の配信を支援します。AWS CodePipelineは、AWS CodeDeploy、AWS CodeCommit、AWS CodeBuildといった他のAWS DevOpsサービスはもちろん、JenkinsやGithubなどの定番サードパーティアクションプロバイダーともスムーズに連携します。
パイプラインのシンプルなユースケースは、コードをプル>ビルド>デプロイ、というものです。一見シンプルで、この場合はパイプラインのビルドステージで単体テストのみを実行する形になります。これはこれで十分です。ですが、テストフェーズに統合テストやUI e2eテストまで含む、もう少し複雑なパイプラインを考えてみましょう。流れは次のようになります。コードをプル>ビルド>ステージングへデプロイ>テスト>本番へデプロイ。違いは、パイプラインを拡張してテストステージを追加し、前のステージでデプロイしたステージング環境に対して統合テストやUI e2eテストを実行できるようにする点です。これでぐっと実用的になります。テストフェーズの追加は難しくなく、既存パイプラインの編集ページからステップ(ステージ)を1つ追加し、利用しているテストツールに応じたネイティブのテストフレームワーク実行を設定するだけです。
AWS CodePipelineは多用途で、AWSの他サービスやサードパーティとの連携も多岐にわたるため、1つの例に絞るのは難しいのですが、ここでは押さえておきたい便利な機能をいくつか紹介します。
検出オプション(Detection option):パイプラインの起動方法を制御するプロパティです。アーティファクトの保存場所に応じて、たとえばGithubの場合はGithub Webhook、AWS S3バケットに保存されたアーティファクトの場合はAmazon CloudWatch Eventsを使うことが推奨されています。
遷移の無効化/有効化(Disable/Enable transition):遷移はパイプラインのステージ間を結ぶもので、デフォルトで有効になっています。何らかの理由であるステージから次のステージへ自動的に進めたくない場合、「Disable transition」ボタンをクリックすれば無効化でき、パイプラインの連続実行を止められます。再有効化も簡単です。
ステージの追加(Add Stage):パイプラインの構成を編集して新しいステージを追加したり、既存のステージを削除・更新したりするには、パイプラインを「Edit」します。編集ページで、既存アクションに対して直列または並列に新しいアクションを追加できます。これにより、パイプラインを柔軟に拡張できます。
承認アクション(Approval Action):パイプラインのステージを管理し、たとえばデプロイステージに承認者を設けたい場合に使える機能です。承認が下りるまでパイプラインを停止し、承認後に実行を再開します。
CodePipelineが連携可能な、その他のDevOps系AWSサービスは次の通りです。
- AWS CodeCommit
- AWS CodeDeploy
- AWS CodeBuild
まとめ
テストフェーズのないパイプラインも、テストフェーズを経ないリリースも、本来あってはなりません。人的要因を最小化し、自動化と用意されたツールを最大限に活かすこと——これこそがCI/CDを担うDevOpsスペシャリストが目指すべき姿です。そしてこれは、パイプラインを構築するDevOpsスペシラリストだけの話ではなく、開発者・QA・DevOpsチームを含む開発組織全体に当てはまります。品質は全員の責任であると捉え、テストフェーズを「使いやすく・柔軟で・堅牢な」フェーズと位置づけることが、正しいアプローチです。AWS CodePipelineのような適切なサービスを活用すれば、目指す成果に近づけるはずです。
リンクとリソース: