Close

自動テストが DevOps の実現で果たす役割

テストを自動化すると、開発チームが構築、テスト、リリースの作業をより迅速かつ確実に進められるようになります。

Krishna Sai の顔写真
Anton Hristov

mabl のプロダクト マネージャー


2000 年代初頭、企業はアジャイル プラクティスを取り入れ始め、顧客からフィードバックを頻繁に受けることを特長とする時間短縮型開発ライフサイクルを採用しました。その後、構築、テスト、構成、デプロイのプロセスを自動化する継続的インテグレーション継続的デリバリーを可能にするツールの採用が促進されました。

ただし、開発、テスト、本番環境へのデリバリーなどの主要な機能は、個別のサイロ内で運営されている別々のチームによって実行されていました。これが非効率性を引き起こして、ソフトウェア開発のライフサイクルを行き詰まらせました。その結果、少人数の部門横断型なチーム (分隊とも呼ばれる) がエンドツーエンドの製品アップデートの継続的デリバリーと品質を担当することを可能にする DevOps、組織理念、プラクティス、ツールにつながりました。

当初、DevOps によって統一されるのは開発と IT 運用のみで、テストは引き続き個別のチームがほぼ手作業で実行していました。これは、クラウド アプリケーションのデリバリーと監視の課題に対処する際に役立ち、完全に自動化された CI/CD パイプラインの作成にもつながりました。ところが、リリース サイクルはそれほど短縮されませんでした。テストがサイロ化していて、多くは時間のかかる手作業のプロセスだったためです。

テストのボトルネックに対応するため、組織は現在、一元化された QA チームから、開発チーム全体に QA を組み込む方式に移行しています。

テスト自動化とは


テスト自動化とは、Web アプリケーションなどのソフトウェア製品を自動的にレビューして検証し、コード スタイル、機能 (ビジネス ロジック)、ユーザー エクスペリエンスに関する所定の品質基準を満たしているかどうかを確認するプラクティスです。

通常、テストのプラクティスには次の段階が含まれます。

  • ユニット テスト: 関数などの個々のコードのユニットを検証して、期待どおりに動作することを確認します。
  • 統合テスト: 意図しない結果が生じることなく、複数のコードが連携して動作することを確認します。
  • エンドツーエンド テスト: アプリケーションがユーザーの期待に応えていることを検証します。
  • 探索的テスト: 非構造化アプローチでアプリケーションの多数の領域をユーザーの観点からレビューして、機能的または視覚的な問題を明らかにします。

これらの各種のテストはよくピラミッドとして描かれます。ピラミッドを登るにつれて、各タイプのテストの数が減り、テストの作成と実行のコストが増加します。

探索的テストのピラミッド

従来、ピラミッド内のテストはすべて手動で実行されていました。これは、時間も費用もかかり、エラーが発生しやすいプロセスでしたが、自動テスト ツールが作成されてから一変します。

今日では、ほぼすべてのユニット テストが完全に自動化されており、ユニット テストの自動化はベスト プラクティスと考えられています。統合テストも大部分が自動化されており、そうでない場合は、手動のエンドツーエンド テストを優先して通常はスキップされます。現在のテスト自動化の取り組みの波は、主にテスト ピラミッドのエンドツーエンド層を自動化することに重点を置いており、統合テストの必要性は低下しています。

自動化ツールは 10 年以上前から存在していますが、多くはコーディング スキルを必要とし、不安定で脆弱なテストにつながることも少なくありません。しかもこうしたテストは、大規模なトラブルシューティングや保守に多額のコストがかかります。結局、多くのチームは独自のカスタム テスト自動化フレームワークを作成するようになり、チームに新規加入するメンバーは覚えなければならないことが多くなってしまうため、オンボーディングが困難になって時間もかかります。また、カスタム フレームワークも結局は変化するテクノロジー スタックに対応するために、独自の保守と改善が必要となります。その結果、ほとんどのエンドツーエンドのテストは手作業のプロセスでした。それもこれからは変わります。

組織が DevOps プラクティスを成熟させるにつれて、DevOps の主なメリット、つまり構築、テスト、リリースの迅速化と信頼性の向上、インシデント対応の合理化、チーム間のコラボレーションとコミュニケーションの向上を実現するには、ライフサイクル全体にわたってテストを自動化することが重要になります。リリース ビルドを QA チームに預けて数日経ってからようやく開発者がフィードバックを受け取り、特定された問題を修正することなどもはや論外です。QA チームは、自動化されたテスト ケースに合わせて DevOps サイクルでの作業を調整し、ほぼ 100% のコード カバレッジを実現する必要があります。環境は標準化し、QA ボックスでのデプロイは自動化する必要があります。テスト前タスク、クリーンアップ、テスト後タスクなどを自動化して、継続的インテグレーション サイクルに合わせる必要があります。

