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 03:39, 8 May 2024
, 8 May→Roles
m (→References) |
m (→Roles) |
||
| Line 8: | Line 8: | ||
== Roles == | == Roles == | ||
' | === Software Developer in Testing - 2019-2020 === | ||
==== 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 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. | |||
Our development teams have been using Postman for over a year and built up a collection with 100+ endpoints and requests. Many requests are furnished with helpful test scripts that extract data from the response, and saves them to the Postman global/environment variables. The collection is an organised into feature folders, and alphabetised to facilitate interactive functional testing of the platform API. However, the developer/test analyst must know the sequence of calls to make to start a session, and then they can perform some feature testing. | |||
This collection is actively maintained and versioned with pull requests and reviews in a Git repo. It is a really wonderful resource, and this project tries to leverage it's value by implementing a framework that can orchestrate the correct sequence of API requests to automate common functional (API) scenarios. | |||
The Postman Testrunner Framework (PTF) uses an external data file to specify a sequence of steps called userActions. A userAction executes a request from the underlying collection, and then has a list of handlers for the possible response codes. Response handlers are little snippets of code that determine the next userAction to perform. When no next userAction is specified in the response handler, execution moves to the next userAction in the external data file until the scenario is completed. The PTF is a simple state-machine. | |||
The PTF implements a data store of the information necessary to be able to test with many different users, FI's, OLB's, deploy instances, etc. A data syntax was developed that links different data types, and selects the values necessary to initiate a scenario for a user. The input variables are processed, the relevant data links expanded, so that the Postman global and environment variables are ready prior to the first request. | |||
Throughout the implementation | |||
A custom reporter was developed to receive the | |||
==== Setup Splunk Enterprise & Integrated PTF with Splunk ==== | |||
*Splunk setup, data indexing, [https://dirksonline.net/CV/Splunk%20feature%20grid.JPG dashboard monitors] etc. of historic 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 === | |||
I started my tenure with Fiserv as a QA member of agile teams delivering changes to a range of mobile banking solutions. | |||
We tested the mobile apps, covering new features as well as cross device regression checks. | |||
I was also able to contribute to the C# Specflow API automation suite for the mobile API servers. | |||
Learned how to deploy environments and modify configurations using Octopus | |||
And spent some time with team testing a banking web app served from dedicated hardware, where I used multiple concurrently running powershell scripts to automate the deployments. | |||
== Tools & Technologies == | == Tools & Technologies == | ||