Monday, August 25, 2014

BPM and Service Virtualization

Value Added Service (VAS)
       Project Goal

–   Create new functionality on online & mobile digital channels to allow clients to
     purchase value added services. 
–   Create a secure network connection between Bank and the vendor.
–   Create a settlement and reconciliation process.


Technologies 
–  Software AG webMethods
–  webMethods Business Process Model Suite.
–  CA LISA, soapUI and Quality Center

  
     Description:
The above is the post implementation flow where the user is provided with the option to
make online recharge and purchase airtime for his cell number using the value added services from the bank. As per the above, the user is provided with the option to recharge using, making a call to customer support representative, using mobile app on his mobile device, or using the online banking option. Behind the presentation layer, there are flows defined in BPM which triggers and choreograph the services. The blog is specifically to explain how these services are tested at component level and later through the BPM layer before them given to the functional team for final round of testing. There were different services developed to provide this functionality to the client. All the services were divided into technical from the domains, business services from the ESB, Chorography in BPM and lastly the presentation service which gives the result back to the user.

   1.updatePayment:
The payment method will receive request for the VAS Purchase and will respond with a
unique payment reference when a successful payment is done. In case of failure to do payment
the service will respond with respective error message or a blank. The service will debit the
amount from the user account and later pass the message to ESB to send it to third party.

Request from GUI to ESB



Request from ESB to 3rd party

 

Request from 3rd Party to ESB



Request from ESB to GUI


2.updatePaymentReversal:
The payment reversal operation is called when a VAS purchase fails, the service will be
triggered and will roll back the transaction and update the different systems for roll back.
This will also credit the amount back to the user account.

     3.getNotificationAndPreferenceDetails:
       This operation is used to provide notifications addresses and preference of the client for transactions. Service is expected to be used for VAS purchase notifications done from accounts for client under a profile. The service picks the preferred method of notification as set by the client. This is available in the online banking notification preference which user defines, like SMS / Email..

4.updateAuditTrail:
         This service exposes audit trail functionality to allow client systems to write audit trail
         information for VAS Purchases. This service uses information in JSON message format which is         
         updated in audit trial table of Online banking system. This helps to keep track of all the  
  transactions performed and helps to troubleshoot in case of transaction failure.

     5.updateVASGatewayForPurchase:
This service sends the request to the third party which process the request and credit the
amount to the cell. The process from the third party and the actual service provider is out of
scope as its already in production and is used by other banks. To keep the seamless  
transaction between the third party and the actual service provider is the responsibility of third
party as they have their own contracts for the same. Teams responsibility was to test the
message is converted in the format which is expected by the third party. This is done by
validating the logs which keep track of the message converted and details around what
message is send to them. 

     6.sendVASCommunicationToClient:
Once the transaction is successful / failed notification will be send to the client of the
same in the preferred mode which client had already set in his online banking profile. This is
done again by another third party. This is out of scope as the same is already in production for
different client notifications for transactions. Responsibility over here is to test the message is
delivered to Document Services Message Queue (DSMQ) by validating in audit database of DSMQ.  
Client Notification from ESB to DocServices
                           
Message which is send from BPM via ESB to doc services which delivers the notification to the client

Client Notification request DocServices Format
                           
Message which is converted, send from ESB to doc services

Client Notification DocServices database validation




 Audit tables of doc services which processes the message and send it to the third party so the same can be delivered to banking client









 Service Virtualization of Third Party to continue testing
The biggest challenge for testing was unavailability of third party services, environment constraint, as they have Development, Testing and Production were as we have Development, Testing, Staging/UAT and Production. Because of this testing was delayed. All the other systems were under control and within bank. Due to this different team were impacted like development, Service testing team, functional testing team and also the delivery dates for the project to Go Live. Each time the messages were to be confirmed with the third party team that they have received and consumed the messages successfully. This was a bottle neck as the communication was through call/mail and the teams have to wait till confirmation received. To overcome this, it was decided to virtualize the third party system to continue development and testing. CA LISA was the identified tool used to virtualize the third party service.


