Test cases document is one the artifacts that ESB team needs to prepare.

Normally ESB team should do the testing in Dev and QA environment before processes are handed over to program or project team for UAT testing.

We should capture all the test cases covering each function mentioned explicitly and implicitly in FS. You should ask source system team to provide sample payload.  You can use the same in testing tools (SoapUI /Postman etc) to trigger the processes.

You should involve source and target application team to test the process in development environment if possible rather than involving them in higher environments for UAT.   The sooner you involve them the better. They should start with sanity testing and dry run afterwards. You should detect as many bug as possible in development environment itself. It will save efforts as detecting and fixing bugs in higher environment is costlier.

The test cases I have mentioned below should be prepared and executed by middleware team.

UAT testing plan should be prepared and executed by respective application team intended to receive or send data. Because most of the time middleware team does not have access to the source and target application.

You can use same documents to capture test results. That is why fields related to test results are also added.

The test cases document should have following contents.

List of processes to be tested.

 

Sr No	Process Name	Successfully Tested(Y/N)	Date of Testing	Comments

(You can have separate test case document for each processes if processes are complex and there are large number of test cases for each process.)

Process Name:  (Mention the process Name to be tested)

Testing scenarios:

(You should capture high level test scenarios. Normally you should do negative testing first, I have given sample test cases as per sample FS which transfer web service payload to destination after database lookup. You should set up test cases scenarios in order of functionality to be executed by the process)

 

Test Case No	FS-ID	Description	Accepted(Yes/No)	Reject Reason	Comments
TC-ERR-01	FS-ERR1	Check if  invalid Messages sent  from Target
TC-ERR-02	FS-ERR-2	Check Connection failure to the database
TC-ERR-03	FS-ERR-3	Check connection failure to the Target system
TC-GEN-04	FS-GEN-1,FS-GEN-2,FS-GEN-3,FS-GEN-4,FS-ERR-3	Check  all the processing steps of successful  Message transfer

 

Test case: TC-ERR-01 (For each test cases, you should define detail steps)

Description: Check if invalid Messages sent from Target

Steps

Step No	Step Description	Test Data	Expected Results	Actual Results	Date of Execution	Execution Status(passed/Failed)	Comments
1.1	Trigger the process with invalid payload (from any SOAP /REST API  testing tools like Postman, SoapUI etc)	Payload=Invalid payload	1.Error mail notification should sent to the support group with invalid payload notification message 2. An audit entry should be inserted in audit table.

 

 

Test case: TC-ERR-02

Description: Check connection failure to the database system

(Mention actual test data in the testdata column)

Steps

Step No	Step Description	Test Data	Expected Results	Actual Results	Date of Execution	Execution Status(passed/Failed)	Comments
2.1	1.     Change database  connection to wrong jdbc url 2.     Trigger the process (from any SOAP /REST API  testing tools like Postman, SoapUI etc)	Jdbc Url=wrong url, Payload=valid payload	1.Error mail notification should sent to the support group with database connection failure messages 2. An audit entry should be inserted in audit table.
2.2	1.     Set connection String to correct JDBC url 2.     Set userid/password to invalid credentials   3.      Triger the process	Database url=correct url, Userid/ Password=invalid, payload=valid	1.Error mail notification should sent to the support group with invalid credentials message 2. An audit entry should be inserted in audit table.

 

Test case: TC-ERR-03

Description: Check connection failure to the target system

Steps

Step No	Step Description	Test Data	Expected Results	Actual Results	Date of Execution	Execution Status(passed/Failed)	Comments
3.1	1. Change the connection url to  any wrong url as per test data, 2. Change the database connection to valid  URL with valid credentials   2.Trigger the process	url=invalid url, JDBC=correct url,payload=valid	1.Error mail notification should sent to the support group with Connection failure messages 2.  An audit entry should be inserted in audit table.
3.2	1. Set connection String to correct url. 2.Set  userid /password to  invalid credentials   3.Triger the process	Connection url= valid url, userd/password=Invalid payload =valid	1.Error mail notification should sent to the support group with invalid credentials message 2. An audit entry should be inserted in audit table.

 

