目次


継続的テスト: IBM の見解

可能になってからではなく、必要なときにテストを実行する

Comments

テストにはコストがかかります

ソフトウェアの開発およびデリバリーは、多数の依存関係がビルド時に解決される、複雑でモノリシックなアプリケーションから、依存関係を実行時に解決できる、より分散されたサービス中心のアーキテクチャーへと進化しつつあります。ほとんどのエンタープライズ・アプリケーションは、元々クラウド以前の環境 (「System of Record」(記録のためのシステム) とも呼ばれる) 向けに設計された既存のアプリケーションと、クラウド内で開発された新しい「Systems of Engagement (人と関わり合うシステム)」アプリケーションを組み合わせたものになっています。このようなアプリケーションのアーキテクチャーは依存関係の多さから複雑になりがちです。また、API を使用して既存の System of Record と新しい Systems of Engagement とを橋渡しするため、API 管理テクノロジーとクラウド統合テクノロジーを活用して統合を可能にすると同時に、組織のセキュリティー要件に対処します。これらのアプリケーションのワークロードは、複数の環境にわたって実行されます。具体的には、オンプレミス、プライベート・クラウド、パブリック・クラウド、そしてこれらの環境を組み合わせた、ハイブリッド・クラウドと呼ばれるアーキテクチャーです。

継続的テストでは、プロジェクト・チームはテストが実行可能になってからではなく、必要なときにテストを実行できます。

現在、クラウド対応アプリケーションとクラウド・ネイティブ・アプリケーションの両方で、ハイブリッド・クラウド・アーキテクチャーが標準になりつつあります。ハイブリッド・クラウドはデプロイメントに柔軟性をもたらし、組織が適切なプラットフォームを選んでワークロードを実行することを可能にします (このリンク先の「DevOps for hybrid cloud:An IBM point of view」(2016 年 2 月) を参照)。IDC では、2017 年までに IT 関連企業の 80% がハイブリッド・クラウド・アーキテクチャーに取り組むことになるだろうと予測しています (「IDC FutureScape: Worldwide Cloud 2016 Predictions — Mastering the Raw Material of Digital Transformation」(2015 年 11 月) を参照)。

IBM はその見解として、テストを改善することで、企業は多大な経費を削減でき、競争上の優位性を獲得できると考えています。テストは、プロセス改善の機が熟した領域です。2018 年までに、品質保証にかかる平均経費は IT 総予算の 40% もの割合を占めることが予測されているからです。この経費の問題をさらに悪化させるのは、多数の組織ではテスト予算の 3 分の 1 を超える額をテスト環境に費やしているという事実です (このリンク先の「World Quality Report 2015-16」(Capgemini、Sogeti、HP) を参照)。

ADT が実施した最近の調査から、本番環境へのデプロイが遅れる理由として第 1 に挙げられるのはテストであることが明らかになっています (このリンク先の「ADT Study Whitepaper: Organizations Increasingly Look to Continuous Deployment to Recover」を参照)。アナリティクスとテストに関するインサイトを基に、IBM はテストおよびテスト関連のデプロイメント業務の最適化に注力しています。その目的は、イノベーションに利用できるリソースをより多く確保するためです。

なぜ継続的テストを目指すのか

