Fiserv Auckland - Intermediate Software Test Engineer: Difference between revisions

Jump to navigation Jump to search
Line 10: Line 10:


=== Software Developer in Testing - 2019-2020 ===
=== Software Developer in Testing - 2019-2020 ===
The mobile API server was essentially an gateway to a network of several core online banking systems (OLB's), each serving multiple financial institutions (FI's), and each with its own data interface. Such a large and complex system was expensive to replicate for integration testing, and as such there were only few of them. Its configuration was also tightly controlled from the USA, and used by many staff across the company. The configuration and data was always in flux, so that testing there was never fully deterministic. Regardless of the difficulties, the integration testing needed to be performed. Hence, there was a desire to create a dashboard of system health, and readiness for testing, for the integrated environment. To monitor the environment's health we needed a simple check of API functionality, capable of exercising all integration paths across the range of different OLB data interfaces, and FI/user configurations. It had to be flexible to run for a range of users, FI's, and OLB's, as well as for different deploy instances of our platform, and finally to handle the range of dynamic responses possible in such a fluid environment.


==== Developed the PTF ([[Postman Testrunner Framework]]) ====
==== Developed the PTF ([[Postman Testrunner Framework]]) ====
The Postman Testrunner Framework was born out of a need to test the API serving our mobile banking apps in a large, integrated test environment, over which we have little control.
 
Our API platform acts as an aggregator of several core online banking systems (OLB's), each serving multiple financial institutions (FI's), and each with its own data/interface contract.
 
The integrated environment is used by hundreds of staff, across the company, and the data setup changes constantly. Testing here is never deterministic, it has to be opportunistic, and needs to respond appropriately to any number of situations.
To monitor the environment's health we needed a simple check of API functionality, capable of exercising all integration paths across the range of different OLB data interfaces, and FI/user configurations. It had to be flexible to run for a range of users, FI's, and OLB's, as well as for different deploy instances of our platform, and finally to handle the range of dynamic responses possible in such a fluid environment.
To start with, we captured and observed the API calls made by the mobile app (Using Fiddler, Burp Suite, and MITM Proxy) and tried to design a Postman solution to emulate the app's behaviour.
To start with, we captured and observed the API calls made by the mobile app (Using Fiddler, Burp Suite, and MITM Proxy) and tried to design a Postman solution to emulate the app's behaviour.
To initiate a check, we select a platform instance, a code for the FI, a useragent for the device, and then enter the user's credentials. Thereafter, the information required for subsequent scenarios must be obtained in prior calls. For example, to test a transfer scenario, you need to first obtain a list of their accounts.
To initiate a check, we select a platform instance, a code for the FI, a useragent for the device, and then enter the user's credentials. Thereafter, the information required for subsequent scenarios must be obtained in prior calls. For example, to test a transfer scenario, you need to first obtain a list of their accounts.
Line 32: Line 32:
==== Developed Inhouse Web UI for PTF Results ====
==== Developed Inhouse Web UI for PTF Results ====
*Quick glance [https://dirksonline.net/CV/PTF%20Dashboard.JPG dashboard] (and associated data API) written in Node.js/Express.js/Pug
*Quick glance [https://dirksonline.net/CV/PTF%20Dashboard.JPG dashboard] (and associated data API) written in Node.js/Express.js/Pug


=== Software Test Engineer - 2017-2018 ===
=== Software Test Engineer - 2017-2018 ===