Fiserv Auckland - Intermediate Software Test Engineer

Jan-2017 - Apr-2020

Intro

Fiserv Auckland is responsible for developing mobile apps utilized by over 2000 banks (mainly in the USA), serving more than 8 million active users. Additionally, they manage multi-tier and multi-tenanted Web and API integration servers interfacing with core online banking (OLB) systems and third-party platforms. Fiserv's solutions offer extensive configurability, allowing for customization of features and branding. Operating within the stringent and risk-averse banking domain, reliability and quality are paramount. Testing at Fiserv presented complexities and challenges, yet it has been a rewarding and intellectually stimulating role despite its difficulties.

References

• 2020 Piyush Dungrani LinkedIn Recommendation
• 2020 K Vaughan Kaufman Letter of Recommendation

Software Developer in Testing - 2019-2020

During my tenure as a Software Developer in Testing at Fiserv, 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.

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 data interfaces and FI/user configurations.

Key Contributions:

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 system through API calls to minimize reliance on potentially stale data.

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 data 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 to 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.

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 scenario results and detailed logs, providing clear insights into failed scenarios and partial successes. Results were sent to the Current Health Status dashboard, as well as to a dedicated Splunk instance for comprehensive monitoring and analysis. The 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.

---

This approach proved invaluable in monitoring the fluid and non-deterministic testing environment, enabling nuanced categorization of scenario outcomes beyond pass/fail distinctions, ensuring a more accurate assessment of system readiness and performance.

Development of Inhouse Web UI for Current Health Status Dashboard

This part of the solution used Node.js with Express.js and Pug to create

• an API for receiving events from the PTF, and
• a Web UI to display a snapshot of the latest results in a tabular dashboard.

See a snapshot of the PTF dashboard here.

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

• 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 not supported by the FI/OLB
• not run. eg. skipped, or still waiting to be run

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

---

Setup Splunk Enterprise & Integrated PTF with Splunk

• Splunk setup, data indexing, dashboard monitors etc. of historic results

Software Test Engineer - 2017-2018

At Fiserv, I began as a QA member within agile teams responsible for implementing changes across various mobile banking solutions.

My responsibilities included:

• Testing new features for mobile apps, and conducting cross-device regression checks.
• Contributing to the development of the C# Specflow API automation suite for mobile API servers.
• Deploying environments and modifying configurations using Octopus.
• Testing a banking Web App hosted on dedicated hardware, where I leveraged Powershell scripts for configuring and automating deployments.

During this period, I used tools and technologies such as:

• Postman and SoapUI for API testing.
• Splunk for log analysis and monitoring.
• Team Foundation Server(TFS) for version control (Git repos) and continuous integration (build server). (Note: TFS has been rebranded to Azure DevOps)
• Powershell for automation tasks.
• Octopus as a deployment automation tool.
• Specflow and C# for API automation using BDD.
• Conducted testing across various domains including mobile functional, accessibility, iOS upgrade, and platform API functional testing.
• Used Fiddler, Burp Suite -CE, and MITM Proxy for capturing network calls, as well as XMind for mind mapping.

orig stuff

Fiserv Auckland produces mobile apps for 2000+ banks (8M active users), as well as the multi-tier web and API integration servers that interface to core online banking systems and third parties. Our solutions are configurable with varying degrees of customisation of features and branding. The banking domain is very strict and risk averse! Reliability and quality are particularly important. I've found testing our product complicated, difficult & challenging.

• (2019-2020) - Sole developer of

• Postman Testrunner Framework for automated integration checks.
• Quick glance dashboard (and associated data API) written in Node.js/Express.js/Pug
• Splunk setup, data indexing, dashboard monitors etc. of historic results

• (2017-2018) - QA member of agile teams delivering changes to a range of mobile banking solutions.

Whilst working at Fiserv I worked with the following technologies

• Postman/Newman/Javascript/TV4 JSON validator
• Node.js/Express.js/Pug (Simple Web UI, Data API for test results, task scripting, data analysis)
• Splunk (system monitoring, setup data collectors, creating new dashboards)
• TFS (Git repos, build server, and script scheduling)
• Powershell (System deployment automation & TFS)
• Octopus (deployment engine)
• Specflow/C# (Gherkin API automation)
• Mobile functional, accessibility, iOS upgrade testing
• Platform API functional testing
• XMind (Mind Mapping Tool)
• Fiddler/Burp Suite (Network capturing)
• Soap UI (API testing)

old content from firserv long page

<< return to main page Template:FiservShort

---

I joined Fiserv first work day of 2017. Fiserv is a very different organisation from Trade Me and presented some real challenges for me. They are a huge global (but USA centric) financial services company with over 23,000 staff and over 100 million active users. Their systems were far more complex, the financial services domain far more risk averse, and has very strict quality and deployment process requirements. The management hierarchy was much deeper and most of the work performed in NZ was directed from offshore with little access to clients or end users. The NZ office of Fiserv produces mobile

Development at Fiserv

xxx

• Database
• System Architecture
• API
• UI

• The squad is responsible for the story's design, implementation, testing ....
• Development is performed on short feature branches using mercurial. When stories are ready to be deployed they are merged into the integration and then the release branches before being deployed to production and eventually merged with the default trunk of the code.

Agile at Fiserv

Fiserv uses the Scaled Agile Framework which is ...

• XXX to be updated XXX The squads were usually 2 Dev's, 1 tester, ½ BA, with access to design. In addition, the PO providing direction but considered just outside the squad.
• XXX to be updated XXX Most squads are product facing, but there are also a number of squads that provide internal technical and support services to help the product squads. (DB, Platform, API, Automation, Code Health etc) Squads are trusted to ask for assistance when needed, and when to reach out to others when there are shared or over lapping responsibilities.

Testing at Fiserv

• TBD

Tools I used at Fiserv

• Postman for functional API testing, and developed framework for managing settings, and to be able to orchestrate API calls from a general collection to test different user scenarios.
• SoapUI for functional API testing
• VersionOne for managing cases/stories, test plans/session charters, bug tracking, test progress, issue(bug) tracking
• xmind for mind maps and visual models to help test planning, execution, and reporting
• Confluence Wiki for storing anything that might be useful for others, eg implementation details, how-to's for testing, common testing processes
• Git & TFS version control and build server
• Powershell scripts, mainly for speeding up repetitive tasks, eg deployments to multi-VM test environments
• Octopus deployment engine
• Chrome CJS Custom Javascript extension (to assist with repetitive QA specific tasks)
• Microsoft SQL Server Management Studio
• Visual Studio for various code development tasks
• Microsoft Test Manager for managing test cases and suites, and recording test progress.
• Splunk error analysis and error graphs
• Fiddler & Blurp Suite for network traffic capture
• Developer tools on common browsers
• MS Office