企業が高品質の革新的ソリューションを短時間で市場に送り出すためには、デリバリー・チーム全体でフィードバックを促し、すべてのフィードバックを活用する必要があります。これらのフィードバックは開発チームと運用チームの間で行われるだけでなく、デリバリー・エコシステム全体 (ビジネス・アナリスト、開発者、設計者、デザイナー、アーキテクト、テスター、リリース管理者、サード・パーティー・ベンダーなど) にわたって繰り広げられなければなりません。さらに、フィードバック・チャネルにはビジネス利害関係者も含める必要があります。ビジネス利害関係者が、定義されたプロセスと取引が期待どおりに機能することを検証するようテスターに依頼し、依頼されたテスターがテスト作業のコストと影響をどのようにして最小限にするのかを模索するという構図です。継続的テストによってソリューションの品質に関するフィードバックを即時に提供できるようになれば、チーム全体に信頼が生まれます。ビジネス利害関係者にとっては、継続的テストにより、デリバリーが信頼できるものであり、ビジネスに影響するリスクが最小限であるという確信が強くなります。プロジェクト・デリバリー・チームにとっては、継続的テストの手法およびツールによってテストが与える影響が最小限になります。その結果、プロジェクトのコストが削減されるだけでなく、ソリューションを提供するまでの時間が短縮されます。そして最も重要なことに、高品質で信頼性の高いソリューションを提供できるようになります。

品質とスピードの必要性

ビジネス利害関係者はプロジェクト・チームに、新しいアプリケーションの提供、統合、マイグレーション、および変更に、できる限り短時間で対応するよう依頼します。すると、プロジェクト・チームはテスターに以下のことを検証するよう依頼します。

  • 技術環境が要件どおりに機能すること
  • ビジネス・プロセスと取引が期待どおりに実行されること
  • 期待される使用状況に応じてソリューションがスケーリングすること
  • アプリケーションがセキュアであり、ユーザー・データが保護されること

関与する業界やテクノロジーが何であれ、スピードと品質との間では慎重なバランスを取らなければなりません。クラウド・テクノロジーが広く受け入れられるようになったことから、ソフトウェア・チームは作業の効率化を図るために、かつてないほど多くのツールを使えるようになっています。けれども、ソフトウェア開発者やシステム開発者がミスを犯さないよう最善の努力を払ったとしても、ヒューマン・エラーは避けられません。それが、テストを行う理由なのです。テストを実行しなければ、わずかな回数でもテストを実行する場合に比べ、リスクが顕著に大きくなります。

アジャイルおよび DevOps 手法の導入が増えつつあるなか、開発ライフサイクルを繰り返すたびに手作業でテストを再実行するというパターンは続けられなくなっています。十分な時間がないだけでなく、手作業でリグレッション・テストを実行するために担当者を増員すると、収益が減ることになるためです。さらに重要な点として、開発者へのフィードバックに時間がかかると、生産性が極度に低下する点があります。よりペースが速くなった開発ライフサイクルに遅れを取らないためには、テストの有効性が非常に重要な特性となります。テストの有効性を最適化するには、最大数の問題を検出するテストを最小限の数に絞って実行します。より従来型の開発ライフサイクル (この場合、すべてのテストが 1 つのフェーズ内で実行されます) に取り組むチームでさえも、欠陥の修正、既存の機能に対する変更、さらに新機能のすべてがバンドルされた新しいビルドを入手するたびに、スケジュールに遅れることなくリグレッション・テストを完了することはできないという結論に至っています。以下の図を見るとわかるように、開発ライフサイクルが数回繰り返されるだけで、新機能の数が増え、したがってテストの数も大幅に増えていきます。

4 回の繰り返しを示す図
4 回の繰り返しを示す図

必要なリグレッション・テストをスケジュールに遅れずに完了する唯一の方法は、適切なテスト・セットを自動化することです。スピードと品質のバランスを取るために、成熟した DevOps チームではテスト自動化と、手作業による予備的テストの両方を、継続的パターン内で実行しています。

正しいテスト・セットを見つける

すべてのテストを自動化しようとしても、それは不可能であり、その試みにかかるコストは、最終的に利益を上回ってしまいます。かなり複雑なアプリケーションでは、システム内で考えられる限りのすべてのパスをテストすることはできません。アプリケーション内にループが 1 つでもあると、潜在的パスの数は無限になってしまうからです。テスト・データ置換を取り入れたとしても、すべてのものをテストしようとするのは現実的でないことに気付くまでに、そう長い時間はかからないはずです。鍵となるのは、テストのうち、最も重要なサブセットを見極めることです。それには、以下の基準を使用します。

  • 問題が見つかることが多い
  • リグレッションが確認された
  • 顧客から苦情があった
  • 障害が発生すると、極めて大きな、あるいは致命的な影響があることがわかっている