mabl のようなローコード ツールによって、CI/CD パイプラインのあらゆる段階で、信頼性が高く自動化されたエンドツーエンド テストを組み込むことが可能になり、開発ライフサイクルのかなり早い段階で問題を検出できるようになりました。リリースの問題の検出が早期であればあるほど、問題の修正がより速く、コストも低くなることは周知の事実です。

DevOps での自動テスト


具体的には、開発者はユニット テストを作成してコードが期待どおりに動作することを検証するようになり、品質担当者とプロダクト オーナーはエンドツーエンドのユーザー エクスペリエンスを検証する自動 UI テストを作成します。また、品質担当者が編成する探索的テスト セッションでは、チームが手作業でさまざまなアプリケーション領域に課題がないかを調べます。

DevOps のベスト プラクティスは、CI/CD パイプライン内でできるだけ早期に、できるだけ頻繁に自動テストを実行することです。これには、本番環境で自動 UI テストを実行して、ユーザー エクスペリエンスの課題をプロアクティブに監視することが含まれます。今日のアプリケーションは複数の不確定要素を持つ多数のサービスに依存しているため、本番環境でテストを実行して合成トランザクション監視を実行すると、ユーザーが気付く前にサードパーティ サービスの課題を検出できます。

連結された輪のアイコン
関連資料

無料で始める

ツールアイコン
関連資料

テストで DevOps プラクティスを改善する

自動化テストを開始する


万能ソリューションはありませんが、チームのテスト自動化戦略を定義する際に考慮すべき重要な点をいくつか紹介します。

リリースの頻度

リリースの頻度が高いほど、テストの自動化、特にすべてのデプロイで実行すべきエンドツーエンドのテストに投資する必要性は増します。リリース サイクルが頻繁ではないため加速させたい場合は、まずユニット テストのカバレッジを追加し、すべてのビルドに対してクイック健全性チェックを実行する単純な自動 UI スモーク テストを作成します。その後、より自動化されたエンドツーエンド テストの作成に徐々に投資して、リリースのリグレッション チェックにかかる時間を短縮できます。

ツールの可用性

最先端のテスト自動化ツールを導入すると、高品質のソフトウェアを継続的にデリバリーするチームの能力が大幅に向上します。テスト ツールを評価する際には、テスト作成の容易さ、信頼性、保守の必要性、CI/CD スタックとの統合を考慮してください。

同様に重要なのは、特定のツールの学習曲線と必要なスキルを把握することです。ソリューションが使いやすくなればなるほど、チームの成長も早くなります。また、チームで多くの人がソリューションにアクセスしやすくなれば、テスト カバレッジが増加し、高い品質を目指す文化を育むのに役立ちます。テスト ソリューションを評価する効果的な方法の 1 つは、候補リストから適任者を選出して、その人を交えてチーム全体でいくつかのテスト ケース シナリオを自動化することです。

製品の成熟度

チームが取り組んでいる製品に多数の既存顧客と成熟したコードベースが存在する場合は、既にリリース サイクルとテスト プラクティスが確立されている可能性があります。チームが継続的インテグレーションまたは完全な CI/CD に移行するにつれて、パイプラインの自動化の主要部分としてテストの自動化を含めることが重要です。迅速なデリバリーと迅速なフィードバックは、開発全体でテストを早期に自動化しなければ持続できません。

一方、チームが新しい製品を構築している場合は、最初から自動テストのインストゥルメンテーションを行う機会として理想的です。開始早々にユニット テストのカバレッジの目標を設定し、各機能のエンドツーエンドのテスト ケースの定義に集中します。機能がリリースに近づくまで待ってから自動化されたエンドツーエンド テストを追加することをお勧めします。これにより、突然の UI の変更によるテストの失敗を回避できます。

CI/CD 環境とテスト データ

