この記事はCameron Lairdによるゲスト投稿です。
マイクロサービスは、モジュール化された個々のサービスの集合としてアプリケーションを構築します。アーキテクチャが異なるというだけで、本質的に要件には影響を与えない、つまりテストには影響しません — そうですよね？もっともらしく聞こえる理論ですが、穴があります。
マイクロサービスを扱うテスターであれば、以下のような基本を押さえておく必要があります。
組織的影響
マイクロサービスは、技術的というよりは組織的な面で影響が大きい場合が多いものです。開発グループがマイクロサービス アーキテクチャを採用するとき、テスターは新しい技術やプラクティスを学ぶ必要はありません。
ただし、要件はアーキテクチャに従う可能性が高いので、テスターの検証のために文書化される要件は、顧客から見たアプリケーション全体ではなく、個々のマイクロサービスの要件になります。おそらく、テスターは個々のアプリケーションプログラミングインターフェイス（API）について議論することが増え、ユーザーエクスペリエンスについての議論は減るでしょう。
ですから、マイクロサービス導入におけるテスターの役割の１つは、ユーザーレベルの要件とワークフローが必要だと主張することです。個々のマイクロサービスが「コントラクト」を満たしているかを確認するのは、たしかに健全なことです。それと同時に、常にユーザーから見たアプリケーションやライブラリ全体としての動作とバランスを取る必要があります。
さらに良いのは、マイクロサービスへの移行が始まる前にテスターが関与することです。そうすれば、確実に誰かがエンドユーザーを代弁すること、技術的アーキテクチャと実装の役割に齟齬がないこと、表現されたすべての要件がテスト可能であることを保証できます。
プッシュレフト
一般的に、マイクロサービスの導入によって、文書化される要件はユーザーインタラクションからAPI呼び出しに重点が移ります。後者は自動化が容易です。より正確に言うと、APIの要件は、入力文字列および出力文字列など、コンピューターが容易に処理できる客観的な用語で表現可能です。ユーザーインタラクションはより人間に近いレベルで行われることが多く、ユーザーインターフェイスによって仲介されるため、ウィジェットの選択、ボタンの押下、視覚的な結果などを自動化するのは、少なくともAPIよりもいくらか困難です。
状況によっては、テスト自動化が非常にうまくいき、専任のテストチームを待つ必要がなくなるかもしれません。テストの自動化をシフトレフトし、テストを開発者のルーティン作業にできます。実際、継続的テスト（CT)が目標とするのは、テスターも開発者もテストする必要がなく、テストを実行するべきときになったら自動的にテストが実行されることです。
こういった自動化によってテスターの仕事はなくなるのでしょうか？そうではありません。自動化はテスターの労力を最終製品の品質強化に向けるという、より良い仕事をしてくれるというだけです。ポインターを合わせ、クリックしてエンドユーザーの操作をシミュレーションするという退屈な作業に費やす時間が少なくなれば、テスターは問題を何日あるいは何週間も早く捕捉できるCTの設定をサポートし、ユーザーインタラクションの自動化を促進し、自動化が難しい要件に集中できます。
高度に洗練されたCTワークフローでも、エキスパートによるテストの価値は依然としてあります。違いは、少なくともCTで表現可能な部分について、結果がより成功する可能性が高くなるということです。この成功によってテスターの時間が自由になり、最終製品のより困難な特性をテストできます。
コンテナー化
マイクロサービスはコンテナーに適しています。プログラミングチームがコンテナーになじみがなければ、移行時にテスターが開発チームを助け、経験や知識を共有するのもよいでしょう。
より具体的な面では、コンテナー化はテストをより精密にします。コンテナー化すると、「マイクロサービスをインストールし、適切なウェブサーバーを設定し、$INPUTを提示したときにAPIが$RESULTを返すことを検証する」という要件は「コンテナーを起動し、$INPUTを提示したときにAPIが$RESULTを返すことを検証する」になります。
コンテナー化は、Webサーバーに関連する「私のマシンでは動いていました」という想定外の状況を一掃します。マイクロサービスのランタイムを設定することに無駄に労力を費やすことなく、テストする価値のある再現可能な動作に労力を集中することができます。
APIテスト
APIテストはテストの一種です。既存のツールもAPIに適用可能であり、従ってマイクロサービスにも適用可能であるいっぽうで、特にマイクロサービスをターゲットとした新しいツールも出てきています。
既存のツールのAPI拡張を使用するのを止めて、新しい「ベストオブブリード」のAPIテストツールを探すべきなのでしょうか？マイクロサービス市場は急速に変化しており、妥当であり、かつ一般的にあてはまるアドバイスはあまりありません。私が一番にお勧めするのは、まず既に利用しているツールが提供するAPIテスト機能を最大限に利用してみることです。ツールがあなた固有の状況にとって適切であれば、上々の結果です。そうでなくても、少なくとも他のツールに何を期待するかがよりはっきりとわかるでしょう。
結論
マイクロサービスへの移行は、テスターにとってプラクティスを見直す良い機会です。チームのコンテナー化を支援しましょう。できるだけ多くの開発作業をシフトレフトし、特にマイクロサービス計画がテスト可能であり組織のカルチャーに適合しているか検討する機会を逃さないようにしましょう。そして個々のテストは自動化が可能であり自動化すべきだという前提から出発しましょう。
マイクロサービスはさまざまな部署に多くの課題や想定外の事態をももたらしますが、テスターはマイクロサービスへの移行でリーダーシップを発揮すべきです。
（この記事は、開発元Gurock社の Blog 「What Testers Should Know About Microservices」2020年7月7日の翻訳記事です。）
関連する製品
テスト管理ツール TestRail
テスト管理をシンプルにするWebベーステスト管理ツールのトップブランド
Webベースのテスト管理ツールのトップブランドであるTestRail。テストケースの管理やテスト結果の記録、チームでの情報共有、REST APIを用いた外部ツールとの連携など、テスト活動の本質的ではない作業に時間を取られていませんか？TestRailはシンプルで使いやすいUIを提供し、テストにかかるさまざまな管理コストの削減に貢献します。
API テスト自動化ツール・サービス仮想化ツール SOAtest/Virtualize
APIのテスト自動化とサービス仮想化を1ツールで
API の開発者／利用者に向けてテストの自動化とテスト環境の仮想化の2つの側面から開発を効率化します。SOAtest/Virtualize は、API のテストドライバーを提供し、開発中の API のテストを自動化する機能と、API を利用するアプリケーションが必要とする API を高性能なスタブとして仮想化する機能を同梱して提供します。