新しいコード変更の影響分析は、実行すべきリグレッション・テストを見極める上で重要な側面です。けれども、有効な変更セットの入力がなければ、コード変更のデータと分析によって誤った結果が導かれる可能性があります。この、自動化するのに適したテストはどれであるかという分析には、ビジネス担当者から開発、テスト、運用、サポート担当者に至るまで、チーム全体が関与しなければなりません。それぞれの役割が、何が可能で何が問題になるかについて異なる視点をもたらすため、全員の参加が重要となるのです。

自動化を適用できるテストの分野には、以下の例が挙げられます。

  • データ駆動型テスト。このテストのデータ・セットは複雑であり、重要な側面をカバーします。
  • 正しい結果が得られることを確認する、ビジネス・ロジック検証。
  • 開発者とテスターが完全にアクセスできない可能性があるサード・パーティー・システムとの統合テスト。
  • 低負荷パフォーマンス・テスト。正式な負荷テストを実施するまでにまだ十分な時間的余裕がある段階で、ビルドごとにストレス、負荷、ボリューム、またはメモリー・リークに関する小規模なチェックを実行し、ビルド間でのパフォーマンスの低下を早期に識別します。
  • ユーザーがインストールするソフトウェアのインストールおよびアップグレードのテスト。消費者向けソフトウェアの場合、多数のプラットフォームとオペレーティング・システムをまたいでインストールおよびアップグレードをテストする必要があります。
  • 特に、財務情報や個人情報をリスクにさらす場合に、セキュリティー上の脆弱性のスキャン。

自動化の実装には、以下の主要な例をはじめ、あらゆる形態と形式があります。

  • 単体テスト
  • ユーザー・インターフェース (UI) 層での機能テスト
  • API を使用した機能テスト
  • パフォーマンス・テスト (UI または API を使用)
  • セキュリティー・テスト

さらに、手作業で実施すると極めて有益なテストもあります。テスト自動化と並行して、これらのテストを継続的に行ってください。

  • 探索的テスト。スクリプト化されていないテストで、最終的な結果を規定せずに、テスターがシステムのさまざまな側面を分析します。このようなテストは、自動化テストによってまだカバーされていない、欠陥を隠しているシナリオを新たに見つける上で役立ちます。
  • ユーザビリティー・テスト。エンド・ユーザーに、システムの特定の側面をテストしてもらい、操作しながら口頭でフィードバックしてもらいます。チームはこれにより、ユーザーが対象のシステムを操作しているときに、どう思っているのかをより深く理解できるようになります。

テストをよりスマートに「シフト・レフト」する

これまでに、「がむしゃらにテストするのではなく、スマートにテストしろ!」と言われたことはありますか?テストや開発の管理者はチームに頻繁にこのメッセージを送っていますが、残念ながら、よりスマートにテストする方法について具体的に指示することはしません。チームは現在抱えているテストをスケジュールに遅れずに完了させようと多忙を極めているため、どうすればよいのかを自分たちで見つけ出す時間はありません。

よりスマートにテストするための重要な側面は、デリバリー・ライフサイクルの早い段階へとテストを「シフト・レスト」して、より頻繁にテストを行うことです。このようにすれば、チームは最もリスクの高い要素を早期のうちにテストできるだけでなく、その後もそれらのテストを継続的に再利用できます。また、ライフサイクルの終わりに近づいた頃に見つかった問題は修正に伴うコストが大きくなるので、そのような問題が少なくなるよう、早いうちからコードの品質に関するフィードバックを直接、繰り返し開発チームに提供するほうが、よりスマートな手法です。