Test case : TC-GEN-04

Description: Check successful message delivery

Steps

Step No	Step Description	Test Data	Expected Results	Actual Results	Date of Execution	Execution Status(passed/Failed)	Comments
4	1. Set connection credentials to correct values   2.Trigger the process with valid payload	Connection url=Valid, JDBC=correct url, Credentials =correct, payload=valid	1.Success return code is sent from target. 2. An audit entry should be inserted in audit table.

 

 

 

 

FS is important for any project. Normally you should get it from customer project team. If not, you have to prepare one.

Following content  integration FS should have. I have put some sample diagram.

Overview

Application context diagram

Interface list

(put message type, source and destination )

Business process diagram for each use case

(Sample  flowchart is given below)

 

S. No	Steps	Descriptions
1	Boomi Receive request from Source	Source invokes Boomi Web service and pass the payload
..	..	..

 

Sequence diagram for each use case.

(Sample sequence diagram is given below)

Functional requirement

(Here you should describe detail functional requirement like below. You can have separate section for other nonfunctional requirement or you can have those in single tabular format)

 

 

FS-ID	Interface/module	Description	Reference to URS
FS-GEN-1		Source should  send the messages to ESB process by invoking REST endpoint	URS-GEN-1
FS-GEN-2		ESB process should do validate the messages	URS-GEN-2
FS-GEN-3		ESB process should do database look up to enrich the messages	URS-GEN-3
FS-GEN-4		ESB process should send the messages to the target after validation and enrichment	URS-GEN-4
..	..	..

 

 

Security requirement

Sample as below

1. Source will use basic authentication to connect to ESB process
2. ESB will connect to database through JDBC with basic authentication
3. ESB will connect to Target with Two way SSL

Error handling requirement

 

FS-ID	Interface/module	Description	Reference to URS
FS-ERR-1		ESB should check validity of payload and send email notification accordingly	URS-ERR-1
FS-ERR-2		Connection failure to the external system should generate email notification	URS-ERR-2
FS-ERR-3		Audit Entry to be generated for successful and failed messages.	URS-ERR-3
..	..	..

 

Audit requirement

Compliance requirement

Non Functional requirement

SLA requirements

Mapping and transformation requirement.

(This section is very important)

 

Message Name	Source field	Transformation	Target field

 

Volumetrics

Sample Messages

Sample XSD.

We should have requirement capture templates for integration project which to be shared with customer. Smart customer will fill it up or you need to fill it up after discussion with the customer. Normally integration architect fill up the template after discussion with customer.  Best way is to have workshop with the customer to understand the requirement and fill up the template. Later you can use the template in URS document or FS document. The spreadsheet comes handy to understand the requirement and subsequently effort estimation.

The template contains message type, security protocol, source system, destination system etc.

To know server location is also important when multi site integration infrastructure is available. i.e you may have integration servers available in    Europe, USA.  So if source application and target application is in Europe, then you should install the integration processes in Europe. There will be latency in process execution, due to cross Atlantic traffic flow, if you install the processes in US server.

From the interface requirement sheet you can roughly calculate how much process to be developed, what design pattern to be followed. You can use this template to calculate effort and cost to implement the projects.

Following standard template you can refer and share it customer.

Part1

API Name	Source Connection Protocol	Destination Connection Protocol	Source  Application	Destination Application	Location of Source end Point	Location of Destination End Point	Authentication Requirement (Source to ESB/ESB to Destination)
Order Master	REST	SOAP	SFDC	SAP	Cloud	EU	Basic/Basic -HTTPS
Customer  Master	REST	jdbc	CustMG	SFDC	EU	Cloud	Basic/2Way SSL
Location	REST	SOAP	SCM	SAP	Cloud	EU	Basic/2Way SSL
Contacts	REST	REST	CustMG	OrdMG	Cloud	EU	Message Signing
Organization	SFTP	SFTP	SAP	SCM	US	Cloud	Basic/Basic
Products	SFTP	Jdbc	SAP	SCM	US	Cloud	Basic/Basic
Utilization	SFTP	jdbc	SAP	SCM	US	Cloud	Basic/Basic

