システム導入支援(受入テスト支援・移行支援)
結合テストは、ERP内部における一連の業務プロセスが正しく連携して動作するかどうかを検証する工程です。
対象はERP本体だけでなく、以下の事項も含めて検証します。
後続工程の総合テストではシステム全体の連携を検証し、UATではユーザーによるシステムの受け入れを実施するため、結合テストの段階で主要な機能間の連携や業務フローが成立していることを確認しておくことが重要です。そのため、テストシナリオは業務フロー単位で作成することが基本です。
結合テストで要点を押さえて検証をしないと、後続の工程で問題が多発してしまいます。
単体テストのコラムに引き続き、結合テストでやりがちなNG事例を3つ紹介します。皆さんのプロジェクトでも同じ状況に陥っていないでしょうか?
NG事例1:テストのパターン出しが不足している
このように、業務パターンやデータのバリエーションが不足している場合、例えば後続の総合テストやUATなどのタイミングで業務パターンの検証の漏れが発覚することとなります。発生頻度の高い正常系のデータは問題なく処理できるがマイナーパターンのデータバリエーションでテストするとエラーになるなど、結合テストで検証できなかった事項や課題が後工程で不具合として表面化し、対応に時間を取られてしまいます。
NG事例2:業務フローをまたいだ検証を考慮していない
NG事例3:モジュール間でのすり合わせをしておらず、データパターンが不十分
これらに当てはまる場合、総合テストやUATで業務フローやモジュールをまたいで検証する際に不具合が多発します。
モジュール間の認識合わせ、障害の内容次第では大幅な見直しが発生し、対応に時間を取られてしまいます。
上記の問題を回避するには、以下の対応が重要です。
ERPの機能の一部を外部パッケージを用いて実現している場合は、結合テストで外部パッケージを合流させて検証するかどうか、テスト計画の段階で明確にしておく必要があります。
外部パッケージを結合テストの対象としない場合、外部パッケージは個別に外部パッケージ内に閉じた検証を実施し、ERPとの連携は総合テストで検証することになります。
ただし外部パッケージの機能がERPの機能との関連性が高く、合同でのテストを総合テストまで引き延ばすべきではない場合は、外部パッケージを含めた結合テストを実施できるように調整するべきです。
とくにERPとは異なるベンダーが外部パッケージを開発するケースでは、課題への対応、仕様変更のために実施した変更について結合テストの段階で確認し、検証精度を向上させることが後工程の品質向上に直結します。
結合テストは単なる機能の確認ではなく、総合テストにおけるシステム全体の検証を円滑に進めるための重要な準備工程です。
業務やデータパターンを網羅的に検証し、課題への対応状況を踏まえて計画的に検証を実施できるかどうかが、後続工程の品質と効率を大きく左右します。
BBSでは、SAP FIモジュールの導入をはじめ、テスト工程の改善やプロジェクト管理の強化を支援しています。また、会計システム導入でお悩みの経理部門や情報システム部門の方のご相談も承っております。
本コラムに関し、より詳細な情報をお求めの場合は、ぜひ当社にお問い合わせください。
著者:黒木 仁、川島 靖大
進化するERP、今こそ押さえたいテストの要点――単体テスト編
進化するERP、今こそ押さえたいテストの要点――次世代ERP編
進化するERP、今こそ押さえたいテストの要点――導入編
あなたの会社のキャリア自律は「自社向け」になっていますか?
現場主導でRPAを始めた企業が最初に躓くポイント(兼務の罠編)
現場主導でRPAを始めた企業が最初に躓くポイント(ネタがない編)
現場主導でRPAを始めた企業が最初に躓くポイント(各現場が自由に推進編)
OCR選定の失敗をゼロにする「実務トライアル」のススメ
【プチ事例】クラウドとのデータ連携の処方箋──自動化で“忘れない日次業務”を実現
管理プロセスを見直して、“使われる”社内FAQボットへ