例えば、ライブ・アプリケーションの品質が低く、評判が悪い場合を想像してみてください。以下のシナリオで、プロジェクト・チームがテスト能力を高めて、可能なときに限らず、必要とあればテスト自動化を行えるようにするにはどうするのかを説明します。

まず、(ビジネス、開発、テスト、運用などに関する) すべての利害関係者が協力して、アプリケーションを本番環境にデプロイした後に見つかった欠陥の根本原因を把握します。チームは欠陥データと分析を基に、最も影響の大きい欠陥の原因が以下の 2 つの領域にあることを発見しました。

  • 他のシステムとの統合
  • 応答時間の遅れ

チームは、本番環境にデプロイする段階まで待つのではなく、開発プロセスの早期にリスクの高い統合に関してテストを行う必要があると判断しました。そうすれば、利害関係者が協力して、全員が合意したインターフェースとデータ定義をシステム・アーキテクチャーの一部として取り込むことができるためです。

また、致命的なパフォーマンス問題を早期のうちに識別して修正できるよう、ビルドが利用可能になると同時に低負荷パフォーマンス・テストを行うことも決めました。パフォーマンス・テストの結果をビルドごとに追跡すれば、パフォーマンスに低下があるかどうかがすぐにわかります。

全員が合意したインターフェースに基づき、開発者とテスターが協力して、リスクの高いインターフェースごとに仮想サービス (スタブ) を作成します。インターフェース・スタブによって他のシステムを模倣すれば、開発プロセスの初期段階 (コードが作成されてビルドされた時点) のうちに、開発者とテスターがリスクの高い領域をテストできるようになります。

チームはさらに、多数の機能統合テスト、そして主要な応答時間テストを自動化します。本番での大きな欠陥の多くは、これらが原因となっていたからです。

これで、新しいビルドが作成される際は常に、ビルド・プロセスが成功すると、以下に示すように自動化されたアクティビティーがトリガーされるようになります。

アクティビティーのフローを示す図
アクティビティーのフローを示す図
  1. 新しいアプリケーション・ビルドは、自動的にプロビジョニングされるクラウド・ベースの開発テスト環境にインストールされます。
  2. 欠落している従属サービスのスタブが起動されます。
  3. 自動化された統合テスト・スイートがトリガーされます。テスト・スイートが実行され、続いて低負荷パフォーマンス・テストが実行されます。
  4. テスト結果がキャプチャーされて、チーム全体でフィードバックを利用できるようになります。チームはテスト結果を分析し、特にパフォーマンスを重点としてリグレッションの有無を確認します。
  5. 統合テストおよびパフォーマンス・テストに合格した場合、開発テスト環境内のアプリケーションのスナップショットがシステム・テスト環境にデプロイされます。
  6. ユーザー・インターフェース・ベースの自動化テスト・スイートがトリガーされ、システム・テスト環境内で実行されます。
  7. この場合も、テスト結果がキャプチャーされ、フィードバックが提供され、欠陥が解決されてから、新しいビルドが作成されます。

従属システムが利用可能になると、チームは前と同じ自動化された統合テストとパフォーマンス・テストを、今度は実際のシステムに対して実行します。これにより、アプリケーションが引き続き期待どおり動作することを確認します。

このシナリオは、あらゆる欠陥パターンに適用できます。このシナリオを適用することで、チーム全体が協力してライフサイクルの早期にテストを開始できるようになるだけでなく、最も重要なテストを最初に自動化し、それらのテストを繰り返し実行することも可能になります。このようにすることで、最もリスクが高いアプリケーションの部分を確実にテストの適用範囲にできるようになるのです。

継続的テストを実現する

継続的テストの組織文化を築き上げるために必要なのは、人、プラクティス、ツール、時間です。以下の図に、継続的テスト・プロセスを確立する際の一般なプラクティスを示します。

継続的テストのプラクティスを示す図
継続的テストのプラクティスを示す図

