進化するERP、今こそ押さえたいテストの要点――結合テスト編

1.一連の業務プロセスを検証する結合テスト

結合テストは、ERP内部における一連の業務プロセスが正しく連携して動作するかどうかを検証する工程です。
対象はERP本体だけでなく、以下の事項も含めて検証します。

  • モジュール間(販売、在庫、会計など)のデータ連携
  • 業務フロー上、ERPで実施する全処理
    →実際に行う可能性がある連携・処理を完全に網羅することが鉄則
  • クリーンコア対応のためERP本体の外部に構築した機能
    例:SAPにおけるBTPのように周辺開発した機能や、外部パッケージを利用して切り出した機能など
    →とくに外部システムからERPへのデータ連携がある場合はこの工程で検証する
  • 業務フローで分岐していない細部のバリエーション
    例:全支払方法、支払締めの複数パターン
    →結合テストですべて検証するのが原則、残件は整理して総合テストにて検証

後続工程の総合テストではシステム全体の連携を検証し、UATではユーザーによるシステムの受け入れを実施するため、結合テストの段階で主要な機能間の連携や業務フローが成立していることを確認しておくことが重要です。そのため、テストシナリオは業務フロー単位で作成することが基本です。

結合テストで要点を押さえて検証をしないと、後続の工程で問題が多発してしまいます。

2.結合テストでやりがちなNG集

単体テストのコラムに引き続き、結合テストでやりがちなNG事例を3つ紹介します。皆さんのプロジェクトでも同じ状況に陥っていないでしょうか?

NG事例1:テストのパターン出しが不足している

  • 業務に即したデータバリエーションを考慮していない
    例:月跨ぎの取引や取り消し修正した取引など
  • 処理されるべきデータの検証のみに集中してしまい、処理されてはいけないデータが除外されているかどうかの確認が漏れている
    例:費用配賦の処理で対象とならない費用が配賦されていないか
  • 通常登録のデータ以外の、業務でイレギュラー的に発生するパターンに対する検証が不足している
    例:会計の赤黒伝票のような取り消しデータが混在するパターン

このように、業務パターンやデータのバリエーションが不足している場合、例えば後続の総合テストやUATなどのタイミングで業務パターンの検証の漏れが発覚することとなります。発生頻度の高い正常系のデータは問題なく処理できるがマイナーパターンのデータバリエーションでテストするとエラーになるなど、結合テストで検証できなかった事項や課題が後工程で不具合として表面化し、対応に時間を取られてしまいます。

NG事例2:業務フローをまたいだ検証を考慮していない

NG事例3:モジュール間でのすり合わせをしておらず、データパターンが不十分

  • 一連の業務の流れを同一のシナリオで検証せず、それぞれのチームで担当領域のみを個別に検証している
    例:受注~売掛計上~入金消込の一連の流れについて、販売・会計チーム間で連携した検証をしていない
  • 必要なバリエーションをカバーしていない
    例:支払方法のバリエーションが購買側に連携されておらず、確認すべき支払方法の全種類をテストできていない
  • 課題への対応や仕様変更のために実施した各モジュールの変更が共有されておらず、処理内容が整合しない

これらに当てはまる場合、総合テストやUATで業務フローやモジュールをまたいで検証する際に不具合が多発します。
モジュール間の認識合わせ、障害の内容次第では大幅な見直しが発生し、対応に時間を取られてしまいます。

3.後工程で問題を発生させないために

上記の問題を回避するには、以下の対応が重要です。

  • 業務フローで定義されているバリエーションを網羅する
  • 正常処理されるデータだけでなく、対象外やエラーになるデータも併せて検証する
  • 業務フローやモジュールをまたぐ検証は、それぞれ独自に実施するのではなく、データ内容をすり合わせて、関係するチームが連携し、検証すべきポイントを充足する
  • テスト中の変更事項は管理を徹底して、影響先を見落とさないようにする。PLやPMOなどが主導して管理するのが確実

4.次世代ERP特有の注意点

ERPの機能の一部を外部パッケージを用いて実現している場合は、結合テストで外部パッケージを合流させて検証するかどうか、テスト計画の段階で明確にしておく必要があります。
外部パッケージを結合テストの対象としない場合、外部パッケージは個別に外部パッケージ内に閉じた検証を実施し、ERPとの連携は総合テストで検証することになります。
ただし外部パッケージの機能がERPの機能との関連性が高く、合同でのテストを総合テストまで引き延ばすべきではない場合は、外部パッケージを含めた結合テストを実施できるように調整するべきです。
とくにERPとは異なるベンダーが外部パッケージを開発するケースでは、課題への対応、仕様変更のために実施した変更について結合テストの段階で確認し、検証精度を向上させることが後工程の品質向上に直結します。

結合テストは単なる機能の確認ではなく、総合テストにおけるシステム全体の検証を円滑に進めるための重要な準備工程です。
業務やデータパターンを網羅的に検証し、課題への対応状況を踏まえて計画的に検証を実施できるかどうかが、後続工程の品質と効率を大きく左右します。

BBSでは、SAP FIモジュールの導入をはじめ、テスト工程の改善やプロジェクト管理の強化を支援しています。また、会計システム導入でお悩みの経理部門や情報システム部門の方のご相談も承っております。
本コラムに関し、より詳細な情報をお求めの場合は、ぜひ当社にお問い合わせください。

著者:黒木 仁、川島 靖大