システム間連携のテストでよくあるトラブル
システム開発プロジェクトにおいて、複数のシステムが連携することは珍しくありません。
そのようなプロジェクトでは、外部結合テストやシステムテストの工程において、対向先システム（連携するシステムのこと）のチームとどこまで協力してテストを進めるか、という判断が求められます。
対向先システムとのテストは、基本的には外部結合テスト計画書やシステムテスト計画書という作業計画を立てて、対向先システムの担当者とテストの内容や分担、スケジュール、管理方法等の合意を取ってから進めます。
この時、対向先システムの担当とどこまで、テスト実施内容を詰めておくべきか、迷ったことはないでしょうか。
対向先システムを巻き込んだテストでは、認識のずれが想定外のトラブルを引き起こすことがあります。テストの実施に入ってから「そのテストはこちらが担当するつもりではなかった」「その観点はあちらで確認する前提だった」というような状況が発生します。
例えば、在庫データをやりとりするインターフェースだとすると、自システムとしては在庫が０の場合の挙動を確認したいのですが、対向先システムの担当者が「在庫が０の場合のテストはやるつもりがなかった」、というようなことが起きます。
この認識齟齬は、テストの進捗や品質面に大きな影響を与える可能性があります。
計画段階でのテスト観点のすり合わせは、「当たり前のこと」として軽視されがちですが、実はその「当たり前」が実現できていない現場が多いのも事実です。
テスト計画書のテスト観点は粒度が重要
対向先システムとの外部結合テストの計画書やシステムテストの計画書では、それぞれのテストのテスト観点というものをまとめます。自システムと対向システムでどんなテストを行うのかの認識を合わせるためです。
しかし、テスト観点は書けばよいというものではありません。
粒度が重要です。
例えば、対向先システムとの連携のことをインターフェースと呼びますが、各インターフェースを列挙して、「在庫データ連携を確認する」「注文データの連携を確認する」という粒度でのテスト観点を見かけます。
しかし、その「確認」の範囲や深さをどう解釈するかは、読み手によって変わります。
対向先システムの担当 あるメンバーは「正常系のみ確認すればよい」と判断し、自システム 別の担当 メンバーは「異常系（例：対向先システムでエラーが発生した場合など）も含めてすべてのパターンを確認する」と理解する、といったことが実際に起きてしまいます。
そして、冒頭の例の通り、在庫が０の場合の挙動までは確認するつもりがなかった（なぜなら通常０ということはありえないから）というようなことが起きるのです。
テスト観点の認識ずれが及ぼす影響
こうした解釈のずれは、テスト量の見積もりにも影響し、工数の不足や進捗遅延につながることがあります。
例えば、異常系を実施するためには、対向先システムで無理やりエラーを発生させるような手順が必要になります。
基幹システムなどのかっちりしたシステムの場合、テスト用の環境であっても、システムを停めるためには、書面を作成して、インフラ運用のチームに依頼をしないといけないなど、結構な手間がかかったりします。
これらの作業は、計画段階で見積もりに入っていないわけなので、想定以上に工数がかかり、他のテストができなくなり、進捗にも影響を与えてしまいます。
品質面でも問題が起きる可能性があります。テストのすり抜けが発生するリスクが出てきます。
外部結合テストの実施タイミングになってはじめて「このテスト観点はどちらが担当するのか」という議論が起きると、テストの期間は決まっているので、どうしても、宙に浮いたテスト観点のすべてを実施できない可能性がでてきます。
そしてそのテスト観点は後続工程に先送りされます。その結果、後続工程であるシステムテストやUATに不具合が発見されることになります。
仮にインターフェース以外にもバグが多い、トラブルが多かったりすると、インターフェースバグが見落とされ、本番稼働後に発覚し、ビジネスに影響を与えるということにもなりかねません。
また、不具合の発見が後工程にずれ込むほど、修正工数は大きくなります。
例えば、仕様バグだとすると、該当インターフェースについて、
- 設計書の修正
- 実装の修正
- 単体テスト
- 内部結合テスト
- 外部結合テスト
- システムテスト
と各工程をやり直さないといけないからです。
この工数増のせいで、本来やりたかった改善要望の対応ができなくなってしまうかもしれません。
解決策①：テスト観点の粒度を適切なものにする
前述のような事態を起こさないためには、外部結合テスト計画書やシステムテスト計画書に記載するテスト観点の粒度を適切なものにする必要があります。
外部結合テストでは、インターフェースデータのすべてのデータパターンのテストを目指す、という前提に立つと（各テストで何をするのかは、本来、全体テスト計画書にて定義されます）、テスト観点として、例えば以下のような粒度でまとめていきます。
- 正常系検証
- 項目組み合わせ検証
- 全項目がある
- 必須項目のみ
- 各データ項目のパターン検証
- 数値の場合は０、最小値、最大値、NULL
- ステータスの場合は全ステータス
- ・・・
- 項目組み合わせ検証
- 異常系検証
- 各データ項目の異常系パターン検証
- 数値の場合はマイナス、全角混在
- ・・・
- システム接続異常系検証
- ・・・
- 各データ項目の異常系パターン検証
この粒度感でテスト観点をまとめることにより、自システム、対向先システムそれぞれのテスト仕様書を作成する担当、テストを実施する担当が同じイメージを持てるようになります。
もちろん、各テスト観点には補足説明も必要です。
例えば、「在庫データの０は、業務上はあり得ないが、システム上は許容しているため、テスト対象とする」など、システム的なパターンだけでなく、業務的なパターンにも配慮します。
解決策②：関係者でしっかりすり合わせをする
そしてテスト開始前に、関係者全員で実施内容のすり合わせ打ち合わせを行います。
参加すべきは、
- テスト観点を作成した担当者
- テスト仕様書を作成する担当
- テストを実際に実施する担当
- そして対向先システムの担当者
です。
打ち合わせでは「何を・どこまでやるか」を具体的に確認し合います。
テスト観点を机上で読んで「わかった」とするのではなく、口頭でのやり取りを通じて理解の深さを揃えることが重要です。
特に対向先システムとの間では「こちらが実施する範囲」「対向先が担当する範囲」を明確にすることを意識して調整することが重要です。
対向システム側にテストデータの準備やシステム操作を行ってもらうものもあるので、テスト観点の抜け漏れだけでなく分担の抜け漏れも防ぐことができます。
テスト観点を整理、すり合わせした後にも注意が必要
テスト観点をしっかりと整理し、関係者とすり合わせをした後もまだ注意が必要です。
まず、テスト観点からテストケース（テスト観点を元に実際のテストパターンをまとめたもの）、テスト仕様書（テストの実施手順やテストするポイントをまとめたもの）に落とし込む段階でも認識ずれが発生することを忘れないようにしましょう。
テスト観点を作成した担当者と、それをもとにテストケースやテスト仕様書を作成する担当者が異なる場合、翻訳や解釈の過程でニュアンスが変わることがあります。
テスト観点作成者がテストケースやテスト仕様書をレビューして、認識に相違ないかチェックすると良いでしょう。
次に、不明点が出たときにすぐにコミュニケーションが取れる環境を整えておくことが大切です。
テスト観点やテストケース、テスト仕様書を読んでいる中で疑問が生じた際、自システムの担当者と対向システム側の担当者の間で、気軽に確認できる関係性や仕組みがないと、疑問を抱えたまま作業が進んでしまいます。
チャットツールのグループ設定や定例の短い確認会など、こまめなコミュニケーションで疑問を解消できる仕組みを用意しておくと効果的です。
最後に、テスト観点は一度作れば終わりではないこと、すり合わせも一度やれば終わりではないという点を意識しましょう。
要件変更や仕様変更が発生した際には、その都度、テスト観点の見直しやそれに伴うテストケースや仕様書の見直し、役割分担の確認をする必要があります。
テスト実施期間中に継続的に資料を最新化し、認識を合わせる取り組みが品質の担保につながります。
最後に
対向先システムとのテストの計画段階でのテスト観点のすり合わせは、プロジェクトの品質を左右する重要なプロセスです。
テスト計画書に観点を記載することは必要ですが、それだけでは関係者全員の共通理解には至りません。
テスト観点作成者・仕様書作成者・テスト実施者・対向先システム担当者が一堂に会し、「何を・どこまでやるか」を言葉で確認し合うプロセスが、認識齟齬の防止と観点のすり抜け回避に直結します。
また対面でコミュニケーションをとることで、相互に話しやすい空気ができていきます。
テスト観点からテストケース、テスト仕様書への落とし込みの段階でも認識ずれは起きうるため、関係者が気軽に疑問を解消できるコミュニケーション環境を整えておくことも重要です。
「当たり前のこと」と思われるこのプロセスが、しっかりできているプロジェクトとできていないプロジェクトでは、後続工程の不具合数に明確な差が生まれます。
システム連携のテストにおいては、関係者間の「認識を合わせようとする姿勢と仕組み」こそが、システムの品質を高める土台となるのだと思います。