従来のテスト手法を適用する場合、テスターと開発者の間で最初の意志疎通経路となるのは、欠陥です。テスターが「バグを見つけた!」と判断すると、開発者はコードに問題があることに同意または反対します。多くの場合、欠陥はコード自体の問題ではなく、要件や設計の問題であったり、さらにはテストの問題であったりすることさえあります。場合によっては、問題の原因はアプリケーションの外部にあります。例えば、テスト環境、テスト・データ、テスト・スクリプト自体、あるいはそれらの組み合わせが問題を引き起こしていることもあります。ソフトウェア開発ライフサイクル内では例外なく、コラボレーティブな環境を作って、欠陥をログに記録して追跡することが不可欠ですが、適切なプラクティス一式を導入するとなると、欠陥の追跡は取り組み全体のほんの一部でしかありません。

通常、テスト・チームが次に導入するプラクティスのうちの 1 つは、テスト管理です。テスト作業の計画、必要なテストの特定、手動テストの作成、既存のテストの収集、テストの実行、テストの進捗状況の追跡およびレポートは、すべてテスト管理に含まれます。テスト管理のプラクティスは、チームと経営陣の両方にとって、テストが合格したか、失敗したか、あるいはブロックされているかを簡単に理解するのに役立ちます。さらに、以下の質問にも答えを出すことになります。テスト作業がスケジュール通りに進んでいるか、遅れているか、あるいは予定よりも早く進んでいるか?

通常、次にくるのはテスト自動化のプラクティスです。つまり、チームがテストを手作業で実行するのでは非効率的、非効果的、そして多くの場合は明らかに不可能であると理解した時点で、テスト自動化が検討されます。堅牢で保守しやすいテスト自動化フレームワークは、ソフトウェア開発プロジェクト自体と同じように取り組まなければ作成するのが困難です。自動化フレームワークを作成するには、共通のビジョン、要件、アーキテクチャー、設計、さらに場合によってはコーディングが必要になり、最終的には自動化が意図されたように機能することを検証しなければなりません。これらの側面を無視して作成されたテスト自動化フレームワークは、不安定で壊れやすく、保守するのが困難で、リファクタリングにコストがかかるものになりやすく、放棄されることも珍しくありません。

テスト自動化と併せ、テスト・アナリティクスおよびインサイトのプラクティスも、どのテストをいつ実行すべきか、なぜテストを実行しているのか、という質問の答えを出すようになってきています。コード変更の影響分析は、特に開発者たちがコードの変更セットに厳密に従い、一貫性を保っていなければ、難しいタスクになりがちです。前回のビルドから何が変更されたのかを把握していなければ、実行すべき適切なテスト・セットを選択することはできません。コード変更の影響分析を行わずに、すべてを包括的にテスト (再テスト) するという対処は心をそそるものの、コストのかかる答えです。

テスト環境の作成も、テストの重要な側面の 1 つです。テスト環境のプロビジョニングを自動化すると、非常に大きな見返りがあります。まず、新しいビルドのテストを開始するまでには数時間、数日、あるいは数週間かかることもありますが、テスト環境の作成と構成を自動化すれば、その時間を数分にまで短縮できます。この自動化は、テスト環境の問題、つまり従属ソフトウェアの不適切なインストールや、その他の手作業によるプロセスによってもたらされた問題による、誤ったエラーの数も減らします。IBM DevOps の筋書きでは、テスト自動化は自動化デプロイメントと密接に関連しています。

テスト実行とテスト環境の自動化と併せて、サービスを仮想化 (つまり、スタブを作成) すると、テスト作業の有効性が大幅に高くなります。既知の合意したインターフェースに基づいて仮想サービスを作成することで、その従属システムがまだ利用できないとしても、開発者とテスターは同じインターフェースに対してコードを作成し、テストできるようになります。これらの既知のインターフェースに対してテストを実行できれば、遥かに早い段階でテストを始められるようになり、したがってビルドのたびに頻繁にテストを実行することができます。サービス仮想化は、ライブ・システムを使用して簡単にテストできないようなシナリオのテストも可能にします。例えば、以下のシナリオです。

  • 例外とエラー
  • 欠落データ
  • 遅延応答時間
  • 大量のデータまたはユーザー

