Difference between revisions of "Westpac NZ - Senior Automation Quality Engineer"

From Vincents CV Wiki
Jump to: navigation, search
m (→‎MF8TL Team: Legacy API Server Replacement)
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
{| class="wikitable" style="float:right; margin-left: 10px;"
+
 
−
|-
+
 
−
|[[Template:References|References]]
+
 
−
|-
+
 
−
|TBD [[xxx]]
+
 
−
|}
 
 
'''Apr-2021 - Nov-2023'''
 
'''Apr-2021 - Nov-2023'''
  
−
:At Westpac I worked as a roving Quality Engineer across a number of teams. Learning new product domains, and technology stacks for both the product as well as the automation. It was fun and exciting, keeping me on my toes to quickly adapt and pickup new knowledge and skills. The common thread was always testing through learning and discovering the product and project. Identifying the biggest issues directly in front of us, as well as looking to the future for pitfalls to avoid.  
+
===Intro===
 +
During my time at Westpac, I worked as a roving Quality Engineer across various teams. This role involved learning about different product domains and technology stacks, both for the products and their automation. It was a challenging yet rewarding experience that kept me engaged and encouraged continuous learning. My focus was always on thorough testing, addressing immediate issues and anticipating future challenges to ensure project success.
 +
 
 +
===[[References - Full List|References]]===
 +
