GENZ, Inc.

作る側と検証側を分ける。 iPaaSのSaaS連携フローを第三者が検証

自ら作った連携フローを自ら検証する体制では、確認した範囲とそうでない範囲を区別できません。GENZは第三者の視点でテスト設計から報告書作成まで担います。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

SaaS連携フローでよくある不具合

iPaaSの連携フローは、マッピング定義や連携先SaaSの仕様が変わるたびに不具合が起きやすく、本番相当のデータ量でしか表面化しないものもあります。SaaS連携フローで発生頻度の高い不具合を取り上げます。

項目追加後、マッピング未設定の値が空欄で送信される

連携先に項目を追加した際、マッピング定義へ反映されないと転送値が空欄になります。受け側の基幹システムでは必須項目の欠落としてエラーになります。

マッピング漏れ

呼び出し上限の超過でジョブが中断し、未連携のレコードが残る

連携先SaaSのAPIには単位時間あたりの呼び出し上限があり、件数の多いバッチ連携で超過するとジョブが中断し、未処理のレコードが残ります。

API上限超過

リトライの重複実行で連携先に同一レコードが二重登録される

タイムアウト時のリトライ設定が連携先の冪等性と合っていないと、同一レコードが二重登録されます。請求や在庫の数値が重複計上されます。

データの二重登録

文字コードと日付形式の違いで連携先に文字化けと日付のずれが出る

連携元と連携先で文字コードや日付形式が異なると、変換設定の不足により文字化けや日付の差異が発生します。氏名や備考が読めない状態で登録されます。

形式変換の不一致

エラー通知の設定漏れにより、連携の停止が翌営業日まで表面化しない

エラー検知時の通知設定がされていないと、ジョブの異常終了が担当者へ届きません。停止の発見が翌営業日まで遅れ、未連携のレコードが蓄積します。

エラー通知の未設定
02 RISK

残存した不具合により生じる問題

連携フローに残った不具合は、基幹システムへ取り込まれた時点で請求・在庫・会計の数値へ反映されます。発見が遅れるほど訂正の対象期間が広がります。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

iPaaSの連携設定は画面上で完結するため、設計書と実装の不整合は実行前のレビューでしか検出できません。実行に移す前に、設計書類どうしを突き合わせておさえるべき観点を整理しました。

照合を省くと、APIに存在しない項目が実装完了後に判明し、要件定義へ戻る手戻りが発生します。

連携要件定義書とAPI定義の項目対応を照合する

連携要件定義書の項目が連携先SaaSのAPI定義に存在するかを項目単位で照合します。API定義にない項目は、個別実装とするか削減するかを判断し、結果を項目対応表へ記録します。

確認する資料
  • 連携要件定義書
  • API定義
  • 項目対応表
桁数・型の不一致を見落とすと、基幹システムの取り込み処理でエラーが起き、請求や在庫の数値へ不整合が反映されてしまいます。

マッピング定義とDB設計書の桁数・型・必須条件を照合する

マッピング定義の各フィールドを、受け側のDB設計書が定める桁数・型・必須条件と照合します。変換ルールの設定ミスは画面上では判別できず、桁あふれや型の不一致は取り込み時のエラーになります。

確認する資料
  • マッピング定義
  • DB設計書
  • 変換ルール一覧
設計にない例外パターンは検知も再送もされないため、データの欠落がリリース後まで表面化しません。

エラーハンドリング設計と例外処理とエラー発生パターンの一覧を照合する

エラーハンドリング設計に対し、業務部門から聞き取った例外処理とエラー発生パターンの一覧を突き合わせます。一覧にあって設計にないパターンは、検知されないまま再送もされない状態になります。

確認する資料
  • エラーハンドリング設計
  • 例外処理一覧
  • エラー発生パターン一覧
実行順の不整合を見落とすと、古いデータが転送され、締め後の帳票で数値が食い違います。

ジョブのスケジュール設定と業務の締め時刻・処理の前後関係を照合する

連携ジョブの起動時刻と実行間隔が、月次締めなど業務の締め時刻と前後のジョブの依存関係に矛盾なく収まるかを照合します。先行ジョブが未完了のまま後続が起動すると、古いデータが転送されます。

確認する資料
  • ジョブスケジュール設定
  • 業務カレンダー
  • ジョブ依存関係図
過剰な権限が本番へ残ると、誤操作によるデータ更新や、システム監査での指摘につながります。

コネクタの権限設定とアクセス権限の運用ルールを照合する

各コネクタに付与した権限が、アクセス権限の運用ルールで定める範囲を超えていないかを照合します。開発時の確認用に広く付与した権限が、そのまま本番へ持ち越される例があります。

確認する資料
  • コネクタ権限設定
  • アクセス権限運用ルール
  • 権限付与記録
  • アカウント一覧
04 TEST DESIGN

動的テストの設計・実行のポイント

