Fiserv Auckland - Intermediate Software Test Engineer: Difference between revisions

Jump to navigation Jump to search

Fiserv Auckland - Intermediate Software Test Engineer (view source)

Revision as of 22:28, 8 May 2024

50 bytes added ,  8 May
m
→‎Software Developer in Testing - 2019-2020
Line 9: Line 9:
== Software Developer in Testing - 2019-2020 ==
== Software Developer in Testing - 2019-2020 ==


With this role I was tasked with integration testing of the API server which was used by the mobile apps as a gateway to a network of core online banking systems (OLBs), each with its own interface contract, and each serving multiple financial institutions (FIs). Due to the expense and difficulty of replicating these OLB systems only three integrated testing environments were available. The test environments were subject to frequent configuration changes, used by many staff, and tightly controlled from the USA. Despite these difficulties and the non-deterministic nature of testing in these environments, integration testing remained essential.
With this role I assisted with integration testing the mobile API server, which was used by the mobile apps as a gateway to a network of core online banking systems (OLBs). Each OLB had its own interface contract, and each served multiple financial institutions (FIs). Due to the expense and difficulty of replicating the OLB systems, only three integrated testing environments were created. These test environments were subject to frequent configuration changes, used by many staff, and tightly controlled from the USA. Despite these difficulties and the non-deterministic nature of testing in these environments, integration testing remained essential.


To streamline integration testing and monitor environment readiness, I spearheaded the development of the Postman Testrunner Framework (PTF), a flexible solution capable of executing complete user scenarios through various OLB's and FI/user configurations.
To streamline integration testing and monitor environment readiness, I spearheaded the development of the Postman Testrunner Framework (PTF), a flexible solution capable of dynamically executing complete user scenarios through various OLB's and FI/user configurations.


'''Key Contributions:'''
'''Key Contributions:'''


=== Development of Postman Collection ===
=== Development of Postman Collection ===
Utilizing tools like Fiddler, Burp Suite, and MITM Proxy, I captured API calls made by the mobile app to create a comprehensive Postman collection. Each scenario was made up of a sequence of calls, each call performing an action and storing relevant data in the Postman Environment Variables. I emphasised obtaining data dynamically from the OLB to minimize reliance on potentially stale data.
Utilizing tools like Fiddler, Burp Suite, and MITM Proxy, API calls made by the mobile app were captured to create a comprehensive Postman collection. Each user scenario was a sequence of calls, each call performing an action and storing relevant data in the Postman Environment Variables. I emphasised obtaining data dynamically from the OLB to minimize reliance on potentially stale data.


=== Architecture of the Postman Testrunner Framework (PTF) ===
=== Architecture of the Postman Testrunner Framework (PTF) ===
The PTF automatically orchestrated the calls in the correct order to execute the user scenarios reliably. It used an external JSON file to specify a sequence of steps called userActions, each userAction referenced a request from the collection, and contained handlers for each http response code which set the next userAction to perform. Effectively, the PTF was a simple state-machine. The PTF also implemented a simple nested JSON data syntax to be able to store data such as user credentials as well as FI connection settings. Passwords were encrypted when they were stored, and decrypted at run time.
The PTF automatically orchestrated the calls in the correct order to execute the user scenarios reliably. It used an external JSON file to specify a sequence of steps called userActions, each userAction referenced a request from the collection, and contained handlers for each http response code which set the next userAction to perform. Effectively, the PTF was a simple state-machine. The PTF also implemented a simple nested JSON data syntax to be able to store data such as user credentials as well as FI connection settings. Passwords were encrypted when stored, and decrypted at run time.


=== Custom Development and Integration ===
=== Custom Development and Integration ===
The PTF was executed using Newman in a Node.js project, with a custom reporter developed to process events emitted by Newman during execution. This allowed for real-time capture of results and detailed logs, providing clear insights into failures and partial successes. Results were sent to the PTF dashboard, as well as to a dedicated Splunk instance for comprehensive monitoring and analysis. The PTF dashboard and Splunk implementations are detailed in the sections below.  
The PTF was executed using Newman in a Node.js project, with a custom reporter developed to process events emitted by Newman during execution. This allowed for real-time capture of results and detailed logs, providing clear insights into failures and partial successes. Results were sent to the PTF dashboard, as well as to a dedicated Splunk instance for comprehensive monitoring and analysis. The PTF dashboard and Splunk implementations are detailed in the sections below.  


The PTF used environment variables to set which FI and user to run for, and it was designed to be able to run several users in parallel. The TFS build server was configured to run scenarios for all the users at the same time once per hour.
The PTF was executed on the TFS build server inside a shell terminal, and TFS used shell environment variables to provide the PTF with FI settings and user credentials. The PTF was designed to be able to run several users in parallel, and the TFS build server was configured to run scenarios for all the users simultaneously once per hour.


=== Development of Inhouse Web UI for Current Health Status Dashboard ===
=== Development of PTF Dashboard ===
This part of the solution used Node.js with Express.js and Pug to create  
This part of the solution used Node.js with Express.js and Pug to create  


Line 36: Line 36:
The API was able to receive events from concurrently running PTF executions, and the Web UI updated itself in real-time to give immediate feedback about the environment health from multiple user perspectives. The fast feedback for multiple users was particularly useful following a deployment of the mobile API server.  
The API was able to receive events from concurrently running PTF executions, and the Web UI updated itself in real-time to give immediate feedback about the environment health from multiple user perspectives. The fast feedback for multiple users was particularly useful following a deployment of the mobile API server.  


The results were not just shown as bland passes and failures, I chose to show that sometimes scenarios  
The results showed as passes and failures, but I chose to also show that sometimes scenarios  
* could not run, eg. a user with just one account could not try to transfer money between accounts. Or  
* could not run, eg. a user with just one account could not try to transfer money between accounts. Or  
* were only partially successful. eg. an attempt to fetch a list of bill payments returning no items because none had been made (marked as "pass ⚠").  
* were only partially successful. eg. an attempt to fetch a list of bill payments returning no items because none had been made (marked as "pass ⚠").  
Line 43: Line 43:


For each cell of the dashboard I used hover and mouse actions to show further details.  
For each cell of the dashboard I used hover and mouse actions to show further details.  
----


==== Setup Splunk Enterprise & Integrated PTF with Splunk ====
==== Setup Splunk Enterprise & Integrated PTF with Splunk ====
Retrieved from ‘https://dirksonline.net/cvwiki/index.php/Special:MobileDiff/863’

Navigation menu