* [https://dirksonline.net/CV/Reference%20for%20Vincent%20from%20Stephen%20Stewart.pdf 2023 Stephen Stuart] - Reference. ''Stephen was my People Lead for my duraction at Westpac''
 +
* [https://dirksonline.net/CV/Kate%20Nesmyelova%20-%20TTC%20Reference_check%20For%20Vincent_Dirks%202023.pdf 2023 Kate Nesmeylova] - Reference Check for [[Water Services Reform, Dept of Internal Affairs (NZ Govt) - Senior Test Automation Engineer|TTC Global]]. ''Kate was the Quality Engineering Chapter Area Lead for Westpac''
 +
* [https://dirksonline.net/CV/Hannah%20Gray%20Reference%20letter%20for%20Vincent%20Dirks%202023.pdf 2023 Hannah Gray] - Reference. ''Hannah was team lead for the Test Environments team I was part of for 10 months''
 +
<!--* other linkedin recommendations - TBD-->
 +
 
 +
=== MF8TL Team - Legacy API Server Replacement ===
 +
 
 +
This team was implementing a replacement of a legacy API Server used by the bank's mobile and web apps. The old system had a mature API automation suite implemented using Java, TestNG, and REST Assured.
  
−
:*'''MF8TL Team'''
+
My work
−
::MF8, aka Mobile First V8, was a legacy API product, and was part of a mobile and web app development eco system sold by IBM. MF8 needed to be replaced with a new temporary solution, MF8TL, prior to migrating all functionality to micro-services. MF8 & MF8TL were effectively API (middleware) services facilitating access to the wider banking network. MF8TL needed to be stood up quickly, and behave identically to the legacy MF8 system.  
+
* Refactored and extended the existing mature API automation suite to test the replacement system.
−
::My involvement with the team was to identify existing testing tools and processes used for the old MF8 system, and to apply them to the new MF8TL implementation.  
+
* Implemented method overloading to centralize reporting results to Splunk within the automation codebase.
−
::Primarily I worked to adapt an existing '''REST Assured''', '''testng''', '''Java''' automation suite. I created new scenarios following the patterns already used in the suite, using service classes, '''POJO'''s, extending base test classes etc. I also significantly refactored parts to standardise and improve the information logged to '''Splunk''' when failures were detected, using method overloading to remove duplicated code, centralising the code that despatches requests & receives the responses, creating a single place to verify the kind of response received, prior to transforming to the success response POJO's.
+
* Identified and applied suitable testing tools and processes from the old system to the new implementation.
 +
* Focused primarily on enhancing the API automation suite by creating new test scenarios using established patterns such as service classes, POJOs (Plain Old Java Objects), and extending base test classes.
 +
* Streamlined code, reduced duplication, and centralized request dispatching and response handling processes through Splunk integration efforts.
  
−
:*'''Test Environments Team'''
+
===Test Environments Team===
−
::The main task this team worked on was to build a fun little webapp UI and API server using '''Node.js''', '''Express.js''', '''React''', and the '''mermaid.js''' diagramming tool to create node maps of how various systems connected. In this project I was more a JavaScript developer than a tester.
+
The main task this team worked on was to build a fun little webapp UI and API server using '''Node.js''', '''Express.js''', '''React''', and the '''mermaid.js''' diagramming tool to create node maps of how various systems connected. In this project I was more a JavaScript developer than a tester.
  
−
:*'''Observability Squad'''
+
===Observability Squad===
−
::With this team I switched to a more Platform Engineering role, and became the Westpac Splunk Champion. We were supporting and growing the Splunk platform for Westpac internal technology teams. I have had exposure to Splunk in previous companies and have truly loved it for analysing data. I really like to try and find the customers' experiences come through the data. I would always ask the teams we were supporting on their Splunk onboarding journey three things:  
+
With this team I switched to a more Platform Engineering role, and became the Westpac Splunk Champion. We were supporting and growing the Splunk platform for Westpac internal technology teams. I have had exposure to Splunk in previous companies and have truly loved it for analysing data. I really like to try and find the customers' experiences come through the data. I would always ask the teams we were supporting on their Splunk onboarding journey three things:  
−
:::# Are you logging how well your product/service/feature is working? eg transactions per hour
+
# Are you logging how well your product/service/feature is working? eg transactions per hour
−
:::# Are you catching all the errors and warnings to know when the product/service/feature is doing something bad
+
# Are you catching all the errors and warnings to know when the product/service/feature is doing something bad
−
:::# When you observe an error/warning are you recording good quality information that truly helps devOps understand the issue, and expedites the remediation of the issue?  
+
# When you observe an error/warning are you recording good quality information that truly helps devOps understand the issue, and expedites the remediation of the issue?  
−
:::The latter I find particularly important because in the end the objective is to minimise the risk of major issues by knowing about them quickly, [[and]] also being able to solve them quickly. Timely & good quality information is paramount.
+
The latter I find particularly important because in the end the objective is to minimise the risk of major issues by knowing about them quickly, [[and]] also being able to solve them quickly. Timely & good quality information is paramount.
  
−
:*'''D365 KiwiSaver Squad'''
+
===D365 KiwiSaver Squad===
−
::Built a Selenium WebDriver POM based cucumber Java automation suite from scratch to test a D365 webapp.
+
Built a Selenium WebDriver POM based cucumber Java automation suite from scratch to test a D365 webapp.
  
−
:*'''Mobile Squad'''
+
===Mobile Squad===
−
::Manual and automated testing of Westpac's iOS & Android mobile apps.
+
Manual and automated testing of Westpac's iOS & Android mobile apps.

Revision as of 22:58, 6 May 2024



Apr-2021 - Nov-2023

Intro

During my time at Westpac, I worked as a roving Quality Engineer across various teams. This role involved learning about different product domains and technology stacks, both for the products and their automation. It was a challenging yet rewarding experience that kept me engaged and encouraged continuous learning. My focus was always on thorough testing, addressing immediate issues and anticipating future challenges to ensure project success.

References

MF8TL Team - Legacy API Server Replacement

This team was implementing a replacement of a legacy API Server used by the bank's mobile and web apps. The old system had a mature API automation suite implemented using Java, TestNG, and REST Assured.

My work

  • Refactored and extended the existing mature API automation suite to test the replacement system.
  • Implemented method overloading to centralize reporting results to Splunk within the automation codebase.
  • Identified and applied suitable testing tools and processes from the old system to the new implementation.
  • Focused primarily on enhancing the API automation suite by creating new test scenarios using established patterns such as service classes, POJOs (Plain Old Java Objects), and extending base test classes.
  • Streamlined code, reduced duplication, and centralized request dispatching and response handling processes through Splunk integration efforts.

Test Environments Team

The main task this team worked on was to build a fun little webapp UI and API server using Node.js, Express.js, React, and the mermaid.js diagramming tool to create node maps of how various systems connected. In this project I was more a JavaScript developer than a tester.

Observability Squad

With this team I switched to a more Platform Engineering role, and became the Westpac Splunk Champion. We were supporting and growing the Splunk platform for Westpac internal technology teams. I have had exposure to Splunk in previous companies and have truly loved it for analysing data. I really like to try and find the customers' experiences come through the data. I would always ask the teams we were supporting on their Splunk onboarding journey three things:

  1. Are you logging how well your product/service/feature is working? eg transactions per hour
  2. Are you catching all the errors and warnings to know when the product/service/feature is doing something bad
  3. When you observe an error/warning are you recording good quality information that truly helps devOps understand the issue, and expedites the remediation of the issue?

The latter I find particularly important because in the end the objective is to minimise the risk of major issues by knowing about them quickly, and also being able to solve them quickly. Timely & good quality information is paramount.

D365 KiwiSaver Squad

Built a Selenium WebDriver POM based cucumber Java automation suite from scratch to test a D365 webapp.

Mobile Squad

Manual and automated testing of Westpac's iOS & Android mobile apps.

Retrieved from ‘https://dirksonline.net/cvwiki/index.php?title=Westpac_NZ_-_Senior_Automation_Quality_Engineer&oldid=798’