自動テストの作成はそれ自体が課題ですが、テスト データを備えた初期環境がないことが原因で、CI/CD パイプラインの早い段階でテスト自動化を採用できないことがよくあります。したがって、テスト戦略について早期にチーム ディスカッションを行い、必要なテスト インフラストラクチャの構築に取り組むことが重要です。たとえば、開発者はテスト ユーザー アカウントのサポートを実装し、API を介してテスト データを含む環境の読み込みができる必要があります。一時的なテスト環境を早期にプロビジョニングするためのインフラストラクチャを構築することで、リリースのレビューとフィードバック サイクルが大幅に短縮されます。

QA テスト図

自動テストによる QA の役割の変化


DevOps は、品質担当者の役割を戦略的なレベルに引き上げて、キャリア アップにうってつけの機会を提供します。

かつて QA の役割は、テスト ケースの作成、手動テストの実行、開発者への問題の報告など、主にテスト アクティビティの実行に重点を置いていました。一般に、製品開発組織に在籍する自動化担当のエンジニアはわずか数人で、品質担当者の大半は手動テスターでした。その理由は、テスト自動化エンジニアには豊富な技術的知識、ある程度の開発スキル、優れたコミュニケーション スキル、ビジネス要件の確かな理解が求められたためです。これほどのスキル セットを持つ人材は引っ張りだこで、採用が難しいのが常でした。そのため、製品チームは品質保証では手動テスターに大きく依存していたのです。

しかし、DevOps はすべてを変えます。本番環境へのリリースが 1 日に複数件ある場合、ビルドのテストに必要な時間は数日ではなく数分です。ソフトウェア チームに必要なのは、チームのメンバー、特に開発者を率いて指導する資格のある専門家です。この指導者は、ユーザーに役立つことを最優先に、ベスト プラクティスを指導し、エンドツーエンドのテストのメリットを達成できるようにサポートします。

幸いなことに、mabl のようなローコード テスト自動化ツールは、手動テスターや品質アナリストが自動化エンジニアになるのに役立ちます。手動テストに費やす時間が短縮されるにつれて、QA はチームで品質コーチという戦略的役割を果たす時間が長くなり、全員が品質保証プロセスに参加するようにサポートできるようになります。

自動テストによる DevOps 強化の仕組み


自動テストは今や DevOps のベスト プラクティスとみなされています。開発パイプラインの大部分で自動テストを実装することは、最初は難題に思えるかもしれませんが、まずは 1 つのエンドツーエンドのシナリオを自動化して、そのテストをスケジュールに従って実行することから始められます。また、新しいツールのおかげで自動テストがかつてないほど簡単になり、その労力をはるかに超える成果が生まれます。結局のところ、ユーザーが満足することを望まない人などいません。

自動テストを採用することで、次のような DevOps のメリットがもたらされます。

  • 品質を犠牲にせずスピードアップ: 開発者を満足させてユーザーにより多くの価値をより速く提供できる、高い製品ベロシティを獲得できます。
  • チーム コラボレーションの改善: 品質に対する責任の共有により、チーム メンバー間のコラボレーションが向上します。
  • 信頼性: テスト自動化でカバレッジを増やすことで、リリースの信頼性が向上します。本番環境の課題は、当たり前のことではなく珍しい出来事であるべきです。
  • スケール: 自立的に運営されている複数の小規模チーム全体に開発を分散することで、リスクを低減し一貫した品質成果を実現できます。
  • セキュリティ: 自動化されたコンプライアンス ポリシー、きめ細かな制御、構成管理の手法を活用して、セキュリティとコンプライアンスを損なうことなく迅速に行動できます。
  • 顧客満足度の向上: 信頼性の向上とユーザーからのフィードバックへの迅速な対応により、ユーザー満足度が向上して製品紹介が促進されます。

結論


テスト自動化を採用して DevOps のポテンシャルを最大限に引き出すと、最終的にはボトルネックが軽減され、効率が向上します。どちらも、従業員と顧客の満足度に直接影響し、最終的には収益につながります。

Bitbucket Pipelines、または Atlassian Marketplace で入手可能な多くのテスト自動化ツールとリソースのいずれかを使用して、テストの自動化を始めましょう。

Anton Hristov
Anton Hristov

Anton Hristov は mabl のプロダクト マネージャーで、ソフトウェア開発、テスト、リリースに10 年以上携わっています。人々、テクノロジー、デザインが交差する場所で働くことを楽しんでいます。Anton が特に入れ込んでいるのは、データからインサイトを引き出して人々が可能性を最大限に活用できるようにサポートすることです。Anton が開発をサポートする製品には、この取り組みが反映されています。


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

シミュレーション ワークショップ

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up