連携基盤の動的テストは、コネクタ単位から業務シナリオの通しまで段階に分け、確認する対象と判定基準を定めます。

STEP 01 コネクタ単位の確認標準コネクタと個別実装で確認範囲を分けます
どう確かめるか

ユニットテスト:コネクタと変換ロジックの入出力を境界値と同値分割で確認する

コネクタと変換ロジックを単位として、入力データに対する出力がマッピング定義どおりかを確認します。文字数・件数・日付形式の境界値と、同値分割で区切った代表値を用います。

  • 01マッピング定義と入出力の対応を確認します
  • 02境界値と同値分割で代表データを選びます
  • 03変換ロジックの例外処理を検証します
OUTPUTコネクタの入出力結果
STEP 02 SaaS間の連携確認API応答のパターンを網羅します
どう確かめるか

統合テスト:SaaS間のデータ連携をAPIの応答パターン別に確認する

SaaS間のデータ連携を対象に、APIの応答パターン別の処理結果を確認します。正常応答・タイムアウト・呼び出し上限の超過を意図的に発生させ、再送処理と通知の動作まで確認します。

  • 01正常応答時のデータ受け渡しを確認します
  • 02タイムアウトと上限超過を発生させて検証します
  • 03エラー時の再送と通知の動作を確認します
OUTPUTAPI応答別の連携結果
STEP 03 業務シナリオの通し確認本番相当のデータ量で実行します
どう確かめるか

システムテスト:業務シナリオに沿って連携フロー全体の処理結果を確認する

取得から変換、送信までの連携フロー全体を業務シナリオに沿って実行します。月次締めや年次バッチの周期イベントをシナリオとして扱い、本番相当のデータ量で表面化する不具合を検出します。

  • 01取得・変換・送信の一連の処理を実行します
  • 02月次締めや年次バッチのシナリオを確認します
  • 03本番相当のデータ量で不具合を検出します
OUTPUT業務シナリオの処理結果
STEP 04 受け入れと回帰の確認既存フローの劣化を検出します
どう確かめるか

受け入れと回帰の確認:業務部門の基準で判定し、既存フローの劣化を捉える

受け入れでは業務部門の運用担当が業務シナリオ単位で判定し、結果を記録します。回帰テストの範囲は、変更したマッピング定義を参照する連携フローから特定し、判定の根拠を残します。

  • 01業務シナリオ単位の判定結果を記録します
  • 02変更の影響範囲から回帰テスト対象を特定します
  • 03既存フローの処理結果に差異がないか確認します
OUTPUT判定記録と回帰テスト範囲
05 RATIONALE

GENZが代行するiPaaS連携のテストの種類

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • ユニットテストと統合テストの結果を第三者の視点で検証
  • 回帰テストの影響範囲を一覧化し項目書を整備
  • リリース判断に使える検証範囲の報告書を作成
  • 業務部門が判定しやすい受け入れテストの材料を用意
06 SERVICE

連携仕様の分析からリリース判断まで伴走する支援

連携基盤の変更に対する検証範囲は、コネクタ単位・連携フロー単位・業務シナリオ単位の階層で切り分けられます。GENZは構築したベンダーとは独立した立場で、テスト設計から実行、報告まで伴走します。

SVC 01

API定義とマッピング定義からテスト設計

API定義とマッピング定義を起点に設定の妥当性をレビューし、テスト項目書を導出します。設計上の不整合を実行前に検出します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

コネクタから業務シナリオまで検証します

標準コネクタの設定確認から、連携フローをまたぐ統合テスト、業務シナリオまでを段階に分けて検証し、何をどこで確認するかを整理します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

今のツールと運用に合わせて進めます

お使いのテスト管理ツールや不具合票の運用、リリース判断の基準に合わせて作業します。品質保証が専任でも兼務でも進められます。

計画から報告までの流れを示す無文字の図解。
SVC 04

判断に使える形で報告します

確認した範囲と確認していない範囲を区別した報告書を作成します。実施記録と判定の根拠は、システム監査で提出できる形式で保全します。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から納品までの流れ

ご相談から報告書の納品まで、各段階で検証範囲と優先順位をご担当者様と合意しながら進めます。

ヒアリングと検証範囲の確認

連携フローの構成とマッピング定義を伺い、検証が必要な範囲を整理します。

テスト設計と見積もりのご提出

連携フロー単位でテスト項目を設計し、内訳のわかる見積もりを提出します。

テストの実施と進捗の共有

テストを実施し、不具合票と実施状況を週次でご報告します。

報告書の納品と再確認

検証した範囲と結果を記した報告書を納品し、確認していない範囲も明記します。

無料相談を受け付けています

iPaaS連携の検証範囲と優先順位をGENZへご相談ください

ご相談では、対象の連携フローに応じたテスト範囲の切り方と優先順位、必要工数の考え方、関連テストの要否をお示しします。検証範囲の見通しが立った状態で、社内の合意形成へ進めます。