Part2

Source Payload (xml/json)	Destination Payload (xml/json)	Data Enrichment requirement	Data Transformation Requirement	Number of Messages Per day(or TPS)/Files	SLA Response Time Sec	File Size /Message Size	Encyption Decryption Requirement
XML	JSON	two external table lookup	one field numeric to char, system date conversion	100 per day	10 sec	100KB	Yes
XML	JSON	One external webservice lookup	system date conversion	100 per day	10 sec	100KB	Yes
XML	JSON	two external table lookup	system date conversion	100 per day	10 sec	100KB	No
XML	JSON	two external webservice  lookup	NA	100 per day	10 sec	100KB	No
Text	Text	NA	NA	5 files per Day	10 Min	10MB	No
XML	XML	NA	NA	5 files per Day	10 Min	10MB	No
XML	XML	NA	NA	5 files per Day	10 Min	10MB	Yes

Part3

Exception Handling Requirement	Audit Requirement	Synch/Asynch	Scheduling Frequency	Initial Synch Up requirement	Message Sequencing Requirement	Other requirement
Email to Support Team	Email success/failed report  by Day end	Asynch, Publish Messages in Q	NA	Yes	Yes	messages to retried to post three times in case of connection failure
Email to Support Team	Email success/failed report  by Day end	Asynch, Fire and forget	NA	Yes	Yes
Email to Support Team	Email success/failed report  by Day end	Synch	NA	No	No
Email to Support Team	Email success/failed report  by Day end	Asynch,Fire and forget	NA	No	No
Email to Support Team	No	NA	Daily	No	No
Email to Support Team	No	NA	Daily	No	No
Email to Support Team	No	NA	Weekly	No	No

After preliminary analysis of requirement, we understand the scope of the project. Once scope is finalized we go for effort estimation. By finalizing scope we identify, source and target, number of interfaces, design pattern and complexity of the interfaces. For integration projects, efforts are calculated on the basis of these parameters.

We spend time on following artifacts/tasks as per SDLC .

1. Analysis
2. Functional Specification
3. Detail Design Document
4. Coding and unit testing
5. Test case preparation
6. QA deployment preparation
7. User acceptance testing support
8. Production deployment support
9. Hypercare
10. Closure activities/Transition to support team.

Here is the sample effort catalogue templates you can use for Effort/Cost calculation for integration projects.