The communication between ESB and 3rd Party was using message queue. ESB used to convert the  message as per third party format and post the message to outbound queue which used to be processed and placed at third party inbound queue. The response was also in the same format from third party queue to ESB inbound queue. To make the transaction seamless and without any hiccups the transaction was virtualized. Proxy queues were created where the LISA Virtualization recorder was placed which used to read the message and later pass to outbound queue and in same way recording was done to incoming message/response from third party. Once all the transaction was recorded the queue details were changed and virtual service was deployed in LISA VSE all the messages were processed with virtual service and response was sent back. This helps the team to continue with their development and testing and all the services and transaction within the bank environment were tested thoroughly and were ready for deployment. Few rounds of tested was also done with the third party to confirm the messages are processed as expected.


Friday, February 14, 2014

Test step comparison between HP-UFT & CA-LISA

Introduction
The post will give the step level comparison between HP-Unified Functional Test and CA – LISA. This will give you the details of the type of steps which are required to testing in both of the tools
Below common testing validations are used to do the comparison.
Ø XML request – response
Ø XML validation
Ø Database Validation
Ø Data driven testing
Ø JMS / Broker (IBM webSphere, SoftwareAG webMethods)queues
Ø Compare two XML file
Ø Test Data generation
Ø Conditional Flow control
Ø Other useful features


XML request – response  (HP – UFT)

Basic XML request-response validation
Step 1- First you will have to Import WSDL



Step 2 – You will have to add operation to test flow from the list of available operations


Step 3 – Enter the required inputs / test data in the request
Step 4 – Invoke/Run the test case

The test case is compiled for error and then executed


Step 5 – When the execution is completed, report is generated in new window and request-response is displayed in the report

Step 6 – You can add XML validation step to implement the validation / Checkpoint

XML Request response - (CA-LISA)

Basic XML request-response validation using CA-LISA

Step 1 – Create test case in LISA workstation
Step 2 Add step “web Service Execution (XML) set
Click on Run button at the left corner of the window
Verify the response by using the bottom response tab
Conditional looping is available in this step which is useful to control the looping of the test case which can help is to directly jump to particular test step.
LISA can also post the request to the available endpoint directly without the service been exposed as web service.

Validation – (CA – LISA)

XML Assertions
CA-LISA offers different rich XML assertions as below:

Ensure result contains string: This will help to validation the response contains the expect string anywhere in the response
Ensure step response time: Use to base line the response time of each request
XML side-by-side Comparison: With the help of this assertion we can compare two XML file of which one can be captured at run-time and compared with baseline XML/XSD. Here we can easily ignore tags or tag values.

Database Assertions
Ensure result set size: This can help to validate the result size or any column number of characters
Ensure result set contains Expression: This can help to ensure the result has the expected value. The expected values can be passed using any external data sets like excel.

Other Assertions


HTTP Assertions

Web Assertions

Database – (HP – UFT)

Pre-Requisites
  Oracle SQL client should be installed on the system where the test is to be run.
Step 1.1: Add step to Establish Connection. Provide the connection string. Provide the required details in Connection Builder window. Click on Test connection

Step 1.2: Provide the required details in Connection Builder window. Click on Test connection
Step 1.3 Click on Ok to close the Connection Builder window
Step 2.1: Select “Select Table” step
Step 2.2: Click on Connection from properties

Step 3: Select Execute query step
Step 3.1: Select Connection from the properties

Step 3.2 Enter the command which is to be executed
Step 4: Add step “Close Connection” and select the connection which is to be closed from properties

Database – (CA – LISA)

Pre-Requisites
Oracle .jar files be added to your CLASSPATH. You can put them in the hot deploy directory.
Step 1.1: Add “SQL Database Execution (JDBC)”
Step 1.2: Provide the required connection  details
Step 1.3: Enter the query in SQL statement panel and click on Test/Execute SQL button
Conditional looping is available in this step


