Re: integration testingについて

統合テスト、結合テストといわれるものですね。
I社さんではITaとかITbとかと称したりしてます。
ソフトウエア開発では一般用語となっていますので、Wikipedia
とかで書かれているのが教科書的かと思いますが、ここはERP導入現場でのケースを記述します。

だいたい
1.要件定義
2.カスタマイズ、基本設計
3.アドオン開発
こんな感んじでPJが進んでいったとき

3.アドオン開発に対するテストは単体テストで、
2.カスタマイズ、基本設計に対するテストが統合テストです。
ちなみに1.要件定義に対するのは統合テストでも実際意識してますが
位置づけ的には客先主体の総合テスト、または受入テスト
となります。

統合テストでは、カスタマイズ定義書(要件定義書みたほうが
早い場合は要件定義書)と基本設計書どおりに仕様どおりに
機能するか、新業務プロセスフローを流してみてテスト
します。

実際は結合テストはじめると単体でばれなかった仕様漏れとか
バグなどが続出するので、統合テストとか言っていても、
とりかかりは単体テスト、動作確認レベルの延長戦です。
ここでやはり必要なスキルはABAPの解析とデバッガーを
操れると重宝します。

ようやく落ち着いてジョブを組み込んでインターフェースを
通してデータを流してみるとか、業務プロセスの手順どおり
動かして、ちゃんと数値が(基本設計書どおりに)正しいか
チェックするといった根気と精緻さが必要な作業です。
これは重要なコンサルの仕事です。ここでのスキルは
Excelのつかいこなしです。関数は当然、マクロも組めると
重宝します。
また言うまでもありませんが基本設計の仕様、業務のイメージと
ユーザーの思いを完璧に理解していなければなりません。

おっとひとつ、フェーズ戻って
ABAP開発している最中は、コンサルは何をするかというと
「結合テストのテストシナリオ」を練ります。
想定しうる入力データパターン、正の場合、ありえないデータ
が入ってきた場合とか、とにかくシステムをいじめつくすかの
ような入力パターンを用意し、アウトプットの正解はこれ。
というような資料を作ります。

私の場合、このシナリオって完璧に洗い出されているというのは
ありえないと思っていますから、実際の結合テストで手を動かしている際に思いついたテスト、ふんだんにたたいてます。
結構この思いつきテスト、結構バグでるんですよ。

FIコンサルでしたら、いつでも経理業務につけるくらいの
業務スキル(勘定コードの意味合いや仕訳パターン、インプットされてくるモジュールとの関わり、どのテーブルにどのような形で格納され、何が正しいアウトプットかが理解できている)は必要でしょうね。