SmartBear Pactflow: コントラクト テストの始め方

この記事では、前回に引き続き、Pact コミュニティ チャネルに寄せられるよくある質問に答えていきます。まだメイン フォーラムに参加していない方は、Slack (http://slack.pact.io/) から参加できます。

前回の記事をご覧になっていない方は、こちらからご覧いただけます。

コントラクト テストの利点を理解したユーザーから寄せられることが多いのは、以下の質問です。


「実際に使ってみたいのですが、どのように始められますか?」

この質問には、どのようにしたらチームの他のメンバーから賛同が得られるか? どこから始めるべきか? どのように成果を測定できるか? どのようにチームを教育できるか? など、さまざまな意味が込められています。ここでは、これらについて順を追って説明します。

どのようにしたらチームの他のメンバーから賛同が得られるか?

ソフトウェア開発はチームプレイであり、新しいツールの導入には、チームの大小にかかわらず、話し合いなどを通じてメンバーの合意を得る必要があります。

最初は賛同してくれないメンバーがいるかもしれません。ほとんどの場合、それはアイデアに価値を見出すことができないからです。ツールの導入が彼らに価値をもたらすことをメンバーに確信してもらう必要があります。

チーム メンバーを説得する前に、以下の質問に答えておく必要があります。ツールを導入する理由はたくさんありますが、Pact やコントラクト テストの場合、以下の質問に答えることで理由を特定できます。

目標や目的がはっきりすると、反対メンバーが推進者に変わることもしばしばです。

解決しなければ問題はあるか?

多くの場合、Pact を導入する理由は、既存のシステムに明示または暗黙の問題があるためです。次のいずれかに該当する場合、コントラクト テストを検討すべき説得力のある理由になります。

  • 既存の E2E テストは管理が困難、時間がかかる、あるいは不安定である
  • ソフトウェアの開発よりもテストの保守に時間がかかる
  • 開発プロセスの後半、あるいは本番環境で定期的に問題が見つかる

効率や品質を改善する方法はあるか?

より良いものを作ろうというモチベーションも、大きな原動力となります。

  • テスト カバレッジを向上したいのか?
  • 1 日に何回も展開したいのか (CD)?
  • システム統合をもっとよく把握したいのか?

別のアプローチを調査する (試す) べきか?

新しいプロジェクトは、大きな問題がなくても、現在のプロセスを再評価する良い機会です。/thoughtworks の Technology Radar のような、サイトやブログの情報に興味を持ち、試してみるのも良いでしょう。

どのように成果を測定できるか?

Pact ツールの導入によってもたらされる価値は測定可能であるため、導入の前と後で基準指標を比較して成果を実証できます。

以下のような指標を使用することができます。

量的指標については、組織のパフォーマンスを評価する DORA の 4 つの主要指標を使用して、コントラクト テストの取り組みを測定し、報告できます。

  • 展開の頻度: リリースの頻度
  • 変更のリード タイム: 変更をコミットしてから本番環境にリリースされるまでにかかる時間
  • 変更のエラー率: すべての変更のうちエラーになる変更の割合
  • 平均復旧時間 (MTTR): 障害からの復旧 (修正やロールバック) にかかる時間

通常、これらの指標は測定が容易であり、有用な情報を提供し、低レベルの詳細を追跡する必要はありません。しかし、次のような改善可能な指標については、より詳細な情報が必要になる場合があります。

  • ビルド期間の短縮
  • 機能サイクル タイムの短縮
  • SDLC のさまざまなステージにおける問題の減少
  • テストの作成と保守に費やした時間

これらの指標が不明な場合は、チーム内で手動でデータを収集し、一定期間にわたる代表的な基準値を得るべきです。

質的指標も価値があります。これらは開発者の満足度に寄与します。

  • 新しいツールに対するチームの感想や意見
  • ツールの導入によるメリットとデメリット
  • ツールの使用状況 (使用頻度や使用範囲など)
  • コミュニティの状況 (活発であるか、協力的かなど)

どこから始めるべきか?

状況はそれぞれ異なるので、簡単な答えはありません。まずは一般的なアドバイスから始め、典型的な例を見てみましょう。

  1. 目標、目的、成果の測定方法を明確にします。
  2. 主な関係者から承認を得て、期間を区切った実験 (スプリントの目標や目的) を提案します。
  3. 実験に参加してくれる賛同者を見つけます。
  4. 小さく始めます。1 つのコンシューマーとプロバイダーのペア、理想的には、最も小さく、最も単純なインタラクションのセットを持つペアを見つます。
  5. 可能であれば、最初のテストは 1 つのチーム内で行います。サービス間のインタラクションについて学ぶことで、チーム間のコラボレーションに備えることができます。
  6. 目的の達成状況を評価し、次の実験を設計し、ステップを繰り返し実行します。

通常、最初の実験は非常に限定的であり、明確な方向性を示すものではありません。また、最初の実験では、手順を間違えることもあるので、そのような場合にも対応できるように準備しておきましょう。ツールとプロセスを検証し、確信が持てたら、ほかのものを削除します。

以下は、よくある状況とその対処法です。

分散モノリスの場合…

分散モノリスは、マイクロサービス アーキテクチャでありながら、各マイクロサービスを一緒にテストして展開する必要があり、各アーキテクチャの最悪の特性を組み合わせたものと言えます。

目標: 結合を排除し、独立したリリースを可能にします (これについては、Sam Newman の素晴らしいビデオをご覧ください)。

アーキテクチャの中で、以下の特性の 1 つ以上を共有し、互いに通信する 2 つのサービスを見つけます。

  1. 小さく、変更が容易である
  2. 理解しやすい結合インターフェイスである
  3. 広範な分散モノリスから切り離すのに最も妥当な候補である
  4. 1 つのチームによって管理されている

理想的な候補を見つけ、すべてのインタラクションを理解するまでテストを繰り返します。そうすることで、この 2 つのコンポーネントを互いに依存することなく自由に展開できるようになります。しかし、システムの残りの部分は、リリースにこのコンポーネントを必要とします。展開プロセスに確信が持てたら、E2E テストの排除や、テストの実行者と管理者 (サービスの所有者) の変更を検討します。

最後に、日常的にリリース期限に追われ、ビルドが常にエラーになるような場合は、上記のルールは無視して、最も重大な問題を見つけて対処します。変更を促すのに危機的状況に勝るものはありません。

モノリスからマイクロサービスに移行する場合…

この場合も、分散モノリスと似ていますが、「サービス」の代わりに、「ドメイン」について考える必要があります (概要ガイドを参考にしてください)。1 つの「コンテキスト境界」を扱うコード領域を見つけ、モノリスから切り離します。理想的には、最も変更の多いもの、あるいは最も価値のあるものから始めると、アーキテクチャから利点が得られやすく、経営陣などの関係者を説得する際に役立ち、好循環を生み出すことができます。コントラクト テストは反復プロセスであり、後続の各インターフェイスは一連のコントラクトによってカバーされるため、このような方法での移行をサポートすることができます。

目標: アーキテクチャを安全に進化させ、コード ベースの遅い部分に阻まれていた価値を引き出せるようにします。

最初に誰が始めるべきか?

最も成功したモデルとして「実践コミュニティ」があります。

実践コミュニティ (Community of Practice、略称 CoP) とは、共通のテーマについての関心や問題、熱意などを共有し、個人とグループ双方の目標を達成するために集まった人々のグループです。通常、実践コミュニティは、その分野の知識や技能を前進させるため、ベスト プラクティスを共有し、新しい知識を生み出すことに重点を置いています。

出典: http://www.communityofpractice.ca/background/what-is-a-community-of-practice/

コミュニティの中には、通常、コミュニティを立ち上げ、コントラクト テストの最初の推進者となる数人のメンバーがいます。彼らは、コントラクト テストのビジネス ケースをまとめ、成功に必要な組織の具体的な変化を特定し、最初の POC を実施します。POC 後の初期導入期間中は、推進者達が継続的に指導して一貫した運用を確実にし、教訓を迅速に慣行に取り入れ、チームが組織内での Pact の使用に関する最新の知識を持つことが重要です。いくつかの導入に成功したら、推進者達は導入における積極的な (実践的な) 役割から退き、代わりに幅広い実践コミュニティの育成に取り組みます。

トレーニング、教育、スケーリング

POC を完了し、前進に必要な価値を実証したら、次の課題は、組織全体にコントラクト テストを拡大することです。

さまざまな方法がありますが、開始点として、コントラクト テストの価値についてチームを教育し、具体的にどのようなメリットがあるのかを示し、そしてそれを効果的に使用する方法についてチームを訓練すると良いでしょう。Pactflow University では、数多くのトレーニングおよび教育用資料を用意しています。問題やコンセプトを説明するデモ パック、チームをトレーニングするためのワークショップ資料、さまざまな言語や技術の多数の事例があります。

以下は、Pact を使ったコントラクト テストの取り組みをガントチャートで表した例です。


PoC からチーム展開までのコントラクト テストの計画例

成功基準の定義、基準値の決定、組織全体で導入を推進するコア チームの形成など、重要な作業のほとんどは POC フェーズで行われます。


Pactflow 製品に関するお問い合わせは、こちら


この資料は、Pactflow の Web サイトで公開されている「How to get started with contract testing」の日本語参考訳です。