Design Pattern	Type	Scenario	Analysis	FS	DD	Code	ITS	SIT	QA	UAT	Prd	Total Effort(PD)
Synchronous Process	Simple	One Source one Destination, simple Lookup for data enrichment( database or  xref table), Simple flow control(try Catch, Decision, Branching) Simple Transformation(string manipulation),Simple error handling Logic(Reuse existing error handling process), Simple security requirement( standard Basic Authentication)	1	1	1	3	1	1	1	1	1	11
Synchronous Process	Medium	One Source one Destination, Medium flow control(try Catch, decision ,branching, few subprocess call)  medium lookup complexity  for data enrichment(database, xref table or webservices), simple scripts(groovy,shell, bat etc), Medium Transformation logic( String conversion, Date format conversion,simple math) , Medium process logic, Medium Error handling logic( reuse or custom built error handling processes)  Medium security( Encyption/Decyption,  Basic Authentication)	2	2	2	5	1	2	1	2	1	18
Synchronous Process	Complex	One Source more than one Destination,  Complex Flow Control(try/catch,multiple, Branch,route, decesion shapes etc are used), Multiple  lookup for data enrichment to Database, Xref table, Webservices, complex database query, Complex scripting requirement, Multiple subprocesses, Complex Transformation logic(String conversion, Mathematical function,lookup,custom scripts), Complex  Error handling logic( Custom built error handling process required), Additional Security  Requirement(  encryption/decryption, Mauth, Two-way SSL, Message signing, URL signing ),  Audit Requirement	3	3	3	8	2	3	1	3	1	27
Asynchronous Publisher Process	Simple	Send Messages to the single Topic/queue, Simple schema validation( Only incoming message to be validated against predefined schema) Simple flow control, No  Lookup for data enrichment, Simple Transformation, Simple Error handling Logic, Simple security requirement	1	1	1	3	1	1	1	1	1	11
Asynchronous Publisher Process	Medium	Send Messages to single  queue,Medium process logic, Medium flow control, Medium lookup  complexity for data enrichment, Medium Transformation logic, Medium Error handling logic, Medium security	1	1	1	5	1	2	1	2	1	15
Asynchronous Publisher Process	Complex	Send Message to multiple Queue, Complex lookup for data enrichment, Complex flow control, Complex Transformation logic, Complex  Error handling logic, Additional Security  Requirement	2	2	2	7	2	3		3	2	23
Asynchronous Subscriber Process	Simple	Subscribe to the single message Queue, Simple process logic, Simple flow control, Simple lookup for data enrichment, Simple Transformation, Simple Error handling Logic, Simple security	1	1	1	3	1	1	1	1	1	11
Asynchronous Subscriber Process	Medium	Subscribe to the single message Queue, Medium process logic,  Medium flow control,Medium  lookup  complexity for data enrichment, Medium Transformation logic, Medium Error handling logic, Medium security	2	2	2	5	1	2	1	2	1	18
Asynchronous Subscriber Process	Complex	Subscribe to the single message Queue, Commit messages to the database, Sequencing requirement,Complex  flow control  logic, Complex lookup for data enrichment, Complex Transformation logic, Complex  Error handling logic, Additional Security  Requirement	3	3	3	8	2	3	1	3	2	28
FTP Process	Simple	One Source one Destination file transfer, Simple backup and delete after  file transfer, simple error notification call using common error code.	1	1	1	2	1	1	1	1	1	10
FTP Process	Medium	One Source , one Destination, Medium flow control , encryption/decryption of the file, custom built error handling process	2	2	2	4	1	2	1	2	1	17
FTP Process	Complex	One Source multiple  destination,  Complex flow control, Complex Data transformation, Intermediate SFTP servers, Complex Scripting (shell /Groovy/bat) requirement. Additional Security  Requirement, Custom  built error handling process, Mail Notification, Auditing requirement	3	3	3	8	2	3	1	3	2	28
Bulk data Process( File to File File to DB File to web Service DB to Web service Batch Retry)	Simple	One Source one Destination, Simple flow control, No  Lookup for data enrichment, Simple Transformation, Simple Error handling Logic, Simple security	1	1	1	2	1	1	1	1	1	10
Bulk data Process	Medium	One Source one Destination, Medium flow control logic, Medium lookup  complexity for data enrichment, Single split and merge requirement, Medium Transformation logic, Medium Error handling logic, Medium security requirement	2	2	2	4	1	2	1	2	1	17
Bulk data Process	Complex	One Source multiple  Destination, Complex  flow control logic, Complex split and merging requirement, Complex   lookup call for data enrichment , Complex Transformation logic, Complex  Error handling logic, Additional Security  Requirement, Audit requirement.	3	3	3	8	2	3	1	3	1	27

You categorize the interfaces while capturing requirement as per requirement capture template. Then you can use effort catalogue to calculate total cost of the project. The above template categorize all the interfaces in 5 pattern types; synchronous, asynchronous publishers and subscribers (Message Queue based) , SFTP, Bulk processing. We have three types of complexity; simple, medium, complex.

Suppose you have 5 simple synchronous interfaces and 2 sftp complex  interfaces , then total effort should be  5 *11+ 2*28 = 55+56=111 PD.

If blended rate is $200 per PD, total cost 111*200=$22200

You can add project management overhead as 20%, so total cost = 22200 + 4440 =      $26640

Additionally   you can add hyper care or production support overhead as 20%.

for exiting interfaces change requirement , you can consider a re-usability factors while calculating effort.  Suppose your total   effort 111 PD. If you add 60 percent re usability factor total effort would be 111*60/100 = 66.6 PD.

Some tasks take same amount of time irrespective of number of interfaces to develop.  Like production migration preparation . In that case we should consider that effort separately , we should not simply multiple with number of interfaces.