You are now ready to create filters and assertions on the result set

Data Driven Testing – (HP – UFT)

Pre-Requisites
MS-Office should be installed
The list of available external data set

Excel
XML
Database
Local Table



Data Driven Testing – (CA – LISA)

Pre-Requisites
MS-Office should be installed
The list of available external data set
  Read Rows from a Delimited Data File Data Set
  Create Your Own Data Sheet Data Set
  Create Your Own Set of Large Data Data Set
  Read Rows from a JDBC Table Data Set
  Create a Numeric Counting Data Set
  Read Rows from Excel File Data Set
  Read DTOs from Excel File Data Set
  Unique Code Generator Data Set
  Random Code Generator Data Set 
  Message-Correlation ID Generator Data Set
  Load a Set of File Names Data Set
  XML Data Set 

Read Rows from Excel File Data Set


  Enter file location
  Click on Test and keep
  Below popup will be displayed with values from first row of the excel sheet
  You also have to option to select Sheet 1  / Sheet 2 /….
  Conditional looping is available in this step


JMS / Broker queues IBM webSphere Broker – (HP – UFT)

Pre-Requisites
webSphere Broker Client to be installed on the system where you want to run the test case
Step 1: Add step to Connect to MQ Queue Manager



Step 2: Select Browse Messages in MQ Queues to see the messages which are in queue for processing


Step 3: Add Put Message to MQ queue step


Step 4: Add Get Message From MQ queue to retrieve the message from particular queue


Step 5: Add Disconnect step from MQ queue manager to disconnect


JMS / Broker queues IBM Broker – (CA – LISA)

Pre-Requisites

CA-LISA can easily connect to any database by using thin client.

Below jar to be included in LISA lib folder
  com.ibm.mqjms.jar
  com.ibm.mqbind.jar 
  com.ibm.mq.pcf.jar 
  com.ibm.mq.jar 

Step 1: Provide the required details like server Connection Info, Subscriber Info, 
Step 1.2: Reply Info, Publisher Info, Message body
Step 1.3: Click on Test button to post the message
Step 1.4: Verify the response in “Response Message” tab
Conditional looping is available in this step


Compare XML Files – (HP – UFT)


You can compare the XML file only with .XSD file
No build in feature available to compare two XML files. You can write code / script to achieve the same.


Compare XML Files – (CA– LISA)


You can use the build in step to compare XML file. Here you can ignore any tags / values and also add assertions. Conditional looping is available in this step which is useful to control the test flow.

Test Data Creation – (HP – UFT)

We can code / script to generate test data like Transaction number, date, correlation ids etc


Test Data Creation – (CA  LISA )

Build in data sets can be used to generate this data and store it in property and can be used in any test cases within the project
  Unique Code Generator data set


  Random Code Generator Data Set 
  Message-Correlation ID Generator Data Set

Other Features – (CA – LISA)

Other Features which are missing in HP – UFT and are available in CA – LISA
1.  SoftwareAG webmethod direct connectivity with below options
We can directly connect to
  wM Broker
  wM Integration Server services
  Message Consumer
  SQL database
  FTP Step 


Pre-requisites:  

Below jar to be added to LISA lib directory
  wm-client.jar
  wm-enttoolkit.jar
  wmbrokerclient.jar
  wmjmsadmin.jar
  wmjmsclient.jar
  wmjmsnaming.jar






We can add webMethod Integration Server Services step and directly select and execute the available packages

Integration Server services step



webMethod Broker Step


Performance Testing

 Ensure Step response time for validation of each request – response
 Others





Other useful features
  JMS Messaging
  TIBCO 
  Sonic 
  Oracle 
  Bea 
  Sun JCAPS
  Filters to easily filter data and use it across the test execution