簡単にテストできるシステムの部分をビルドしてテストするのではなく、サービス仮想化をテストの取り組み全体に統合することで、チームはシステムの最もリスクが高い部分を最初にビルドして効率的にテストすることが可能になります。そして、それらのリスクの高いシステムの部分に対するテストを自動化し、ビルドのたびに自動化テストを実行することで、それらの部分のテスト・カバレッジを改良できるため、新しいビルドが作成されたときに迅速にリグレッションを特定できるようになります。

サービス仮想化の典型的なシナリオは、モバイルと Web の開発チームがクラウド・アプリケーションに取り組み、メインフレーム・チームがオンプレミスで作業する場合でしょう。サービス仮想化により、IBM はこれらのハイブリッド・クラウドのシナリオに見られる環境への依存関係を切り離しています。環境の依存関係がないため、それぞれのチームが独自のスピードでビルドとテストを行い、独自の組織文化に適切な DevOps 手法を採用します。

テストの有効性を高めるもう 1 つの側面は、適切なテスト・データ・セットを使用することです。できるだけ本番環境に即したテスト・データを使用すれば、より多くのシナリオで、より効果的なテスト・カバレッジが実現します。本番環境からデータを抽出し、そのデータをマスキングしてセキュリティーを確保することで、実際的なテスト・データのセットを使用できるようになります。例外やエラーをテストするのは難しいことですが、このような有効性に優れたテスト・データのセットがあれば、チームが例外やエラーの状態を作り出すこともできます。

このように、効果的なテストのプラクティス一式により、テスターだけでなく、チーム全体が協力して品質を向上させて、新しい機能を提供するまでの所要時間を短縮できるようになります。従来のテスト環境に通常必要となる高額すぎる投資を行わなくても、これらのプラクティスを採用すれば、依存関係やボトルネックを取り除き、ライフサイクルの早期から継続的テストを行うことが可能になります。

まとめ

ハイブリッド・クラウド戦略を導入している企業にとって、「スピードを伴う高品質」という願望は、これまでになく重要な意味を持つようになってきました。ハイブリッド・クラウド戦略では、一部のプロジェクトをクラウド内で開発し、他のプロジェクトをオンプレミスで開発して、これらのアプリケーションがデプロイ後にシームレスに連動するようにする必要があります。

私たちはテスト自動化とサービス仮想化の組み合わせを「継続的テスト」と呼んでいます。テストを開始するタイミングをライフサイクルの早期に繰り上げ (つまり、テストを「シフト・レフト」する) 、より頻繁に実行することによって、チームはビルド、デプロイ、テスト、フィードバックの収集のすべてを継続的に行えるようになります。ライフサイクルの終わりに近づいた頃に見つかった問題は修正に伴うコストが大きくなるので、そのような問題が少なくなるよう、コードの品質に関するフィードバックを早いうちから繰り返し開発チームに直接提供するほうが、よりスマートな手法です。さらに、本番環境内で問題が見つかったとしたら、問題を解決するのに極めて大きなコストがかかるだけではなく、企業の評判を傷付け、長期間にわたってカスタマー・ロイヤルティーに悪影響を及ぼす恐れもあります。タイムリーにテストを実行してフィードバックを入手できなければ、企業は真のスピードを伴う高品質を実現することはできないのです。

その他のコントリビューター:

  • Glyn Rhodes, Offering Management Lead – Continuous Test
  • James Hunter, Offering Lead – Industry Solutions and SAP
  • Roger LeBlanc, Sr. Offering Manager – Performance Testing and UI Automation
  • Matt Tarnawsky, Offering Manager – API Testing and Service Virtualization

ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1038021
ArticleTitle=継続的テスト: IBM の見解
publish-date=09292016